All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roman Kagan <rkagan@virtuozzo.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	Evgeny Yakovlev <eyakovlev@virtuozzo.com>,
	Alexander Graf <agraf@suse.de>,
	qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
	"Denis V. Lunev" <den@openvz.org>
Subject: Re: [Qemu-devel] vmbus bridge: machine property or device?
Date: Thu, 13 Apr 2017 20:04:03 +0300	[thread overview]
Message-ID: <20170413170403.GE14312@rkaganb.sw.ru> (raw)
In-Reply-To: <20170413164457.GX32646@thinpad.lan.raisama.net>

On Thu, Apr 13, 2017 at 01:44:57PM -0300, Eduardo Habkost 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.

I see.  Then we should be good subclassing TYPE_DEVICE.

> > OTOH we use neither mmio nor pio members of SysBusDevice; nor do we
> > currently use any of its *_irq helpers, but we may eventually need to
> > (the guests require VMBus to announce two IRQs in its ACPI description
> > but nothing seems to use them so we just hardcode two (almost) random
> > numbers).
> 
> I'm not sure about the consequences of simply connecting IRQs
> inside ->realize() without using the sysbus *_irq helpers.

We don't connect IRQs; we just compose the appropriate AML fragments
with arbitrarily chosen irq numbers and forget about them.  The guests
refuse to use VMBus if the respective clauses aren't in the ACPI, but
don't seem to care if they point nowhere.

> > Is there an idiom to express that no more than a single vmbus-bridge can
> > be present in the system?  Or the only way to ensure that is with a
> > static or a class variable and checking / setting it in ->realize?
> 
> I wouldn't use a static or class variable. You have some
> alternatives:
> 
> You could check if a TYPE_VMBUS device already exists anywhere in
> the device tree, or always create it at a specific QOM path.
> 
> Or, if your device is 100% specific for PC machines, you could
> add a PCMachineState struct field pointing to the existing vmbus
> device.

Makes sense, thanks!
(And IIUC there's no generic way to express this, like, e.g. with a
class property ->single_instance or ->max_instances=1, right?)

Thanks a lot for the advices, we'll be back with a patchset ;)
Roman.

  parent reply	other threads:[~2017-04-14  2:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-11 20:58 [Qemu-devel] vmbus bridge: machine property or device? Roman Kagan
2017-04-12 15:18 ` Markus Armbruster
2017-04-12 20:07   ` Eduardo Habkost
2017-04-13 15:15     ` Roman Kagan
2017-04-13 16:44       ` Eduardo Habkost
2017-04-13 16:58         ` Peter Maydell
2017-04-13 18:15           ` Eduardo Habkost
2017-04-13 21:57             ` Peter Maydell
2017-04-13 21:10           ` Roman Kagan
2017-04-13 17:04         ` Roman Kagan [this message]
2017-04-13 14:08   ` Roman Kagan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170413170403.GE14312@rkaganb.sw.ru \
    --to=rkagan@virtuozzo.com \
    --cc=agraf@suse.de \
    --cc=armbru@redhat.com \
    --cc=den@openvz.org \
    --cc=ehabkost@redhat.com \
    --cc=eyakovlev@virtuozzo.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.