[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [libvirt] clean/simple Q35 support in libvirt+QEMU for
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [libvirt] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0 |
Date: |
Thu, 23 Aug 2018 18:08:55 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Eduardo Habkost <address@hidden> writes:
> On Wed, Aug 22, 2018 at 01:26:01PM +0100, Daniel P. Berrangé wrote:
>> On Wed, Aug 22, 2018 at 09:01:35AM -0300, Eduardo Habkost wrote:
>> > On Wed, Aug 22, 2018 at 12:36:27PM +0200, Andrea Bolognani wrote:
>> > > On Tue, 2018-08-21 at 14:21 -0400, Laine Stump wrote:
>> > > > On 08/17/2018 06:35 AM, Andrea Bolognani wrote:
>> > > > > If we decide we want to explicitly spell out the options instead
>> > > > > of relying on QEMU changing behavior based on the slot type, which
>> > > > > is probably a good idea anyway, I think we should have
>> > > > >
>> > > > > virtio-0.9 => disable-legacy=no,disable-modern=no
>> > > > > virtio-1.0 => disable-legacy=yes,disable-modern=no
>> > > > >
>> > > > > There's basically no reason to have a device legacy-only rather
>> > > > > than transitional, and spelling out both options instead of only
>> > > > > one of them just seems more robust.
>> > > >
>> > > > I agree with both of those, but the counter-argument is that "virtio"
>> > > > already describes a transitional device like your proposal for
>> > > > virtio-0.9 (at least today), and it makes the versioned models less
>> > > > orthogonal. In the end, I could go either way...
>> > >
>> > > Yeah, Dan already made that argument and convinced me that we
>> > > should use virtio-0.9 for legacy only, virtio-1.0 for modern only
>> > > and plain virtio for no enforced behavior / transitional.
>> >
>> > I don't understand why we are optimizing the new system for the
>> > less useful use cases:
>> >
>> > I don't see a use case where virtio-0.9 (legacy-only) would be
>> > more useful than virtio-transitional. I don't see why anybody
>> > would prefer a legacy-only device instead of a transitional
>> > device. Even if your guest has only legacy drivers, it might be
>> > upgraded and get new drivers in the future.
>> >
>> > I don't see a use case where virtio-1.0 (modern-only) would be
>> > more useful than "virtio". If you are running i440fx, you get a
>> > transitional device with "virtio", and I don't see why anybody
>> > would prefer a modern-only device. If you are running Q35, you
>> > already get a modern-only device with "virtio".
>> >
>> > The most useful feature users need is the ability to ask for a
>> > transitional virtio device on Q35, and this use case is
>> > explicitly being left out of the proposal. Why?
>>
>> You can already get a transitional device on Q35, albeit with manual
>> placement. Adding flags for magic placement for the existing devices
>> is not something that is suitable for the XML. The ability to get
>> legacy-only, or modern-only doesn't exist today in any way, so that
>> would be a valid new feature.
>
> Transitional devices and modern-only devices are different kinds
> of devices. Making the guest see a different type of device
> depending on where it's plugged is why we got into this mess,
Every time we make -device FOO result in a different device depending on
context, device configuration or placement, it eventually joins our
collection of Very Bad Ideas. Different PCI device IDs are a clear
indicator of device difference.
Instances of this class of Very Bad Ideas I've addressed myself:
* I deprecated "ivshmem" in favor of "ivshmem-plain" and
"ivshmem-doorbell".
* I split "ide-drive" into of "ide-hd" and "ide-cd" (deprecation wasn't
fashionable back then)
* I split "scsi-disk" into "scsi-hd" and "scsi-cd" (likewise)
One time pain, long term gain.
We should consider addressing virtio devices, too: deprecate the
chameleon device models an adequate grace period.
> why
> would we recommend applications to rely on this behavior?
>
> That's why I like your virtio-0.9/virtio-1.0 proposal. I just
> don't see why you think virtio-transitional should be out of it.
>
>>
>> Honestly though, the longer this discussion goes on, the more I think
>> the answer is just "do nothing". All this time spent on discussion,
>> and future time spent on implementing new logic in apps, is merely
>> to support running RHEL-6 on Q35.
I strenously disagree. This is first and foremost about correcting a
design mistake we made.
>> I think we should just say that
>> RHEL-6 should use i440fx forever and be done with it.
>
> I'm not sure if you are saying that we (Red Hat) shouldn't spend
> time implementing it, or that the libvirt upstream project should
> reject the patches if somebody implements it. I would understand
> the former, but not the latter.
I would be willing to listen a reasoned argument why correcting the
design mistake is not worthwhile. I'm unwilling to listen to more
downstream blaming. Please stop it.
- Re: [Qemu-devel] [libvirt] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0, (continued)
- Re: [Qemu-devel] [libvirt] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0, Eduardo Habkost, 2018/08/22
- Re: [Qemu-devel] [libvirt] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0, Daniel P . Berrangé, 2018/08/22
- Re: [Qemu-devel] [libvirt] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0, Eduardo Habkost, 2018/08/22
- Re: [Qemu-devel] [libvirt] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0, Daniel P . Berrangé, 2018/08/22
- Re: [Qemu-devel] [libvirt] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0, Eduardo Habkost, 2018/08/22
- Re: [Qemu-devel] [libvirt] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0, Daniel P . Berrangé, 2018/08/22
- Re: [Qemu-devel] [libvirt] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0, Eduardo Habkost, 2018/08/22
- Re: [Qemu-devel] [libvirt] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0, Daniel P . Berrangé, 2018/08/22
- Re: [Qemu-devel] [libvirt] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0, Laine Stump, 2018/08/22
- Re: [Qemu-devel] [libvirt] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0, Daniel P . Berrangé, 2018/08/22
- Re: [Qemu-devel] [libvirt] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0,
Markus Armbruster <=
- Re: [Qemu-devel] [libvirt] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0, Daniel P . Berrangé, 2018/08/23
- Re: [Qemu-devel] [libvirt] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0, Eduardo Habkost, 2018/08/23
- Re: [Qemu-devel] [libvirt] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0, Markus Armbruster, 2018/08/23