On 2015/7/16 23:39, George Dunlap wrote:
On 07/16/2015 04:20 PM, Chen, Tiejun wrote:
What about this?
Looks reasonable (but don't forget that I continue to be unconvinced
that the patch as a whole makes sense).
Yes, I always keep this in my mind as I mentioned in patch #00. Any risk
you're still concerning? Is it that case if guest OS force enabling
these devices again? IMO, at this point there are two cases:
#1. Without passing through a RMRR device
Those emulated devices don't create 1:1 mapping so its safe, right?
#2. With passing through a RMRR device
This just probably cause these associated devices not to work well, but
still don't bring any impact to other Domains, right? I mean this isn't
going to worsen the preexisting situation.
If I'm wrong please correct me.
But I think the issue is, without doing *something* about MMIO
collisions, the feature as a whole is sort of pointless. You can
carefully specify rdm="strategy=host,reserved=strict", but you might
I got what your mean. But there's no a good approach to bridge between
xl and hvmloader to follow this policy. Right now, maybe just one thing
could be tried like this,
Under hvmloader circumstance,
"strict" -> Still set RDM as E820_RESERVED
"relaxed" -> Set RDM as a new internal E820 flag like E820_HAZARDOUS
Then in the case of MMIO collisions
E820_RESERVED -> BUG() -> Stop VM
E820_HAZARDOUS -> our warning messages + disable devices
I think this can make sure we always take consistent policy in each
involved cycle.
Thanks
Tiejun
still get devices whose MMIO regions conflict with RMMRs, and there's
nothing you can really do about it.
And although I personally think it might be possible / reasonable to
check in a newly-written, partial MMIO collision avoidance patch, not
everyone might agree. Even if I were to rewrite and post a patch
myself, they may argue that doing such a complicated re-design after the
feature freeze shouldn't be allowed.
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel