qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13]


From: Michael S. Tsirkin
Subject: Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13] qemu: add routines to manage PCI capabilities]
Date: Mon, 15 Jun 2009 17:37:37 +0300
User-agent: Mutt/1.5.17+20080114 (2008-01-14)

On Mon, Jun 15, 2009 at 09:24:32AM -0500, Anthony Liguori wrote:
> Dor Laor wrote:
>> Libvirt does not support r2d. I hope it won't start to support it.
>
> It supports mips, sparc, and ppc machines now.  I don't see why it  
> wouldn't support r2d.  For ppcemb, I expect this same problem to occur.   
> This sort of restriction is going to be common with embedded boards.
>
>> We can have default values for these types of devices or something  
>> like pci_addr=auto.
>
> Why wouldn't libvirt always use pci_addr=auto?  If the only argument for  
> having libvirt do pci slot allocation is error messages, can't we find a  
> nice way to allow libvirt to create friendly error messages when QEMU 
> fails?
>
>>> If you let QEMU allocate which PCI slot a device goes in, we can hide 
>>> this detail from libvirt.  If you have libvirt do PCI slot allocation 
>>> by default, it has to know about this restriction in the r2d board  
>>> unless you have a clever way to express this sort of information.
>>>
>>> Once QEMU has allocated a device to a slot, libvirt can do a good job 
>>> maintaining that relationship.
>>>
>>
>> The end user should have a mechanism to control device slot  
>> positioning. For example, if you have several pci devices, some
>> get high rate of interrupts and some not, if you want to optimize you  
>> guest you should isolate the high rate 'interesting' devices.
>> This is something the user will need to do. I agree that the default  
>> behavior might be 'auto'
>
> I'm not at all arguing against pci_addr.  I'm arguing about how libvirt  
> should use it with respect to the "genesis" use-case where libvirt has  
> no specific reason to choose one PCI slot over another.  In that case,  
> I'm merely advocating that we want to let QEMU make the decision.

The allocation code could be moved out into a library, and libvirt could
link with it (ducks).

> Regards,
>
> Anthony Liguori




reply via email to

[Prev in Thread] Current Thread [Next in Thread]