Keir Fraser wrote:
On 28 Jun 2006, at 08:13, Nakajima, Jun wrote:
The patch removes the 1:1 mapping against HVM guests from qemu-dm,
allowing to have bigger guests than qemu-dm. This is also the first
step for enabling balloning with HVM guests.
It sets up mapping dynamically, and thus it can cause some latency
for I/O operations for HVM guests. I don't see visible latency yet,
but I think we need to tune the hashing size.
What do all the shadow-mode changes do? I see you add an extra
writable-mapping refcount to tlbflush_timestamp (only 4 bits) -- why
is that needed?
Since the write refcount in type_info can change at any time now because
of map/unmap by qemu-dm at runtime, I stopped using it to avoid a hack
in mm.c. The extra code is a scaled-down version of write refcount
dedicated for guest page table pages, and I think 4 bits would be
sufficient in normal cases because normal guests don't establish that
many translations (i.e. using different virtual addresses) against page
table pages.
Since the number cannot exceed the length of the shadow hash chains
anyway, I can add an extra logic that detects overflow and scans the
entire chains if detected. With this we can just have a 2-bit ref count,
0 - no, 1 (most cases), and 2 - more than one.
Jun
10 messages in com.xensource.lists.xen-develRE: [Xen-devel] [PATCH][HVM] Removing...
.patch