qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>
Cc: Chen Fan <chen.fan.fnst@cn.fujitsu.com>,
	izumi.taku@jp.fujitsu.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v5 7/7] pc: add PC_I440FX_COMPAT to disable aercap for vifo device
Date: Thu, 19 Mar 2015 22:26:36 +0100	[thread overview]
Message-ID: <550B3F0C.7040306@redhat.com> (raw)
In-Reply-To: <1426705538.3643.425.camel@redhat.com>



On 18/03/2015 20:05, Alex Williamson wrote:
> > OK, so maybe it's a feature that users should have control over.
> > But tying it to machine types makes no sense.
>
> If we were to change the default, where else would you tie it?  Machine
> types are the only finger hold we have to maintain VM stability afaik.

I agree.

Machine type are there to avoid exposing "important" changes in the
behavior of the device model to the guest.  These include the number and
size of capabilities and BARs (and other fields in configuration space),
the number of virtqueues and how they are used (virtio features), etc.

Migration is definitely the main reason to introduce a new property and
add compatibility glue for older machine types, but it does not have to
be the only one.

AER seems to me like it is a significant-enough change in how the guest
sees an assigned device.  You certainly don't want it to appear in a
configuration that was previously stable.

So, migration could be a reason why we _have_ to introduce compatibility
glue, but AER to me is a perfect example of why we may sometimes _want_
to have compatibility glue.  It's different, but it makes a lot of sense.

The maintenance cost of the compatibility glue is small.  Hiding the
capability is half a dozen lines of code, and the behavior is no
different than when the guest doesn't want to see errors (which has to
be supported, if only because not all chipsets are PCIe).

Paolo

  reply	other threads:[~2015-03-19 21:26 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-12 10:23 [Qemu-devel] [PATCH v5 0/7] pass aer error to guest for vfio device Chen Fan
2015-03-12 10:23 ` [Qemu-devel] [PATCH v5 1/7] vfio: add pcie extanded capability support Chen Fan
2015-03-12 10:23 ` [Qemu-devel] [PATCH v5 2/7] aer: impove pcie_aer_init to support vfio device Chen Fan
2015-03-13 22:25   ` Alex Williamson
2015-03-16  2:30     ` Chen Fan
2015-03-12 10:23 ` [Qemu-devel] [PATCH v5 3/7] vfio: add aer support for " Chen Fan
2015-03-13 22:28   ` Alex Williamson
2015-03-12 10:23 ` [Qemu-devel] [PATCH v5 4/7] pcie_aer: expose pcie_aer_msg() interface Chen Fan
2015-03-13 22:30   ` Alex Williamson
2015-03-18 13:29   ` Michael S. Tsirkin
2015-03-19  1:33     ` Chen Fan
2015-03-12 10:23 ` [Qemu-devel] [PATCH v5 5/7] vfio-pci: pass the aer error to guest Chen Fan
2015-03-13 22:34   ` Alex Williamson
2015-03-16  3:05     ` Chen Fan
2015-03-16  3:52       ` Alex Williamson
2015-03-16  7:35         ` Chen Fan
2015-03-16 14:09           ` Alex Williamson
2015-03-25  1:33             ` Chen Fan
2015-03-25  2:31               ` Alex Williamson
2015-03-25  1:53             ` Chen Fan
2015-03-25  2:41               ` Alex Williamson
2015-03-25  3:07                 ` Chen Fan
2015-04-01  4:12                 ` Chen Fan
2015-04-01 15:46                   ` Alex Williamson
2015-04-08  8:59                     ` Chen Fan
2015-04-08 15:36                       ` Alex Williamson
2015-04-15 10:30                         ` Chen Fan
2015-04-15 14:18                           ` Alex Williamson
2015-03-12 10:23 ` [Qemu-devel] [PATCH v5 6/7] vfio: add 'x-aer' property to expose aercap Chen Fan
2015-03-18 13:23   ` Michael S. Tsirkin
2015-03-18 14:09     ` Alex Williamson
2015-03-12 10:23 ` [Qemu-devel] [PATCH v5 7/7] pc: add PC_I440FX_COMPAT to disable aercap for vifo device Chen Fan
2015-03-13 22:38   ` Alex Williamson
2015-03-16  2:48     ` Chen Fan
2015-03-16  2:49     ` Chen Fan
2015-03-18 13:23   ` Michael S. Tsirkin
2015-03-18 14:02     ` Alex Williamson
2015-03-18 14:05       ` Michael S. Tsirkin
2015-03-18 14:15         ` Alex Williamson
2015-03-18 14:36           ` Michael S. Tsirkin
2015-03-18 14:50             ` Alex Williamson
2015-03-18 15:02               ` Michael S. Tsirkin
2015-03-18 15:45                 ` Alex Williamson
2015-03-18 16:44                   ` Michael S. Tsirkin
2015-03-18 17:11                     ` Alex Williamson
2015-03-18 17:45                       ` Michael S. Tsirkin
2015-03-18 18:08                         ` Alex Williamson
2015-03-18 18:56                           ` Michael S. Tsirkin
2015-03-18 19:05                             ` Alex Williamson
2015-03-19 21:26                               ` Paolo Bonzini [this message]
2015-03-16  2:52 ` [Qemu-devel] [PATCH v5 0/7] pass aer error to guest for vfio device Chen Fan
2015-03-16  4:57   ` Michael S. Tsirkin
2015-03-19 21:44     ` Paolo Bonzini

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=550B3F0C.7040306@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=chen.fan.fnst@cn.fujitsu.com \
    --cc=izumi.taku@jp.fujitsu.com \
    --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).