Re: [Xen-devel] [PATCH 0 of 5] Add support for mapping grant references into HVM guests (+ some cleanup)

[Steven Smith <steven.smith@xxxxxxxxxx>]

> > 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.
Okay, so the suggestion is that we should use map-to-VA if
auto_translated_physmap is clear, and map-via-P2M if it's set?  Tying
together largely unrelated features like that sounds to me like
encoding implementation limitations into the interface, which doesn't
sound like a good idea.

> 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.
Well, no, it's not directly relevant to me, but at the same time being
able to move backends between PV and HVM guests easily would be pretty
useful.  Any API we can come up with will necessarily require some
changes to the backends, though, so it's mostly a matter of balancing
the amount of porting needed now against the long-term maintenance
cost of having yet more weird special cases in our APIs.  I think that
keying off of auto_translated_physmap probably puts too much emphasis
on the short-term cost, but using an explicit GNTMAP_p2m_map flag
might be better.

Steven.

Attachment: signature.asc
Description: Digital signature

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