Re: [libvirt] [PATCH 3/3] qemu: introduce vram64 attribute for QXL video device

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(a)redhat.com&gt; >> >---

>> >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?