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

["Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>]

Jan Beulich wrote on 2014-09-26:
>>>> On 26.09.14 at 03:24, <yang.z.zhang@xxxxxxxxx> wrote:
>> Jan Beulich wrote on 2014-09-25:
>>>>>> On 25.09.14 at 04:30, <yang.z.zhang@xxxxxxxxx> wrote:
>>>> 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.
>> 
>> If there is another mapping already there and it is different from
>> the one we are establishing, we should return failure. But if the
>> existing mapping is same to the one we are establishing, how we can
>> know whether it is a 'normal memory 1:1' mapping or it is created by
>> previous operation of RMRR creating(e.g. there already a device with
>> RMRR assigned to this guest). What I am thinking is that we need a
>> flag to know whether the mapping is RMRR mapping or regular memory
> mapping.
> 
> If the new and old mappings are the same, nothing needs to be done at
> all (as is already the case in one direction in the patches we have
> seen). And yes, for the case when there is an occasional 1:1 mapping
> we of course will need some way of identifying intentional ones.

So how about adding a new p2m type to do this? It may also helpful when 
creating a guest without device attached.(I mentioned it in another thread).

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


Best regards,
Yang



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