Booting from PV disk driver (Was: Re: [PATCH 10/13] KVM: Wire up hypercall handler ..)

[Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.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