> 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.
Steven.
signature.asc
Description: Digital signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home