On Tue, Feb 23, 2016 at 08:55:29AM +0100, Martin Kletzander wrote:
On Mon, Feb 22, 2016 at 07:26:42PM +0100, Pavel Hrdina wrote:
On Mon, Feb 22, 2016 at 04:16:49PM +0100, Martin Kletzander wrote:
On Mon, Feb 22, 2016 at 02:34:14PM +0100, Pavel Hrdina wrote:
This attribute is used to extend secondary PCI bar and expose it to the guest as 64bit memory. It works like this: attribute vram is there to set size of secondary PCI bar and guest sees it as 32bit memory, attribute vram64 can extend this secondary PCI bar. If both attributes are used, guest sees two memory bars, both address the same memory, with the difference that the 32bit bar can address only the first part of the whole memory.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1260749
Signed-off-by: Pavel Hrdina <phrdina@redhat.com> ---
[...]
diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index d2b641f..34efd4f 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -1436,6 +1436,14 @@ qemuMonitorJSONUpdateVideoMemorySize(qemuMonitorPtr mon, return -1; } video->vram = prop.val.ul / 1024; + if (qemuMonitorJSONGetObjectProperty(mon, path, + "vram64_size_mb", &prop) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("QOM Object '%s' has no property 'vram64_size_mb'"), + path); + return -1; + } + video->vram64 = prop.val.ul / 1024;
And a last question: why don't we just skip the vram64_size_mb if it's not available and move on to the next one? What if it's a bit older QEMU?
I'm not sure about this, but if a device supports some attribute, it should be also present in QOM Object. If this happens, something is really wrong :)
Yes, but we are not checking that it supports that attribute anywhere. Or are you saying that whenever QEMU supports qxl, it has this property?
Oh, I see. I need to rework this as the qemuMonitorJSONUpdateVideoMemorySize was originally meant to update only vgamem and we check for capabilities in qemu_process before we call this function. Good catch. Pavel