> When the virtualized hardware (VT-x or Pacifica) is available, I assume
> that there is no more need for sharing a single table for memory management
> because guest OSs will not know there is such table exists. Is there any
> documentation that explains how to manage memory when virtualized hardware
> is used?
There's no documentation to explain it but you might find some mailing list
posts if you search around the archives a little.
Full virtualisation implies using shadow page tables. The guest isn't allowed
to manage the pagetables the hardware uses anymore. Instead, the hypervisor
is responsible for monitoring the pagetables the guest tries to install,
translating the addresses in them and installing a real pagetable that will
produce the behaviour expected by the guest. This task is complicated by a
number of things: it's necessary to trap guest attempts to write directly to
its own pagetables, and it's necessary to propagate accessed and dirty bits
back to the guest pagetables from the host pagetables.
HTH,
Mark
> Thanks,
>
> Myong
>
> -----Original Message-----
> From: Mark Williamson [mailto:mark.williamson@xxxxxxxxxxxx]
> Sent: Thursday, February 16, 2006 11:22 AM
> To: mkang@xxxxxxxxxxxxxxxx
> Cc: xense-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xense-devel] Xen memory management
>
> > I am just wondering what does it take (including design modification) to
> > limit the global access to the whole table.
>
> The reason there's a single shared table is that M2P mapping needs to be
> fast
> for guests. A table lookup is obviously fast (index by machine address,
> get
>
> a physical address) but requires a lot of space. Maintaining a single
> table
>
> enables the guests to do this fast lookup without requiring a large amount
> of
> machine memory to be devoted to per-guest M2P tables.
>
> The most straightforward solution would be to maintain a separate table for
> each guest. This could probably be done without breaking the existing
> guest
>
> ABI. It would be rather more memory intensive, however.
>
> In principle, a guest could maintain its own M2P table instead of there
> being
> a shared one - Xen wouldn't need to supply it at all. This would still
> incur
> a per-guest memory cost, and some extra complexity in the guest.
>
> > I think every little action
> > that limits unnecessary sharing of resources among guest domains will
> > help achieve multi-level secure Xen that is included in Xen research
> > roadmap.
>
> Agreed. It's worth thinking about where things might leak and considering
> options for plugging / limiting those holes.
>
> Cheers,
> Mark
>
> > Thanks,
> >
> > Myong
> >
> > -----Original Message-----
> > From: Mark Williamson [mailto:mark.williamson@xxxxxxxxxxxx]
> > Sent: Thursday, February 16, 2006 9:28 AM
> > To: xense-devel@xxxxxxxxxxxxxxxxxxx; mkang@xxxxxxxxxxxxxxxx
> > Subject: Re: [Xense-devel] Xen memory management
> >
> > > Xen interface manual describes the following:
> > > "Xen maintains a globally readable machine-to-physical table which
> > > records the mapping from machine page frames to pseudo-physical ones."
> > >
> > > The questions are:
> > > What does it mean by "globally readable"? Which hypercall is being used
> > > to access this table from a guest domain (or is there some other way to
> >
> > access
> >
> > > this table from a guest domain)?
> >
> > It's mapped into a domain's address space. (nb. this is x86 specific).
> > I can't remember where it's mapped, though... Anyhow, the overhead of a
> > hypercall isn't necessary to read it, it's just a single memory access.
> >
> > The advantage here is that a domain can map a machine address back into a
> > guest physical address by simply doing a table lookup. This also means
> > it can see the M2P mappings for all the other domains, but this doesn't
>
> really
>
> > leak any information since it still can't see the memory contents of
> > other domains.
> >
> > It is, however, a channel by which malicious guests might theoretically
> > exchange data whilst bypassing security checks. This is only really an
> > issue
> > in Mandatory Access Control systems, and even there there are liable to
> > be many other covert channels too.
> >
> > > Is it possible to read memory content of guest domain B (or domain 0)
> > > from guest domain A?
> >
> > No. On x86 you can only read memory if you can map it with the
> > pagetables (i.e. no direct physical addressing). You can therefore only
> > read the memory
> > contents of another domain if you can create a pagetable mapping for that
> > domain. Xen validates any updates to the pagetables to make sure that
>
> they
>
> > are safe, so a domain can't create arbitrary mappings to other domains -
>
> if
>
> > it tries to make an illegal mapping, Xen won't allow the pagetable
>
> updates.
>
> > Cheers,
> > Mark
--
Dave: Just a question. What use is a unicyle with no seat? And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!
_______________________________________________
Xense-devel mailing list
Xense-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel
|
Home