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
|
Home