From: Paolo Bonzini <pbonzini@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: agraf@suse.de, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH 0/2] virtio: reset all qbuses too when writing to the status field
Date: Mon, 17 Dec 2012 17:14:44 +0100 [thread overview]
Message-ID: <50CF44F4.7050506@redhat.com> (raw)
In-Reply-To: <20121217160108.GA28909@redhat.com>
Il 17/12/2012 17:01, Michael S. Tsirkin ha scritto:
> On Mon, Dec 17, 2012 at 04:37:36PM +0100, Paolo Bonzini wrote:
>> Il 17/12/2012 16:24, Michael S. Tsirkin ha scritto:
>>> On Mon, Dec 17, 2012 at 04:14:00PM +0100, Paolo Bonzini wrote:
>>>> Il 17/12/2012 11:40, Michael S. Tsirkin ha scritto:
>>>>> How about the following? Then we can put reset
>>>>> in generic code where it belongs.
>>>>> It's untested - really kind of pseudo code - and
>>>>> s390 is still to be updated.
>>>>>
>>>>> Posting to see what does everyone thinks.
>>>>
>>>> I'm not (yet) sure how that helps my problem,
>>>
>>> It makes it possible for virtio.c to get at the
>>> device state through the binding pointer.
>>> So you will be able to qdev_reset_all from virtio.c
>>> where it belongs, instead of duplicating code
>>> in all bindings.
>>
>> Yes, but where does it belong? Do you want to move handling of the
>> status register (and others) to hw/virtio.c?
>
> I thought we can have some kind of generic function that all
> transports can call. It would call qdev_reset_all internally,
> and we would invoke it from all transports.
>
>> Also, you're proposing that I do qdev_reset_all(vdev->binding_opaque)
>> but that would be a layering violation. Generic virtio code should not
>> be able to reset the transport-specific setup (e.g. MSIs).
>
> Bus reset looks like this:
>
> qdev -> pci -> virtio pci reset -> virtio reset
>
> status reset looks like this:
>
> virtio pci reset -> virtio reset
>
> You original patch was basically calling back to
> qdev from virtio pci (bypassing pci).
Because it is actually correct to not involve PCI. This is not
bypassing: PCI is above in the qdev tree, and never learns about a reset
that is triggered by a register write. So, a device can ask qdev and be
reset, but it device cannot ask its parent to do a bus reset of itself.
That would be like doing an FLR when writing zero to status. Wrong,
and a layering violation.
> If that is OK and not a layering violation,
> why calling from virtio back to virtio pci not OK?
Because I'm calling qdev_reset_all on the same device that received the
reset. I'm not calling qdev_reset_all on a parent device. Calling
qdev_reset_all(vdev->binding_opaque) is equivalent calling it on a
parent device.
Still, the extra typesafety of your patch is good to have.
Paolo
> How do you think reset should be layered?
>
>
>>>> but it is definitely a
>>>> step in the right direction!
>>>>
>>>> Paolo
prev parent reply other threads:[~2012-12-17 16:14 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-12 14:26 [Qemu-devel] [PATCH 0/2] virtio: reset all qbuses too when writing to the status field Paolo Bonzini
2012-12-12 14:26 ` [Qemu-devel] [PATCH 1/2] virtio-pci: " Paolo Bonzini
2012-12-12 14:44 ` Michael S. Tsirkin
2012-12-12 15:20 ` Paolo Bonzini
2012-12-12 15:33 ` Michael S. Tsirkin
2012-12-12 16:37 ` Paolo Bonzini
2012-12-12 17:05 ` Michael S. Tsirkin
2012-12-12 17:29 ` Paolo Bonzini
2012-12-12 21:32 ` Michael S. Tsirkin
2012-12-13 7:56 ` Paolo Bonzini
2012-12-12 14:26 ` [Qemu-devel] [PATCH 2/2] virtio-s390: " Paolo Bonzini
2012-12-12 15:38 ` [Qemu-devel] [PATCH 0/2] virtio: " Michael S. Tsirkin
2012-12-12 16:38 ` Paolo Bonzini
2012-12-12 17:18 ` Michael S. Tsirkin
[not found] ` <50C8BF83.4010307@redhat.com>
[not found] ` <20121212212720.GC23087@redhat.com>
2012-12-13 8:54 ` Paolo Bonzini
2012-12-16 17:04 ` Michael S. Tsirkin
2012-12-16 19:31 ` Paolo Bonzini
2012-12-16 21:15 ` Michael S. Tsirkin
2012-12-17 9:24 ` Paolo Bonzini
2012-12-17 10:40 ` Michael S. Tsirkin
2012-12-17 15:14 ` Paolo Bonzini
2012-12-17 15:24 ` Michael S. Tsirkin
2012-12-17 15:37 ` Paolo Bonzini
2012-12-17 16:01 ` Michael S. Tsirkin
2012-12-17 16:14 ` Paolo Bonzini [this message]
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=50CF44F4.7050506@redhat.com \
--to=pbonzini@redhat.com \
--cc=agraf@suse.de \
--cc=mst@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).