> -----Original Message----- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 25 June 2015 14:29 > To: Andrew Cooper; Paul Durrant > Cc: xen-de...@lists.xenproject.org; Keir (Xen.org) > Subject: RE: [PATCH v4 07/17] x86/hvm: add length to mmio check op > > >>> On 25.06.15 at 15:08, <paul.durr...@citrix.com> wrote: > >> -----Original Message----- > >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> Sent: 25 June 2015 13:46 > >> To: Andrew Cooper > >> Cc: Paul Durrant; xen-de...@lists.xenproject.org; Keir (Xen.org) > >> Subject: Re: [PATCH v4 07/17] x86/hvm: add length to mmio check op > >> > >> >>> On 25.06.15 at 14:21, <andrew.coop...@citrix.com> wrote: > >> > On 24/06/15 12:24, Paul Durrant wrote: > >> >> When memory mapped I/O is range checked by internal handlers, the > >> length > >> >> of the access should be taken into account. > >> >> > >> >> Signed-off-by: Paul Durrant <paul.durr...@citrix.com> > >> >> Cc: Keir Fraser <k...@xen.org> > >> >> Cc: Jan Beulich <jbeul...@suse.com> > >> >> Cc: Andrew Cooper <andrew.coop...@citrix.com> > >> >> > >> > > >> > For what purpose? The length of the access doesn't affect which > handler > >> > should accept the IO. > >> > > >> > This length check now causes an MMIO handler to not claim an access > >> > which straddles the upper boundary. > >> > > >> > It is probably fine to terminate such an access early, but it isn't fine > >> > to pass such a straddled access to the default ioreq server. > >> > >> No, without involving the length in the check we can end up with > >> check() saying "Yes, mine" but read() or write() saying "Not me". > >> What I would agree with is for the generic handler to split the > >> access if the first byte fits, but the final byte doesn't. > > > > That's not a trivial thing to do. Could we, for now, have the check claim > > based on address but domain_crash() if length does not fit? > > Would seem acceptable to me; if problems arise we could drop > that domain_crash() later on with a trivial patch. >
Ok. Thanks, Paul > Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
