[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if guest memory is out of reserved device memory maps
On 2014/11/11 18:07, Jan Beulich wrote:
On 11.11.14 at 10:42, <tiejun.chen@xxxxxxxxx> wrote:
On 2014/11/11 17:06, Jan Beulich wrote:
Part of which would involve re-considering whether device
assignment shouldn't be done before memory population in the
tool stack.
Yes, after we introduce this new domctl, we just make sure this domctl
should be called before memory population no matter when we do assign a
device as passthrough.
You didn't think through the implications then: If device assignment
happens early enough, there's no need to report SBDF tuples via a
In the present the device assignment is always after memory population.
And I also mentioned previously I double checked this sequence with printk.
new domctl (or only if we want to still allow for post-boot assignment
of affected devices without using the global enforcement flag, in
which case assigning devices early at boot time is pointless).
The global enforcement flag is mainly used to provide such an approach
the user know exactly he/she may need a hotplug later, we'd better check
to reserve all RMRR ranges in advance.
So I guess you mean we need to separate this interface from our original
device assignment like this,
#1 pci_force as a global variable would control whether we force to
check/reserve __all__ RMRR ranges.
#2 flags field in each specific device of new domctl would control
whether this device need to check/reserve its own RMRR range. But its
not dependent on current device assignment domctl, so the user can use
them to control which devices need to work as hotplug later, separately.
This means we should introduce new parameters just like current 'pci'
construction, right? Or extend current device assignment to be
compatible with this case, for instance, new field to indicate if we
really want to do device assignment in boot time.
Thanks
Tiejun
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
