Re: reserve e820 ram

[Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>]

On 04/20/2012 09:16 AM, Tim Deegan wrote:
>
> At 18:10 +0100 on 18 Apr (1334772613), Francisco Rocha wrote:
> > On 04/18/2012 05:43 PM, Tim Deegan wrote:
> > >
> > > At 15:36 +0100 on 18 Apr (1334763404), Francisco Rocha wrote:
> > > > Hi Tim,
> > > >
> > > > I was thinking about changing my approach.
> > > >
> > > > I think that for now I will leave those pages off because I am
> > > > mostly interested in protecting other areas.
> > > >
> > > > Those accesses for now are inevitable to get the VM to properly
> > > > operate. Now, the question is if it is possible to use page table
> > > > entries to do what I want to do.
> > > >
> > > > The objective would be to use a bit flag that would determine if
> > > > the pages are returned when a call to map_foreign_range is made.
> > > > So, my final objective would be that only pages used for the three
> > > > operations you describe are accessible to Dom0.
> > > > Everything that is not BIOS and related, Qemu or PV backend
> > > > drivers will not be returned.
> > > >
> > > > From what I see in the header files you use 12-bits from a 24-bit
> > > > flag (x86_64). Can we do it? This would again take us to controlling
> > > > access at get_page_from_l1e(), right?
> > >
> > > Are you talking about the count_info and type_info fields?  yes, I 
> think
> > > you can probably put a new flag or two in there.
> > >
> > I was thinking about the ones used in page table entries
> > (_PAGE_PRESENT|RW, etc).
>
> Oh.  That's probably not so suitable for access control since (a) there
> may be more that one PTE pointing to the same page, even controlled by
> different domains, and what if they have different flags? and (b) given
> a page number you can't easily find a PTE that points to it to look at
> the bits.
>
> Th type_info and count_info fields, on the other hand, exist once per
> page and are entirely under Xen's control.
>
> > > Choosing which pages
> > > qemu can map will be interesting, though -- it needs to map 
> anything the
> > > VM uses for I/O.  But maybe you can just define the things you protect
> > > and declare taht they can't be used for I/O.  That sounds easier. :)
> > >
> > The objective is to protect the kernel and its data structures.
> > That is why I was considering the flags I previously mentioned.
> > There is one denominated _PAGE_GUEST_KERNEL.
>
> That's part of the 64-bit PV interface; if the guest is 32-bit or HVM it
> won't be used like that.  I think you'll have to modify the kernel to
> explicitly tell Xen which pages are kernel ones (wih a hypercall) and
> then remember that with a bit in the count_info/type_info.
>
Hi Tim,

I have been changing a xen kernel driver to test the idea of
telling the hypervisor.
 From what I have read guests have the pfn -> mfn table, but
I am not able to find a function to make the conversion. I was
using the pfn because the mfn_valid at the hypervisor level
was saying the mfn was valid. :-) So, the pfn_to_mfn function
at guest level gets the mfn but from the guest point of view,
is that correct?
How can I get the mfn from the pfn/gmfn? I am using a 32-bit
guest.
>
>
> Cheers,
>
> Tim.
>
Cheers,
Francisco