Re: [Xen-devel] [PATCH v4 07/17] x86/hvm: add length to mmio check op

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 25 June 2015 14:29
> To: Andrew Cooper; Paul Durrant
> Cc: 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 15:08, <Paul.Durrant@xxxxxxxxxx> wrote:
> >>  -----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?
> 
> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel