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] Xen with dom0 pvops on ultra-recent "git tip" kernel on

To: Christophe Saout <christophe@xxxxxxxx>
Subject: Re: [Xen-devel] Xen with dom0 pvops on ultra-recent "git tip" kernel on x86_64
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Fri, 16 Jan 2009 09:52:33 -0800
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 16 Jan 2009 09:52:56 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1232127636.4946.28.camel@xxxxxxxxxxxxxxxxxxxx>
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: <49690103.5020706@xxxxxx> <1231619339.5616.15.camel@xxxxxxxxxxxxxxxxxxxx> <20090110203706.GW15052@xxxxxxxxxxxxxxx> <1231622029.4778.1.camel@xxxxxxxxxxxxxxxxxxxx> <1231683478.4809.43.camel@xxxxxxxxxxxxxxxxxxxx> <1231685561.4809.50.camel@xxxxxxxxxxxxxxxxxxxx> <1231691732.5342.3.camel@xxxxxxxxxxxxxxxxxxxx> <1231769868.4838.4.camel@xxxxxxxxxxxxxxxxxxxx> <1231778480.4742.3.camel@xxxxxxxxxxxxxxxxxxxx> <1231838888.4823.5.camel@xxxxxxxxxxxxxxxxxxxx> <20090113153302.GZ15052@xxxxxxxxxxxxxxx> <1231864918.5257.6.camel@xxxxxxxxxxxxxxxxxxxx> <1231865847.5257.8.camel@xxxxxxxxxxxxxxxxxxxx> <4970C2A7.8010702@xxxxxxxx> <1232127636.4946.28.camel@xxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.19 (X11/20090105)
Christophe Saout wrote:
It's not really exciting stuff, mostly some cleanups which were
moving stuff around and such (and some iotlb dma things which were not
entirely trivial but pretty straight-forward).

Yeah the iotlb stuff was in a bit of a flux, but I think I understand how it ended up.

I haven't been brave enough to even attempt starting X; there's a lot of work to be done if you want to do anything beyond dumb framebuffer.

Anyway, in this case, I definitely haven't added this call, so it will need to be done somewhere. Does it need to be called once at startup, or on every context switch? There may well be a suitable place to hook this into already, but we can add a new pvop if its really needed.

Looking at the original Xen kernel the call has to be made on every
context switch if the io permissions change between the two threads.
In the past days I have sort of started trying to put some new paravirt
call together in the various places.  This unfortunately also meant
changing a bit of the native stuff to pass through a unified
"set_io_bitmap" call.  I haven't checked if that works, but at least the
Xen versions of the call doesn't get X up and running.  Now I get a
black screen and dead machine.  I guess I will have to do some
debugging. ;-)

There are several pvops calls made already during context switch, so I wouldn't be surprised if you can sneak it into one of those (load_sp0 looks like a candidate, since it's already passed the tss). Just make sure the hypercall gets batched with the rest of the context-switch multicall so that the latency doesn't get worse.

If you're interested, I can send you what I have so far, but I guess you
have more pressing things to do first. :-)

Yeah, I'm working on rebasing the patch queue at the moment, then I'll try to catch up on the various bugs/observations that people have reported.

   J

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

<Prev in Thread] Current Thread [Next in Thread>