* P2M aliasing check
@ 2016-04-01 17:18 Roger Pau Monné
2016-04-04 8:23 ` Jan Beulich
0 siblings, 1 reply; 2+ messages in thread
From: Roger Pau Monné @ 2016-04-01 17:18 UTC (permalink / raw)
To: xen-devel; +Cc: George.Dunlap, keir, tim, JBeulich
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: P2M aliasing check
2016-04-01 17:18 P2M aliasing check Roger Pau Monné
@ 2016-04-04 8:23 ` Jan Beulich
0 siblings, 0 replies; 2+ messages in thread
From: Jan Beulich @ 2016-04-04 8:23 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: George.Dunlap, xen-devel, keir, tim
>>> 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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2016-04-04 8:23 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-04-01 17:18 P2M aliasing check Roger Pau Monné
2016-04-04 8:23 ` Jan Beulich
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).