Re: [Xen-devel] [PATCH 0 of 3] Update paging/sharing/access interfaces v2

["Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx>]

> On 10/02/2012 11:45, "Olaf Hering" <olaf@xxxxxxxxx> wrote:
>
>>> Actually, this hiatus allows me to float a perhaps cleaner way to map
>>> the
>>> ring: the known problem is that the pager may die abruptly, and Xen is
>>> still posting events to a page now belonging to some other dom0
>>> process.
>>> This is dealt with in the qemu-dm case by stuffing the ring in an
>>> unused
>>> pfn (presumably somewhere in the mmio hole?)
>>>
>>> Would that work? Is there a policy for parceling out these "magic
>>> pfn's"?
>>
>> I was just thinking about this issue. The bug is that the ring lives in
>> dom0, the page should belong to domU and should be destroyed along with
>> it. And ring users in dom0 should request (and maybe initially allocate
>> and setup) a certain gfn belonging to domU.
>
> Yes indeed. The gpfn could be allocated by the domain builder, or by
> hvmloader (which might be too late!).

Well, let's say the domain builder reserves three gpfns (paging, access,
sharing). When helpers for each come up, the enable domctl allocates the
actual frame. Or, we could have the frames allocated up front, it's not
terrible wastage -- the enable domctl would init the ring.

My question was more along the lines of how to choose which guest pfns to
reserve for this.

Andres
>
>  -- Keir
>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel