[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 07/17] x86/hvm: add length to mmio check op
> -----Original Message----- > From: Jan Beulich [mailto:JBeulich@xxxxxxxx] > Sent: 25 June 2015 13:46 > To: Andrew Cooper > Cc: Paul Durrant; xen-devel@xxxxxxxxxxxxxxxxxxxx; 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.cooper3@xxxxxxxxxx> 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.durrant@xxxxxxxxxx> > >> Cc: Keir Fraser <keir@xxxxxxx> > >> Cc: Jan Beulich <jbeulich@xxxxxxxx> > >> Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> > >> > > > > 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? Paul > > Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |