[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



>>> 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.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.