Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13] qemu: add routines to manage PCI capabilities]

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

 



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
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization

[Index of Archives]     [KVM Development]     [Libvirt Development]     [Libvirt Users]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux