Re: [Xen-devel] [PATCH 4/4] xen: Add V4V implementation

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.10.12 at 10:52, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>>>> On 04.10.12 at 19:00, Jean Guyader <jean.guyader@xxxxxxxxx> wrote:
>> On 4 October 2012 16:12, Tim Deegan <tim@xxxxxxx> wrote:
>>> AIUI you need to use compat_handle_okay() instead of guest_handle_okay()
>>> to check the handles if is_pv_32on64_domain(current).
>>>
>> 
>> How about something like that?
> 
> Could be done, but not by modifying guest_handle_okay() (which
> penalizes all its users), nor by (incorrectly) open-coding
> compat_handle_okay(). And neither should any such implementation
> use is_pv_32on64_domain() twice - use the conditional operator
> instead (that way you also avoid evaluating arguments twice).
> 
> So you could either introduce e.g. any_guest_handle_okay(), or
> switch all current users of guest_handle_okay() to, say,
> native_handle_okay() (perhaps with the exception of those where
> the compat mode wrapper source files #define guest_handle_okay()
> to compat_handle_okay(), which could then be dropped).

Actually, after some more recalling of how all this was put together,
you can use the existing guest_handle_okay() on anything that
legitimately is a XEN_GUEST_HANDLE(). In particular, direct
hypercall arguments can be expressed that way since they get
properly zero-extended from 32 to 64 bits on the hypercall entry
path. The things needing extra consideration are only handles
embedded in structures - you need to either translate these
handles, or validate that their upper halves are zero.

That's also one of the reasons why I didn't make the guest
memory accessor/validation macros transparently handle both
cases.

Jan


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