WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 0 of 5] Add support for mapping grant references

To: Steven Smith <steven.smith@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0 of 5] Add support for mapping grant references into HVM guests (+ some cleanup)
From: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Date: Tue, 26 May 2009 19:55:06 +0900
Cc: Steven Smith <Steven.Smith@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 26 May 2009 03:55:31 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20090526092346.GB6973@xxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <patchbomb.1242732422@xxxxxxxxxxxxxxxxxxxxxxxxxx> <20090525023601.GE24437%yamahata@xxxxxxxxxxxxx> <20090526092346.GB6973@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.6i
On Tue, May 26, 2009 at 10:23:46AM +0100, Steven Smith wrote:
> > Hi. Some comments.
> > 
> > - Patch 4 adds a new grant hypercall, but the current
> >   GNTTABOP_map_grant_ref can be used, I suppose. Why not to use
> >   gnttab_map_grant_ref::host_addr?
> > 
> > - It seems that the patch 4 touches common code unnecessary.
> >   it would suffice to touch create_grant_host_mapping() and
> >   replace_grant_host_mapping() inserting something like
> >   "if (hvm_domain) return hvm_domain_case()".
> > 
> > Then, your modification will be well separated so that the
> > possibility for inclusion would increase.
> Yes, it could be done like that.  I decided against going that way,
> though, because we'd end up with the same call having significantly
> different semantics in PV and HVM guests, which sounds like a bad
> idea.
> 
> In PV guests, the grant map hypercalls map a grant reference into the
> virtual address space, by going and rewriting guest PTEs.  In an HVM
> guest, the guest PTEs are all owned by the guest OS kernel, and so
> it's not a good idea for Xen to go and modify them directly (even
> ignoring the nasty interactions with shadow mode).  The patch
> therefore works by modifying the P2M PTEs instead, since they're owned
> by Xen and it can modify them as it wills.  Since the two operations
> are different, from a guest perspective, and have different semantics,
> it seemed best not to try to mosh them together.
> 
> It would have been possible to instead allocate another GNTMAP_* flag,
> and use that to indicate that the guest wants the different semantics.
> That would have worked fine, but it seemed a bit less clean to me than
> keeping the two interfaces separate.

ia64 grant table works with guest physical address as updating
ia64 p2m table. (the ia64 p2m table isn't exactly same to x86, though.
and please note note that ia64 guest works with always
auto_translated_physmap mode enabled.)
And by using "if (xen_feature(XENFEAT_auto_translated_physmap))",
almost all pv backend/frontend works for ia64 pv guest.
So if grant table for x86 HVM domain is implemented with existing
gnttabop, x86 HVM guest can use pv backend/frontend as is.

Your concern is windows pv driver, so this doesn't make sense to you,
though.

thanks,
-- 
yamahata

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>