qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Eric Blake <eblake@redhat.com>
Cc: Alexander Graf <agraf@suse.de>,
	weidong.huang@huawei.com, mst@redhat.com,
	"libvir-list@redhat.com" <libvir-list@redhat.com>,
	qemu-devel@nongnu.org,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Jim Fehlig <jfehlig@suse.com>,
	arei.gonglei@huawei.com, Gerd Hoffmann <kraxel@redhat.com>,
	pbonzini@redhat.com
Subject: Re: [Qemu-devel] [PATCH] cirrus_vga: adding sanity check for vram size
Date: Mon, 12 May 2014 19:53:38 +0200	[thread overview]
Message-ID: <53710AA2.3080808@suse.de> (raw)
In-Reply-To: <5370FF54.2080808@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 12.05.2014 19:05, schrieb Eric Blake:
> [adding libvirt]
> 
> On 05/09/2014 05:54 AM, Gerd Hoffmann wrote:
>> Hi,
>> 
>>> virt-manager/libvirt seems to default to 9 MByte of Vram for
>>> cirrus, so this would break a lot of setups.
>> 
>> It wouldn't.  libvirt sticks that into the xml, but it doesn't
>> set any qemu parameters.  The libvirt parameter actually predates
>> the qemu property for setting the size.

Déjà vu... we had the same problem with pvpanic.

> Then we should probably re-evaluate what libvirt does with the 
> parameters, which avoids breaking any guest that happens to be 
> pre-existing with the odd 9MB sizing in the XML.

If libvirt cannot or doesn't want to pass a user-supplied tag to QEMU,
the only sane and future-proof solution is for libvirt to signal an
error to the user for *any* flags it cannot handle rather than
throwing up on a case-by-case basis the question of how libvirt should
behave when some previously ignored feature gets implemented. That
would prevent us from running into this situation again and again.

As further examples, apic, acpi and other x86-centric features got
auto-added for s390x guests last time I checked. Apart from anything
the user might have specified herself, there's really no reason to add
stuff the user did not ask for and that are not applicable.

Ignoring a value "9" specified by the user would be very odd; and I
guess you have no way of telling who added what to the XML for
choosing between dropping and error'ing out.

Regards,
Andreas

- -- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJTcQqiAAoJEPou0S0+fgE/CY8P/jRgyfqNtv2MLbilNXKKXe5A
CBftFQv1dlvL4VFVGD9W5ortlyOpPfxSmC6fgnLKNbTsTCtDy1k3zgWp8uSjYNrp
/W5oMpOstYxUBA7LtizCnCyPisffV6FlWQBLt8BGnRBPjEyVQXIIDHQuwvYv6Byr
EKjCGWMjw76Rfe84Hdl7xDQvfd+qTFjIDbKEfSa3fciJ/svCYKlnTqsPzvtNWbUg
907r5tI2LVT17xaclhex12GQ+uxV4hXcpcUnY3W/lCHvH98NdgFZRf1P8xTdjSmB
MbQ6WKOtGK9SqoyPiPzm8NwPduBbbmC69vumEmaG6QCqvTmcEKPNB5WMcXSEo4YB
SBJjZrkeNgS7XlUDwL4i45PYSbxi60CByrIrvYzWEielPCUQWMKzckfs+Zxmu0FT
nO51q334YmHU1X/oEPDnF8hakwzu9figWJ43uXSP/dm3ifjhFh35/Owmz+pd84Zi
cauzlygF0JAHGKurStveIqOZ0o6AJLxhWZP695PbKHAeHvOXo6dSsnLgG6POylP1
N/pTCcvQZV6oZ/NjscHcrmYxwrA4XWSzY8JdzS4iPSqzvCgxFNR/wZ1VTjCZ5Cbx
zs+bv+B7JKhjrYs/7dQt8kPv5ZXwh/kEkxkhXX7xpBfdPixx173Gdg3XvS86G6GI
q/dszTpb4kJNcsaxNp3y
=RZ98
-----END PGP SIGNATURE-----

  reply	other threads:[~2014-05-12 17:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-09 10:21 [Qemu-devel] [PATCH] cirrus_vga: adding sanity check for vram size arei.gonglei
2014-05-09 10:31 ` [Qemu-devel] [PATCH] cirrus_vga: adding sanity check for vram size [checkpatch false positive?] Gerd Hoffmann
2014-05-09 10:40   ` Gonglei (Arei)
2014-05-09 10:54     ` Gerd Hoffmann
2014-05-09 10:59       ` Gonglei (Arei)
2014-05-09 11:53         ` [Qemu-devel] [PATCH] cirrus_vga: adding sanity check for vram size Andreas Färber
2014-05-09 11:18 ` Dr. David Alan Gilbert
2014-05-09 11:50   ` Paolo Bonzini
2014-05-09 11:54   ` Gerd Hoffmann
2014-05-09 12:02     ` Dr. David Alan Gilbert
2014-05-12 17:05     ` Eric Blake
2014-05-12 17:53       ` Andreas Färber [this message]
2014-05-12 17:03   ` Eric Blake

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=53710AA2.3080808@suse.de \
    --to=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=arei.gonglei@huawei.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=jfehlig@suse.com \
    --cc=kraxel@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=weidong.huang@huawei.com \
    /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).