WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] managing address space inside paravirtualized guest
From: Mike Rapoport <mike.rapoport@xxxxxxxxx>
Date: Thu, 18 Aug 2011 15:38:43 +0300
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 18 Aug 2011 05:39:19 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=oa0us0C2P1RbgFWtx03fk1z6ivMtibb5zncE16hEQUE=; b=lusvNQBML4zCS4DM786a4wXP86o0iFA/Empk5V+gtczDZ/PdVjyJWwMIJ+RIdfOmOv S6Xdq9aGrW0wHNJIct2AZP2q+jKsEbxtzFwQVbATwpSjkZoHnxFNhmKBLTGKsqakcGBC 2DWTXw//3RkfNHLMWy5cBeLlr0aCxUkrxOVkM=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1313508682.5010.135.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <CABpLfog3U5LW7TrsfmJgDDdYBBg3YNkg5TcbL0KF2SX-zNfv=Q@xxxxxxxxxxxxxx> <1313400820.26263.292.camel@xxxxxxxxxxxxxxxxxxxxxx> <CABpLfohT2nmUX-vCL+4MGc2bhQ6405xasps47ojrycMS8oO+cw@xxxxxxxxxxxxxx> <1313508682.5010.135.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi Ian,
Thanks a lot for your help.It seems that I've solved the problem after
fixing bugs in the page table pinning code.

--
Sincerely yours,
Mike.

On Tue, Aug 16, 2011 at 6:31 PM, Ian Campbell
<Ian.Campbell@xxxxxxxxxxxxx> wrote:
> 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