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

[Tim Deegan <tim@xxxxxxx>]

At 08:07 +0100 on 30 Sep (1412060848), Jan Beulich wrote:
> >>> 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.

Although adding new p2m types is generally OK, I'm not sure I see the
need here.  The useful cases are trivial:
 - gfn space unoccupied -> insert mapping; success.
 - gfn space already occupied by 1:1 RMRR mapping -> do nothing; success.
 - gfn space already occupied by other mapping -> fail.

The remaining case is where the gfn space happens to be entirely
occupied by an existing 1:1 mapping of RMRR that wasn't put there by
RMRR code.  If you really want to detect this I think a simple
reference count of how may times this VM has had the RMRR mapped will
do.  If that count is 0 and you see a mapping, fail (even if the
mapping looks right).

Cheers,

Tim.

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