qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] vmbus bridge: machine property or device?


From: Roman Kagan
Subject: Re: [Qemu-devel] vmbus bridge: machine property or device?
Date: Fri, 14 Apr 2017 00:10:54 +0300
User-agent: Mutt/1.8.0 (2017-02-23)

On Thu, Apr 13, 2017 at 05:58:51PM +0100, Peter Maydell wrote:
> On 13 April 2017 at 17:44, Eduardo Habkost <address@hidden> wrote:
> > On Thu, Apr 13, 2017 at 06:15:34PM +0300, Roman Kagan wrote:
> >> Can you (or anybody else) please help me decide if I need
> >> TYPE_SYS_BUS_DEVICE?  Logically the VMBus bridge is "attached directly
> >> to the main system bus" as written at the top of include/hw/sysbus.h.
> >
> > I think that documentation was written before we supported
> > bus-less devices.
> 
> The major question to ask to determine whether you need to be
> a sysbus device is how does the guest interact with this thing?
> In particular, does it have memory mapped registers (and is it
> not part of some other more specific interface like a PCI device) ?

The interaction happens through a set of dedicated MSRs, shared pages,
hypercalls, and "synthetic" interrupts (non-ioapic).  No pio, mmio,
gpio/irq.

VMBus annonces its presence by a device entry in ACPI with two IRQs;
we've seen no need to wire those IRQs so far, and the guests don't seem
to use them.  That's it; everything else is VMBus-specific.

> > I'm not sure about the consequences of simply connecting IRQs
> > inside ->realize() without using the sysbus *_irq helpers. I hope
> > others can clarify this.
> 
> Connecting what IRQs to what? If your device has an IRQ
> then it isn't the device's job to connect it up -- it is
> the job of the machine model, because only the machine
> model knows what the IRQ controller is, whether the IRQ
> needs to be advertised via ACPI or device tree, and so on.
> You can do that without sysbus though, by using the core
> DeviceState's qdev_init_gpio_* APIs. (NB that if you do
> this then you're by necessity not a device creatable
> with -device, since the board code has to wire you up.)
> 
> If you're not using sysbus then watch out for reset:
> all sysbus devices get automatically reset on QEMU
> system reset; if you're directly using the DeviceState
> baseclass then you have to arrange reset for yourself
> somehow.

Thanks!
Roman.



reply via email to

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