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

["Chen, Tiejun" <tiejun.chen@intel.com>]

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
>