Re: [Xen-devel] [PATCH 3 of 7] Use a reserved pfn in the guest address space to store mem event rings

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2012-02-28 at 15:19 +0000, Andres Lagar-Cavilla wrote:
> > On Thu, 2012-02-23 at 06:05 +0000, Andres Lagar-Cavilla wrote:
> >
> > Doers this mean that a guest can now potentially observe, or even modify
> > it's own mem event ring? Are we sure there's no potential for havoc
> > here?
> 
> This is the same mechanism we use to map the qemu ioreq and bufioreq
> rings. These pfns lie within a reserved region as advertised by the e820
> to the guest, so that's the protection we rely upon.

That still sounds fishy to me ;-) But if people who actually know what's
going on are happy with it then so am I...

> >
> > Is there no scope for making these pages owned by the domain but not
> > actually part of the P2M? We can cope with that for other types of magic
> > page, can't we?
> 
> If you're referring to the qemu rings,

I meant all rings of this sort (i.e. those associated with a domain but
not really part of it, IYSWIM).

>  I don't think so. They're like any
> other page in the p2m. They get allocated with xc_populate_physmap_exact.
> 
> >
> > I didn't atually dig into the implementation other than to see if it
> > answered  my questions, although I did notice:
> >
> >> diff -r 99e6c9b9e971 -r 0e79f8005b6b tools/libxc/xc_hvm_build.c
> >> --- a/tools/libxc/xc_hvm_build.c
> >> +++ b/tools/libxc/xc_hvm_build.c
> >> @@ -38,12 +38,15 @@
> >>  #define SUPERPAGE_1GB_SHIFT   18
> >>  #define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
> >>
> >> -#define SPECIALPAGE_BUFIOREQ 0
> >> -#define SPECIALPAGE_XENSTORE 1
> >> -#define SPECIALPAGE_IOREQ    2
> >> -#define SPECIALPAGE_IDENT_PT 3
> >> -#define SPECIALPAGE_CONSOLE  4
> >> -#define NR_SPECIAL_PAGES     5
> >> +#define SPECIALPAGE_PAGING   0
> >> +#define SPECIALPAGE_ACCESS   1
> >> +#define SPECIALPAGE_SHARING  2
> >> +#define SPECIALPAGE_BUFIOREQ 3
> >> +#define SPECIALPAGE_XENSTORE 4
> >> +#define SPECIALPAGE_IOREQ    5
> >> +#define SPECIALPAGE_IDENT_PT 6
> >> +#define SPECIALPAGE_CONSOLE  7
> >> +#define NR_SPECIAL_PAGES     8
> >
> > Any reason to not simply append them?
> 
> Yes: I didn't want to change the existing magic pfn's. If I just append,
> all pfns shift, and now the venerable store or ioreq pfn's are on
> different locations.

Ah, because we count the indexes from TOP-NR_SPECIAL_PAGES so increasing
NR_SPECIAL_PAGES knocks everything down?

As a separate cleanup perhaps these should be -ve offsets from TOP? Or
maybe the specific offsets don't actually need preserving since they
aren't important outside this file?

Ian.


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