Re: [v6][PATCH 0/7] xen: reserve RMRR to avoid conflicting MMIO/RAM

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

On 2014/9/11 15:48, Jan Beulich wrote:
>>>> On 11.09.14 at 03:38, <tiejun.chen@intel.com> wrote:
>> On 2014/9/11 5:44, Tian, Kevin wrote:
>>>> From: Chen, Tiejun
>>>> Sent: Tuesday, September 09, 2014 10:50 PM
>>>>
>>>
>>> currently the confliction is detected absolutely. Do we need a way to allow
>>> the confliction if there is no device assigned at all?
>>
>> How to handle a hot-plug case when guest already boot? I think it may
>> not be worth distinguishing such fine gain, things will be becoming
>> complicated.
>
> In that case hotplug should fail. I'm very much in agreement with
> Kevin that an override should be possible if there's any risk of the
> detection done now could cause problems on certain systems (as
> pointed out before, I'm mainly concerned about RMRRs being
> defined in regions that overlap where the guest's BIOS wants to
> be placed).
>

Looks I have to refactor most codes again :)

I just take a quick look at Xen codes to try figuring out this possible 
way. As I see, either we do assign a device when create VM, or we do 
attach a device to a running VM, eventually we always call 
libxl__device_pci_add() to finish this operation. Furthermore, 
xc_test_assign_device() call such a hypercall, 
XEN_DOMCTL_test_assign_device. Right?

If yes, I guess I can do check if RMRR is overlapping something in two 
cases:

#1: In case of creating a VM, we may use global flag to make sure our 
original codes work indeed. It should be easy and especially I guess we 
can't check any conflict directly here since those memory info, 
RAM/MMIO/others, don't be filled completely, right?

#2: In case of a running VM, we can check if any overlapping exist then 
determine what's next. Often we should drop to attach such a conflicting 
device.

I'm not sure if I understand this path in Xen, so if I'm wrong please 
correct me.

Thanks
Tiejun