qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

      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).