From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jean Guyader Subject: Re: [PATCH 4/4] xen: Add V4V implementation Date: Mon, 8 Oct 2012 11:24:25 +0100 Message-ID: References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com> <1348141322-28657-5-git-send-email-jean.guyader@citrix.com> <505B2636020000780009CAA6@nat28.tlf.novell.com> <506D98FE020000780009FA23@nat28.tlf.novell.com> <20121004151214.GG38243@ocelot.phlegethon.org> <506EBBD7020000780009FD84@nat28.tlf.novell.com> <506EBF67020000780009FD94@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <506EBF67020000780009FD94@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Tim Deegan , Jean Guyader , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 5 October 2012 10:07, Jan Beulich wrote: >>>> On 05.10.12 at 10:52, "Jan Beulich" wrote: >>>>> On 04.10.12 at 19:00, Jean Guyader wrote: >>> On 4 October 2012 16:12, Tim Deegan 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. > Ok, thanks for the background info. In my hypercall I only use direct hypercall argument handle. The other handles that I use have been created with guest_handle_add_offset from the original argument handle. Considering this, I think I might be ok. Thanks, Jean