Re: [Xen-devel] [v6][PATCH 2/2] xen:vtd: missing RMRR mapping while share EPT

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.09.14 at 04:30, <yang.z.zhang@xxxxxxxxx> wrote:
> Jan Beulich wrote on 2014-09-24:
>>>>> On 24.09.14 at 10:53, <tiejun.chen@xxxxxxxxx> wrote:
>>> On 2014/9/24 16:47, Jan Beulich wrote:
>>>>>>> On 24.09.14 at 10:35, <tiejun.chen@xxxxxxxxx> wrote:
>>>>> In tools stack, how can we get ultimate e820 table built by hvmloader?
>>>> 
>>>> What is this needed for?
>>> 
>>> I mean in case of a hotplug after the migration, we should check any
>>> overlap with current existing RAM/MMIO, right? So we need to know
>>> current existing guest RAM/MMIO layout since this ultimate e820
>>> table is just built by hvmloader, not in xen internal.
>> 
>> Actually I think we'd be better off not complicating the tool stack
>> for this - with proper checking for collisions in the P2M updates, the
>> assignment ought to fail without the tool stack doing anything.
> 
> How do the checking in P2M updates? Only hvmloader knows whether the RMRR 
> region is reserved. If we want do the check in hypervisor, we need to report 
> those info to hypervisor. 

First of all the hypervisor has the information - it is where the
information comes from that tools and hvmloader consume. And
then the check will need to be a collision check: If while
establishing an identity mapping another mapping is found to be
already in place, the request will need to be failed. And similarly
if a "normal" mapping request finds a 1:1 mapping already in place,
this ought to result in failure too. Of course a prerequisite to this
is that error get properly bubbled up through all layers.

Jan


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