From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Booting from PV disk driver (Was: Re: [PATCH 10/13] KVM: Wire up hypercall handler ..) Date: Fri, 23 Feb 2007 15:14:43 -0600 Message-ID: <45DF5943.3090304@codemonkey.ws> References: <45D979D3.2020907@qumranet.com> <20070219103052.4D23725016B@il.qumranet.com><20070221103733.GI3945@ucw.cz> <45DD6CF0.3010509@qumranet.com> <64F9B87B6B770947A9F8391472E032160A91BAF3@ehost011-8.exch011.intermedia.net> <1172140490.3531.236.camel@laptopd505.fenrus.org> <45DD7330.1030001@qumranet.com> <1172142081.3531.243.camel@laptopd505.fenrus.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Arjan van de Ven Return-path: In-Reply-To: <1172142081.3531.243.camel-NIQFrBLA1CpScpXdPBN83iCwEArCW2h5@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Hi Arjan, Have you thought about how you'll boot from a PV disk driver? The BIOS needs support for it in some way. The easiest thing I can think of is to have the PV disk driver show up as an actual PCI device and to use a PCI option rom to hijack the appropriate interrupt. Are you exposing the PV disk driver as a PCI device currently? Regards, Anthony Liguori Arjan van de Ven wrote: > On Thu, 2007-02-22 at 12:40 +0200, Avi Kivity wrote: > >> Arjan van de Ven wrote: >> >>>> I have Ingo's network PV hypercalls to commit in my piplien. >>>> >>>> >>> I have 5 or so pending as well :) >>> can't wait for the infrastructure to be there so that it's relatively >>> easy to add my paravirt block driver >>> >>> >> I can't wait for your pv block driver :) >> >> What do you think is missing? My list has: >> >> - registration of hypercall handlers from module >> > > optional I think, but yeah easier for the user > > >> - execution of hypercall handlers outside vcpu_load() (so they are >> preemptible and sleepable) >> > > I don't need this; most of my hypercalls are non-blocking. The ones that > are can already undo the load themselves, no big deal. > > >> - passing unhandled hypercalls to userspace for qemu-based devices >> > > hm could do I suppose > > One thing I'd like to see is some way to do batched hypercalls. I don't > quite know how this will work in general, but let me explain the > scenario: > The guest submits a bunch of disk IO requests into a submit queue. > The host gets a hypercall and goes to process the submit queue > While this is processing, the guest submits more IO > The guest would here do another hypercall.. > > .. but what could be done is have the host poll at the end of it's scan > of the queue if there's more, and while the host is scanning, just > disable the hypercall the guest would make. So that if there is a > "submit while scanning/processing" going on, no need for more > hypercalls. > > (Otoh... the current situation isn't all that bad, there's one hypercall > for an entire batch of IO's, and the blocklayer isn't all that bad at > giving us nice large batches) > > > > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV