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

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

On 2014/9/11 15:48, Jan Beulich wrote:
> > > > On 11.09.14 at 03:38, <tiejun.chen@xxxxxxxxx> 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  

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