Re: [Xen-devel] managing address space inside paravirtualized guest

[Mike Rapoport <mike.rapoport@xxxxxxxxx>]

On Mon, Aug 15, 2011 at 12:33 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Sun, 2011-08-14 at 06:59 +0100, Mike Rapoport wrote:
>> Hello all,
>>
>> I working on a project that runs in paravirtualized Linux. The
>> application should have it's own address space that is not managed by
>> the underlying Linux kernel. I use a kernel module to allocate pages
>> for the application page table and to communicate the pages physical
>> and machine physical addresses between the kernel and the application.
>> The page tables I create in the application seem to be correct and I
>> can successfully pin them using Xen hypercalls.
>
> What is your end goal here?

Unfortunately I cannot elaborate about the application because of NDA, but I
can tell that certain  parts of the application are required to have
control over
hardware MMU and interrupts.

> Does this scheme work for you under native Linux?

Yes, it does.

>  In general doing an
> end-run around the OS like this seems likely to be fraught with
> pitfalls.

Agree :)

>>  However, when I try to
>> set cr3 to point to these page tables with MMUEXT_NEW_{USER}BASEPTR I
>> get the following error:
>>
>> (XEN) domain_crash_sync called from entry.S
>> (XEN) Domain 1 (vcpu#0) crashed on cpu#0:
>> (XEN) ----[ Xen-4.0.1  x86_64  debug=n  Not tainted ]----
>> (XEN) CPU:    0
>> (XEN) RIP:    e033:[<0000000fb0013d09>]
>
> What does this address correspond to?

This addres corresponds to the printf("success") in the following code:

{
    struct mmuext_op op;
    int success_count;
    int ret;

    op.cmd = MMUEXT_NEW_BASEPTR;
    op.arg1.mfn = new_cr3 >> PAGE_SHIFT;

    ret = HYPERVISOR_mmuext_op(&op, 1, &success_count, DOMID_SELF);
    if (ret || success_count != 1)
        printf("%s: ret=%d, success_count=%d\n", __func__, ret, success_count);

    printf("%s: success\n", __func__);
}

i.e. the hypercall is apparently returned succesfully, but the further
execution faults.

>> Any leads how to debug it would be highly appreciated.
>
> There's only a few calls to domain_crash_sync in entry.S and they all
> involve errors while creating a bounce frame (i.e. setting up a return
> to guest context with an event injection).
>
> Since you are replacing cr3 you are presumably taking steps to ensure no
> interrupts or anything like that can occur, since they will necessarily
> want to be running on the kernel's page tables and not some other
> application controlled pagetables.

We have the interrupts disabled. Besides, the behavior is consistent and I
wouldn't expect that if the reason for faults were interrupts...

> Ian.
>
>>
>> --
>> Sincerely yours,
>> Mike.
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
>
>
>



-- 
Sincerely Yours,
Mike.

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