P2M aliasing check

P2M aliasing check

[Roger Pau Monné]

Hello,

While trying to get hotplug scripts to work on FreeBSD, I've realized that 
there's a check in the P2M code that prevents having multiple gfn pointing 
to the same mfn. The check in question is performed at 
guest_physmap_add_entry, and it means that the existing gfn -> mfn is 
removed and the new one is added, leaving the previous gfn without a valid 
mfn.

This is a problem specially for PVH Dom0, since it means local-attach of 
virtual disk devices lead to a crash of the Dom0. This happens because 
Dom0 is sharing a grant with itself, and then the original gfn -> mfn 
assignment gets destroyed in favor of the new one created by mapping the 
grant reference.

I would like to understand the reason why this check is in place, and why 
aliased gfn -> mfn mappings are not permitted. This is a different behavior 
as compared to PV guests, where multiple VA -> mfn mappings are permitted.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: P2M aliasing check

[Jan Beulich]

>>> On 01.04.16 at 19:18, <roger.pau@citrix.com> wrote:
> While trying to get hotplug scripts to work on FreeBSD, I've realized that 
> there's a check in the P2M code that prevents having multiple gfn pointing 
> to the same mfn. The check in question is performed at 
> guest_physmap_add_entry, and it means that the existing gfn -> mfn is 
> removed and the new one is added, leaving the previous gfn without a valid 
> mfn.
> 
> This is a problem specially for PVH Dom0, since it means local-attach of 
> virtual disk devices lead to a crash of the Dom0. This happens because 
> Dom0 is sharing a grant with itself, and then the original gfn -> mfn 
> assignment gets destroyed in favor of the new one created by mapping the 
> grant reference.
> 
> I would like to understand the reason why this check is in place, and why 
> aliased gfn -> mfn mappings are not permitted. This is a different behavior 
> as compared to PV guests, where multiple VA -> mfn mappings are permitted.

That's the wrong thing to compare with: You mean pfn -> mfn
mappings. And then the pointer direction is misleading too: In
your first paragraph, you really mean to say that unique M -> P
mappings are being enforced, and that's the same for PV. And
not enforcing this would invalidate the (shared!) M2P, which in
addition is part of the PV ABI. Iirc there are a few places where
M -> P translations are being looked up inside the hypervisor
even for non-PV guests, so breaking the unique mapping would
render such translation requests ambiguous.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel