On Tue, May 26, 2009 at 12:46:25PM +0100, Steven Smith wrote:
> > > 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?
Yes. That is exactly what ia64 xen is doing. (ia64 xen supports only
auto translated mode enabled mode.)
> 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.
Yeah. I agree with the point. It's a trade off.
auto_translated_physmap mode support was included long time before and
uite stable. At least for linux pv drivers in linux-2.6.18-xen.hg.
In fact it was introduced before switching to linux-2.6.18-xen.hg tree.
I.e. before June 2007.
Please note that I'm not trying to prevent your new hypercall.
I'm quite fine as long as it doesn't break existing ones.
I was curious why you came up with a new hypercall instead
of reusing existing hypercall.
thanks,
--
yamahata
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home