> -----Original Message----- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 10 August 2018 12:59 > To: Paul Durrant <paul.durr...@citrix.com> > Cc: Andrew Cooper <andrew.coop...@citrix.com>; xen-devel <xen- > de...@lists.xenproject.org> > Subject: Re: [PATCH 2/2] x86/hvm/emulate: make sure rep I/O emulation > does not cross GFN boundaries > > >>> On 10.08.18 at 12:37, <paul.durr...@citrix.com> wrote: > > --- a/xen/arch/x86/hvm/emulate.c > > +++ b/xen/arch/x86/hvm/emulate.c > > @@ -184,8 +184,23 @@ static int hvmemul_do_io( > > hvmtrace_io_assist(&p); > > } > > > > - vio->io_req = p; > > + /* > > + * Make sure that we truncate rep MMIO at any GFN boundary. This is > > + * necessary to ensure that the correct device model is targetted > > + * or that we correctly handle a rep op spanning MMIO and RAM. > > + */ > > + if ( unlikely(p.count > 1) && p.type == IOREQ_TYPE_COPY ) > > + { > > + unsigned long off = p.addr & ~PAGE_MASK; > > > > + p.count = min_t(unsigned long, > > + p.count, > > + p.df ? > > + (off + p.size) / p.size : > > + (PAGE_SIZE - off) / p.size); > > For misaligned requests you need to make sure p.count doesn't end > up as zero (which can now happen in the forwards case). Or do you > rely on callers (hvmemul_do_io_addr() in particular) splitting such > requests already?
Well I have a test case where that split is not happening. Adding a safety check for p.count == 0 at this point should be done. > Yet in that case it's not clear to me whether > anything needs changing here in the first place. (Similarly in the > backwards case I think the first iteration risks crossing a page > boundary, and then the batch should be clipped to count 1.) > Ok. Sounds like clipping to 1 rep in both circumstances would be best. Paul > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
