[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [v8][PATCH 06/16] hvmloader/pci: disable all pci devices conflicting with rdm



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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.