[Qemu-devel] [PATCH 2/2] spapr: Add support for -vga option

[Qemu-devel] [PATCH 2/2] spapr: Add support for -vga option

[Li Zhang]

Also instanciate the USB keyboard and mouse when that option is used
(you can still use -device to create individual devices without all
the defaults)

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Li Zhang <zhlcindy@linux.vnet.ibm.com>
---
 hw/spapr.c |   43 ++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 42 insertions(+), 1 deletions(-)

diff --git a/hw/spapr.c b/hw/spapr.c
index 8d158d7..c7b6e9d 100644
--- a/hw/spapr.c
+++ b/hw/spapr.c
@@ -45,6 +45,8 @@
 #include "kvm.h"
 #include "kvm_ppc.h"
 #include "pci.h"
+#include "pc.h"
+#include "usb.h"

 #include "exec-memory.h"

@@ -82,6 +84,7 @@
 #define PHANDLE_XICP            0x00001111

 sPAPREnvironment *spapr;
+static int spapr_has_graphics;

 qemu_irq spapr_allocate_irq(uint32_t hint, uint32_t *irq_num,
                             enum xics_irq_type type)
@@ -222,6 +225,9 @@ static void *spapr_create_fdt_skel(const char *cpu_model,
         _FDT((fdt_property(fdt, "qemu,boot-kernel", &kprop, sizeof(kprop))));
     }
     _FDT((fdt_property_string(fdt, "qemu,boot-device", boot_device)));
+    _FDT((fdt_property_cell(fdt, "qemu,graphic-width", graphic_width)));
+    _FDT((fdt_property_cell(fdt, "qemu,graphic-height", graphic_height)));
+    _FDT((fdt_property_cell(fdt, "qemu,graphic-depth", graphic_depth)));

     _FDT((fdt_end_node(fdt)));

@@ -457,7 +463,9 @@ static void spapr_finalize_fdt(sPAPREnvironment *spapr,
         }
     }

-    spapr_populate_chosen_stdout(fdt, spapr->vio_bus);
+    if (!spapr_has_graphics) {
+        spapr_populate_chosen_stdout(fdt, spapr->vio_bus);
+    }

     _FDT((fdt_pack(fdt)));

@@ -510,6 +518,30 @@ static void spapr_cpu_reset(void *opaque)
     cpu_reset(CPU(cpu));
 }

+static int spapr_vga_init(PCIBus *pci_bus)
+{
+    /* Default is nothing */
+#if 0 /* Enable this once we merge a SLOF which works with Cirrus */
+    if (cirrus_vga_enabled) {
+        pci_cirrus_vga_init(pci_bus);
+    } else
+#endif
+    if (vmsvga_enabled) {
+        fprintf(stderr, "Warning: vmware_vga not available,"
+                " using standard VGA instead\n");
+        pci_vga_init(pci_bus);
+#ifdef CONFIG_SPICE
+    } else if (qxl_enabled) {
+        pci_create_simple(pci_bus, -1, "qxl-vga");
+#endif
+    } else if (std_vga_enabled) {
+        pci_vga_init(pci_bus);
+    } else {
+        return 0;
+    }
+    return 1;
+}
+
 /* pSeries LPAR / sPAPR hardware init */
 static void ppc_spapr_init(ram_addr_t ram_size,
                            const char *boot_device,
@@ -663,6 +695,11 @@ static void ppc_spapr_init(ram_addr_t ram_size,
         spapr_vscsi_create(spapr->vio_bus);
     }

+    /* Graphics */
+    if (spapr_vga_init(QLIST_FIRST(&spapr->phbs)->host_state.bus)) {
+        spapr_has_graphics = 1;
+    }
+
     machine_opts = qemu_opts_find(qemu_find_opts("machine"), 0);
     if (machine_opts)
         usb_on = qemu_opt_get_bool(machine_opts, "usb", true);
@@ -670,6 +707,10 @@ static void ppc_spapr_init(ram_addr_t ram_size,
     if (usb_on) {
         pci_create_simple(QLIST_FIRST(&spapr->phbs)->host_state.bus,
                           -1, "pci-ohci");
+        if (spapr_has_graphics) {
+            usbdevice_create("keyboard");
+            usbdevice_create("mouse");
+        }
     }
     if (rma_size < (MIN_RMA_SLOF << 20)) {
         fprintf(stderr, "qemu: pSeries SLOF firmware requires >= "
-- 
1.7.7.6

Re: [Qemu-devel] [Qemu-ppc] [PATCH 2/2] spapr: Add support for -vga option

[Benjamin Herrenschmidt]

On Wed, 2012-06-27 at 17:25 -0500, Anthony Liguori wrote:

> If a user asks for something and we can't make it work, we should fail.

Note that QEMU's cirrus works fine with the new kernel cirrusdrmfb, so
I say we should allow it (needs to be able to the powerpc device .mak
as well tho.

It shouldn't be primary because old RHEL's iirc used to have cirrusfb
enabled and that would blow due to guest kernel bugs among others.

I haven't had a chance to try whatever userspace DDX the Xorg folks have
come up with to use on top of cirrusdrmfb, so that might need a bit of
fixing but there's no reason not to allow -vga cirrus at this point.

Note to Matthew: cirrusdrmfb is a LOT SLOWER than offb for a similar
SW only dumb framebuffer, probably has to do with the way it does the
"dirty" stuff, not sure ...

Why not draw directly into the emulated vram ?

Cheers,
Ben.

Re: [Qemu-devel] [Qemu-ppc] [PATCH 2/2] spapr: Add support for -vga option

[Benjamin Herrenschmidt]

On Mon, 2012-07-23 at 16:40 +1000, Benjamin Herrenschmidt wrote:
> 
> Note to Matthew: cirrusdrmfb is a LOT SLOWER than offb for a similar
> SW only dumb framebuffer, probably has to do with the way it does the
> "dirty" stuff, not sure ...
> 
> Why not draw directly into the emulated vram ? 

More note to Matthew ... any objection to doing something similar for
qemu "bochs" style framebuffer ? (ia -vga std). This is the preferred
one on ppc, does 32-bpp fine and is generally simpler.

Cheers,
Ben.

Re: [Qemu-devel] [Qemu-ppc] [PATCH 2/2] spapr: Add support for -vga option

[Matthew Garrett]

Dave Airlie wrote the dirty handling code, so Cc:ing him. I suspect 
transitioning offb over to a similar design would be fine by him.

On Mon, Jul 23, 2012 at 04:40:21PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2012-06-27 at 17:25 -0500, Anthony Liguori wrote:
> 
> > If a user asks for something and we can't make it work, we should fail.
> 
> Note that QEMU's cirrus works fine with the new kernel cirrusdrmfb, so
> I say we should allow it (needs to be able to the powerpc device .mak
> as well tho.
> 
> It shouldn't be primary because old RHEL's iirc used to have cirrusfb
> enabled and that would blow due to guest kernel bugs among others.
> 
> I haven't had a chance to try whatever userspace DDX the Xorg folks have
> come up with to use on top of cirrusdrmfb, so that might need a bit of
> fixing but there's no reason not to allow -vga cirrus at this point.
> 
> Note to Matthew: cirrusdrmfb is a LOT SLOWER than offb for a similar
> SW only dumb framebuffer, probably has to do with the way it does the
> "dirty" stuff, not sure ...
> 
> Why not draw directly into the emulated vram ?
> 
> Cheers,
> Ben.
> 
> 
> 
-- 
Matthew Garrett | mjg59@srcf.ucam.org