Re: [Qemu-devel] Managing architectural restrictions with -device and libvirt

[Mark Cave-Ayland]

On 04/07/17 21:44, Daniel P. Berrange wrote:

> On Tue, Jul 04, 2017 at 07:25:41PM +0100, Mark Cave-Ayland wrote:
>> Hi all,
>>
>> I've been working on a patchset that brings the sun4u machine on
>> qemu-system-sparc64 much closer to a real Ultra 5, however due to
>> various design restrictions I need to be able to restrict how devices
>> are added to the machine with -device.
>>
>> On a real Ultra 5, the root PCI bus (sabre) has 2 PCI bridges (simba A
>> and simba B) with the onboard devices attached to simba A with 2 free
>> slots, and an initially empty simba B.
>>
>> Firstly, is it possible to restrict the machine so that devices cannot
>> be directly plugged into the root PCI bus, but only behind one of the
>> PCI bridges? There is also an additional restriction in that slot 0
>> behind simba A must be left empty to ensure that the ebus (containing
>> the onboard devices) is the first device allocated.
>>
>> Secondly, how does libvirt handle these type of restrictions? Is it able
>> to get the information from QEMU or is there some kind of libvirt
>> profile that needs to be updated? And do newer versions of libvirt have
>> the ability to attach devices behind PCI bridges using a GUI such as
>> virt-manager, or is that only something that can only be done by
>> directly editing the domain XML?
> 
> Libvirt has a bunch of code that provides different logic for various
> machine types when doing addressing & setting up default PCI controllers.
> Libvirt support for sparc machine types almost certainly broken since
> I'm not aware of anyone having looked at it forever. Probably best to
> re-ask your Q's on the libvir-list to get info from the people familiar
> with this, since I'm fuzzy on precise details of what you'd need todo.

Thanks for the information. From what you're saying above it seems like
we need to fix this on two levels: firstly in QEMU itself, and secondly
to determine some suitable logic for libvirt.

For me QEMU itself is the priority, however it does appear that some
people are using libvirt with SPARC, e.g. from this post on
debian-sparc: https://lists.debian.org/debian-sparc/2017/07/msg00000.html.

The other thing to bear in mind is that the machine model still needs at
least one more change (emulating a proper Sun HME nic) so it would be
good to get the model static before working on the libvirt logic.


ATB,

Mark.