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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 30.09.14 at 05:49, <yang.z.zhang@xxxxxxxxx> wrote:
> 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).

If that makes it easier to implement - why not? But I think you're aware
that raising memory management related questions without Tim in the
loop isn't going to yield a result you can reasonably rely on later being
accepted in patch form.

Jan


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