|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Fwd: Re: [Xen-devel] [RFC] XI Shadow Page Table Mechanism]
Robert Phillips wrote:
This isn't supported currently? Since an HVM must go through 16
bit, 32
bit, and 64 bit mode to boot up, how can we start more than one
guest at
a time currently if this doesn't already work?
Ed Smith's daily test results show there have been problems with SMP.
We haven't diagnosed these problems but, from reading the pre-XI
shadow code, it's not clear how it copes with multiple VCPUs in the
same domain running in different modes.
There's only a short period of time when this would be happening right?
During boot up?
- how do you deal with large pages within the hypervisor? do you
coalesce or just hope there is contiguous pages available?
We just hope that contiguous pages are available. However we allocate
pages for the guest in large extents to maximize this likelihood. In
practice this is very effective for guests created soon after boot
time. There may be fragmentation problems later.
Any ideas about how to deal with this long term? Large page support
would also be useful for PV domains. There was a lot of people at the
last summit that were interested in this...
Thanks for the responses,
Anthony Liguori
- what is the performance benefit in saving the shadow pages for each
domain? there's clearly a memory trade-off here so understanding the
performance gain seems important.
The performance benefit appears to be substantial but we have not done
a thorough study yet.
- OOM can be dealt with in the existing code by just invalidating
existing mappings to free up pages. what advantages do your approach
have to this? (i realize we don't do this today but in theory, we
could).
Ultimately XI deals with OOM by tearing down cached shadow pages,
just as you say. But it uses LRU to pick the victims.
Interesting stuff. I'm eager to see the code.
Regards,
Anthony Liguori
> Thanks,
> -b
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx <mailto:Xen-devel@xxxxxxxxxxxxxxxxxxx>
> http://lists.xensource.com/xen-devel
--
------------------------------------------------------------------------
Ben Thomas Virtual Iron
Software
bthomas@xxxxxxxxxxxxxxx
<mailto:bthomas@xxxxxxxxxxxxxxx> Tower
1, Floor 2
978-849-1214 900 Chelmsford
Street
Lowell, MA 01851
------------------------------------------------------------------------
Robert S. Phillips Virtual Iron Software
rsp.vi.xen@xxxxxxxxxxxxxxx
<mailto:rsp.vi.xen@xxxxxxxxxxxxxxx> Tower 1, Floor 2
978-849-1220 900 Chelmsford Street
Lowell, MA 01851
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|