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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 07/16/2015 05:08 PM, Chen, Tiejun wrote:
> 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.

A better way to communicate between xl and hvmloader is to use xenstore,
as we do for allow_memory_reallocate.  But I have very little hope we
can hash out a suitable design for that by tomorrow.

 -George


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