On Tue, 2011-08-16 at 14:44 +0100, Mike Rapoport wrote:
> 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.
:-/ and the requirement is for the _application_ to control these
mappings etc rather than simply asking the kernel to do it (i.e. by
mmap'ing device)? Have you seen drivers/uio in the kernel for example?
Anyway, perhaps you could post a dummy user application (which just
creates the PT and perhaps flip to/from them?), along with the complete
hypervisor and Linux modifications? I don't think anyone is going to be
able to help if they are guessing what you might have actually done.
> > 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.
Where does new_cr3 come from?
Are you sure that your new pagetables include mappings for the kernel
text and data etc?
There was a cr2 value in the trace, I wonder if it is valid at this
point (it's not clear if you've taken a page fault or some other form of
fault)
> >> 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...
OK.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home