Re: [Qemu-devel] [PATCH] usb-redir: Add the posibility to filter out certain devices from redirecion

[Gerd Hoffmann]

On 01/12/12 17:31, Hans de Goede wrote:
> This patch adds the posibility to filter out certain devices from redirecion.
> To use this pass the filter property to -device usb-redir.  The filter
> property takes a string consisting of filter rules, the format for a rule is:
> 

Hmm, what is the point of having this filter in qemu?

I'd expect the other end of the network connection which talks to the
actual usb device (i.e. the tcp standalone server or spice client) doing
the filtering ...

cheers,
  Gerd

Re: [Qemu-devel] buildbot failure in qemu on default_x86_64_debian_6_0

[Stefan Hajnoczi]

On Fri, Jan 13, 2012 at 12:04 AM,   wrote:
> The Buildbot has detected a new failure on builder default_x86_64_debian_6_0 
> while building qemu.
> Full details are available at:
>  http://buildbot.b1-systems.de/qemu/builders/default_x86_64_debian_6_0/builds/151

This build failure has been fixed by Stefan Weil's
"virtfs-proxy-helper: Fix compilation on newer systems" patch, which
is queued in the trivial-patches tree.  I will send a pull request in
a couple of hours after testing has completed.

Stefan

Re: [Qemu-devel] [PATCH 1/7] hw/arm_mptimer.c: Turn ARM MPcore private timers into qdev devices

[Evgeny Voevodin]

On 12/05/2011 08:40 PM, Peter Maydell wrote:

-/* Return conversion factor from mpcore timer ticks to qemu timer ticks.  */
-static inline uint32_t mpcore_timer_scale(mpcore_timer_state *s)
-{
-return (((s->control>>  8)&  0xff) + 1) * 10;
-}


Dear Peter, could you please explain why such a conversion used to gain 
qemu ticks from mpcore timer ticks, actually why to multiply by 10?
AFAIK by default to get timer ticks QEMU uses host's time. Also cortex 
documentation says that mpcore timer tick interval should be calculated 
in this way: ((prescaler + 1) * (load + 1))/freq

Later mpcore_timer_reload uses this code to update QEMU ticks:


-s->tick += (int64_t)s->count * mpcore_timer_scale(s);


I see that equation has transformed to: (prescaler * load) * 10
As I understand, this means that arm core internal timer is working at 
frequency 10 times less (in ideal) then host.


--
Kind regards,
Evgeny Voevodin,
Leading Software Engineer,
ASWG, Moscow R&D center, Samsung Electronics
e-mail: e.voevo...@samsung.com

[Qemu-devel] buildbot failure in qemu on ppc-next_x86_64_debian_6_0

[qemu]

The Buildbot has detected a new failure on builder ppc-next_x86_64_debian_6_0 
while building qemu.
Full details are available at:
 
http://buildbot.b1-systems.de/qemu/builders/ppc-next_x86_64_debian_6_0/builds/151

Buildbot URL: http://buildbot.b1-systems.de/qemu/

Buildslave for this Build: yuzuki

Build Reason: The Nightly scheduler named 'nightly_ppc-next' triggered this 
build
Build Source Stamp: [branch ppc-next] HEAD
Blamelist: 

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

[Qemu-devel] buildbot failure in qemu on ppc-next_i386_debian_6_0

[qemu]

The Buildbot has detected a new failure on builder ppc-next_i386_debian_6_0 
while building qemu.
Full details are available at:
 http://buildbot.b1-systems.de/qemu/builders/ppc-next_i386_debian_6_0/builds/151

Buildbot URL: http://buildbot.b1-systems.de/qemu/

Buildslave for this Build: yuzuki

Build Reason: The Nightly scheduler named 'nightly_ppc-next' triggered this 
build
Build Source Stamp: [branch ppc-next] HEAD
Blamelist: 

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

[Qemu-devel] [PATCH] Endian fix an assertion in usb-msd

[Benjamin Herrenschmidt]

I stumbled across that one while debugging some
other issue... 

Signed-off-by: Benjamin Herrenschmidt 
---
 hw/usb-msd.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/usb-msd.c b/hw/usb-msd.c
index e427296..28271fc 100644
--- a/hw/usb-msd.c
+++ b/hw/usb-msd.c
@@ -195,7 +195,7 @@ static void usb_msd_send_status(MSDState *s, USBPacket *p)
 DPRINTF("Command status %d tag 0x%x, len %zd\n",
 s->csw.status, s->csw.tag, p->iov.size);
 
-assert(s->csw.sig == 0x53425355);
+assert(s->csw.sig == cpu_to_le32(0x53425355));
 len = MIN(sizeof(s->csw), p->iov.size);
 usb_packet_copy(p, &s->csw, len);
 memset(&s->csw, 0, sizeof(s->csw));

[Qemu-devel] [PATCH] Endian fixes for virtfs

[Benjamin Herrenschmidt]

This may not fix all of the endian problems in there but it's
enough to make it work with some SLOF version I'm working on.

Maybe more when I get the Linux client attached...

Signed-off-by: Benjamin Herrenschmidt 
---
 hw/9pfs/virtio-9p.c |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
index e6ba6ba..08445a1 100644
--- a/hw/9pfs/virtio-9p.c
+++ b/hw/9pfs/virtio-9p.c
@@ -1349,7 +1349,9 @@ static void v9fs_open(void *opaque)
 if (s->proto_version == V9FS_PROTO_2000L) {
 err = pdu_unmarshal(pdu, offset, "dd", &fid, &mode);
 } else {
-err = pdu_unmarshal(pdu, offset, "db", &fid, &mode);
+uint8_t modebyte;
+err = pdu_unmarshal(pdu, offset, "db", &fid, &modebyte);
+mode = modebyte;
 }
 if (err < 0) {
 goto out_nofid;
@@ -3261,9 +3263,9 @@ void handle_9p_output(VirtIODevice *vdev, VirtQueue *vq)
 
 ptr = pdu->elem.out_sg[0].iov_base;
 
-memcpy(&pdu->size, ptr, 4);
+pdu->size = le32_to_cpu(*(uint32_t *)ptr);
 pdu->id = ptr[4];
-memcpy(&pdu->tag, ptr + 5, 2);
+pdu->tag = le16_to_cpu(*(uint16_t *)(ptr + 5));
 qemu_co_queue_init(&pdu->complete);
 submit_pdu(s, pdu);
 }

[Qemu-devel] Question about tlb_flush

[陳韋任]

Hi all,

  When I looked at function tlb_flush (exec.c), I found its
second parameter "flush_global" is never used. In tlb_flush
comment, it says

  if flush_global is true, also flush global entries (not
  implemented yet)

Does anyone know what the global entries are? Thanks.

Regards,
chenwj

-- 
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj

Re: [Qemu-devel] icount and tb chaining

[陳韋任]

On Thu, Jan 12, 2012 at 11:00:43AM -0800, James Greensky wrote:
> Hello all, I have a question about icount and tb chaining that I hope
> somebody can clear up.  In cpu-exec.c, when the icount_decr.u16.low
> counter expires, it passes back the current tb as the next_tb and add
> a jump with the least significant bits = 2. This falls through to tb
> add jump, which then updates the jmp_first field of the current tb.
> why is this done? Thanks -Jim

  Could you elaborate on the whole sequence? I am not sure where should
I look into to answer your question. Thanks.

Regards,
chenwj

-- 
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj

[Qemu-devel] [PATCH v3 4/8] prep: qdev'ify Raven host bridge (SysBus)

[Andreas Färber]

Drop pci_prep_init() in favor of extended device state. Inspired by
patches from Hervé and Alex.

Assign the 4 IRQs from the board after device instantiation. This moves
the knowledge out of prep_pci and allows for future machines with
different IRQ wiring (IBM 40P). Suggested by Alex.

Signed-off-by: Andreas Färber 
Cc: Hervé Poussineau 
Cc: Alexander Graf 
Cc: Michael S. Tsirkin 
Cc: Anthony Liguori 
---
 hw/ppc_prep.c |   23 +-
 hw/prep_pci.c |   67 +++-
 hw/prep_pci.h |   11 -
 3 files changed, 63 insertions(+), 38 deletions(-)
 delete mode 100644 hw/prep_pci.h

diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c
index dec059a..747539f 100644
--- a/hw/ppc_prep.c
+++ b/hw/ppc_prep.c
@@ -29,7 +29,7 @@
 #include "sysemu.h"
 #include "isa.h"
 #include "pci.h"
-#include "prep_pci.h"
+#include "pci_host.h"
 #include "usb-ohci.h"
 #include "ppc.h"
 #include "boards.h"
@@ -522,6 +522,9 @@ static void ppc_prep_init (ram_addr_t ram_size,
 MemoryRegion *bios = g_new(MemoryRegion, 1);
 uint32_t kernel_base, initrd_base;
 long kernel_size, initrd_size;
+DeviceState *dev;
+SysBusDevice *sys;
+PCIHostState *pcihost;
 PCIBus *pci_bus;
 ISABus *isa_bus;
 qemu_irq *i8259;
@@ -633,7 +636,23 @@ static void ppc_prep_init (ram_addr_t ram_size,
 /* Hmm, prep has no pci-isa bridge ??? */
 isa_bus = isa_bus_new(NULL, get_system_io());
 i8259 = i8259_init(isa_bus, first_cpu->irq_inputs[PPC6xx_INPUT_INT]);
-pci_bus = pci_prep_init(i8259, get_system_memory(), get_system_io());
+
+dev = qdev_create(NULL, "raven-pcihost");
+sys = sysbus_from_qdev(dev);
+pcihost = DO_UPCAST(PCIHostState, busdev, sys);
+pcihost->address_space = get_system_memory();
+qdev_init_nofail(dev);
+qdev_property_add_child(qdev_get_root(), "raven", dev, NULL);
+pci_bus = (PCIBus *)qdev_get_child_bus(dev, "pci.0");
+if (pci_bus == NULL) {
+fprintf(stderr, "Couldn't create PCI host controller.\n");
+exit(1);
+}
+sysbus_connect_irq(&pcihost->busdev, 0, i8259[9]);
+sysbus_connect_irq(&pcihost->busdev, 1, i8259[11]);
+sysbus_connect_irq(&pcihost->busdev, 2, i8259[9]);
+sysbus_connect_irq(&pcihost->busdev, 3, i8259[11]);
+
 isa_bus_irqs(isa_bus, i8259);
 //pci_bus = i440fx_init();
 /* Register 8 MB of ISA IO space (needed for non-contiguous map) */
diff --git a/hw/prep_pci.c b/hw/prep_pci.c
index 5970196..ccd0832 100644
--- a/hw/prep_pci.c
+++ b/hw/prep_pci.c
@@ -25,9 +25,12 @@
 #include "hw.h"
 #include "pci.h"
 #include "pci_host.h"
-#include "prep_pci.h"
+#include "exec-memory.h"
 
-typedef PCIHostState PREPPCIState;
+typedef struct PRePPCIState {
+PCIHostState host_state;
+qemu_irq irq[4];
+} PREPPCIState;
 
 typedef struct RavenPCIState {
 PCIDevice dev;
@@ -52,7 +55,7 @@ static void ppc_pci_io_write(void *opaque, target_phys_addr_t 
addr,
 case 1:
 case 2:
 case 4:
-pci_data_write(s->bus, PPC_PCIIO_config(addr), val, size);
+pci_data_write(s->host_state.bus, PPC_PCIIO_config(addr), val, size);
 break;
 default:
 abort();
@@ -67,7 +70,7 @@ static uint64_t ppc_pci_io_read(void *opaque, 
target_phys_addr_t addr,
 case 1:
 case 2:
 case 4:
-return pci_data_read(s->bus, PPC_PCIIO_config(addr), size);
+return pci_data_read(s->host_state.bus, PPC_PCIIO_config(addr), size);
 default:
 abort();
 }
@@ -88,38 +91,43 @@ static void prep_set_irq(void *opaque, int irq_num, int 
level)
 {
 qemu_irq *pic = opaque;
 
-qemu_set_irq(pic[(irq_num & 1) ? 11 : 9] , level);
+qemu_set_irq(pic[irq_num] , level);
 }
 
-PCIBus *pci_prep_init(qemu_irq *pic,
-  MemoryRegion *address_space_mem,
-  MemoryRegion *address_space_io)
+static int raven_pcihost_init(SysBusDevice *dev)
 {
-PREPPCIState *s;
+PCIHostState *h = FROM_SYSBUS(PCIHostState, dev);
+PREPPCIState *s = DO_UPCAST(PREPPCIState, host_state, h);
+MemoryRegion *address_space_mem = get_system_memory();
+MemoryRegion *address_space_io = get_system_io();
+PCIBus *bus;
+int i;
+
+for (i = 0; i < 4; i++) {
+sysbus_init_irq(dev, &s->irq[i]);
+}
 
-s = g_malloc0(sizeof(PREPPCIState));
-s->bus = pci_register_bus(NULL, "pci",
-  prep_set_irq, prep_map_irq, pic,
-  address_space_mem,
-  address_space_io,
-  0, 4);
+bus = pci_register_bus(&h->busdev.qdev, NULL,
+   prep_set_irq, prep_map_irq, s->irq,
+   address_space_mem, address_space_io, 0, 4);
+h->bus = bus;
 
-memory_region_init_io(&s->conf_mem, &pci_host_conf_be_ops, s,
+memory_region_init_io(&h->conf_mem, &pci_host_conf_be_ops, s,
   "pci-conf-idx", 1);
-memory_region_add_subregio

Re: [Qemu-devel] [PATCH v3 0/8] qdev'ify PReP PCI host bridge and add PCI-to-ISA bridge

[Andreas Färber]

Am 13.01.2012 04:09, schrieb Andreas Färber:
> Hello,
> 
> Here's an updated initial qdev'ification series for PReP, as prerequisite
> for Anthony's second QOM series.

Available from
http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/prep-queue
on top of all patches needed for testing.

> Andreas Färber (8):
>   prep: qdev'ify Raven host bridge (PCIDevice)
>   prep_pci: Simplify I/O endianness
>   prep_pci: Update I/O to MemoryRegion ops
>   prep: qdev'ify Raven host bridge (SysBus)
>   MAINTAINERS: Add PCI host bridge files to PReP machine
>   prep: Add i82374 DMA emulation
>   prep: Add i82378 PCI-to-ISA bridge emulation
>   prep: Use i82378 PCI->ISA bridge for 'prep' machine
> 
>  MAINTAINERS |1 +
>  Makefile.objs   |2 +
>  default-configs/ppc-softmmu.mak |3 +
>  hw/i82374.c |  154 
>  hw/i82378.c |  252 
> +++
>  hw/pci_ids.h|1 +
>  hw/ppc_prep.c   |   77 +---
>  hw/prep_pci.c   |  181 +---
>  hw/prep_pci.h   |   11 --
>  9 files changed, 553 insertions(+), 129 deletions(-)
>  create mode 100644 hw/i82374.c
>  create mode 100644 hw/i82378.c
>  delete mode 100644 hw/prep_pci.h

[Qemu-devel] [PATCH v3 3/8] prep_pci: Update I/O to MemoryRegion ops

[Andreas Färber]

Convert to new-style read/write callbacks.

Signed-off-by: Andreas Färber 
Cc: Michael S. Tsirkin 
Cc: Alexander Graf 
Cc: Avi Kivity 
Cc: Benoît Canet 
---
 hw/prep_pci.c |   61 +---
 1 files changed, 23 insertions(+), 38 deletions(-)

diff --git a/hw/prep_pci.c b/hw/prep_pci.c
index edfb25d..5970196 100644
--- a/hw/prep_pci.c
+++ b/hw/prep_pci.c
@@ -44,53 +44,38 @@ static inline uint32_t PPC_PCIIO_config(target_phys_addr_t 
addr)
 return (addr & 0x7ff) |  (i << 11);
 }
 
-static void PPC_PCIIO_writeb (void *opaque, target_phys_addr_t addr, uint32_t 
val)
+static void ppc_pci_io_write(void *opaque, target_phys_addr_t addr,
+ uint64_t val, unsigned int size)
 {
 PREPPCIState *s = opaque;
-pci_data_write(s->bus, PPC_PCIIO_config(addr), val, 1);
-}
-
-static void PPC_PCIIO_writew (void *opaque, target_phys_addr_t addr, uint32_t 
val)
-{
-PREPPCIState *s = opaque;
-pci_data_write(s->bus, PPC_PCIIO_config(addr), val, 2);
-}
-
-static void PPC_PCIIO_writel (void *opaque, target_phys_addr_t addr, uint32_t 
val)
-{
-PREPPCIState *s = opaque;
-pci_data_write(s->bus, PPC_PCIIO_config(addr), val, 4);
-}
-
-static uint32_t PPC_PCIIO_readb (void *opaque, target_phys_addr_t addr)
-{
-PREPPCIState *s = opaque;
-uint32_t val;
-val = pci_data_read(s->bus, PPC_PCIIO_config(addr), 1);
-return val;
-}
-
-static uint32_t PPC_PCIIO_readw (void *opaque, target_phys_addr_t addr)
-{
-PREPPCIState *s = opaque;
-uint32_t val;
-val = pci_data_read(s->bus, PPC_PCIIO_config(addr), 2);
-return val;
+switch (size) {
+case 1:
+case 2:
+case 4:
+pci_data_write(s->bus, PPC_PCIIO_config(addr), val, size);
+break;
+default:
+abort();
+}
 }
 
-static uint32_t PPC_PCIIO_readl (void *opaque, target_phys_addr_t addr)
+static uint64_t ppc_pci_io_read(void *opaque, target_phys_addr_t addr,
+unsigned int size)
 {
 PREPPCIState *s = opaque;
-uint32_t val;
-val = pci_data_read(s->bus, PPC_PCIIO_config(addr), 4);
-return val;
+switch (size) {
+case 1:
+case 2:
+case 4:
+return pci_data_read(s->bus, PPC_PCIIO_config(addr), size);
+default:
+abort();
+}
 }
 
 static const MemoryRegionOps PPC_PCIIO_ops = {
-.old_mmio = {
-.read = { PPC_PCIIO_readb, PPC_PCIIO_readw, PPC_PCIIO_readl, },
-.write = { PPC_PCIIO_writeb, PPC_PCIIO_writew, PPC_PCIIO_writel, },
-},
+.read = ppc_pci_io_read,
+.write = ppc_pci_io_write,
 .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
-- 
1.7.7

[Qemu-devel] [PATCH v3 7/8] prep: Add i82378 PCI-to-ISA bridge emulation

[Andreas Färber]

Prepare Intel 82378 emulation for use by PReP platforms.

Signed-off-by: Hervé Poussineau 

Create ISA bus in this device (suggested by Markus).
Rebase onto Memory API, mark memory ops as Little Endian.
Add VMState.

Signed-off-by: Andreas Färber 
Cc: Markus Armbruster 
Cc: Alexander Graf 
Cc: Jan Kiszka 
---
 Makefile.objs   |1 +
 default-configs/ppc-softmmu.mak |2 +
 hw/i82378.c |  252 +++
 hw/pci_ids.h|1 +
 4 files changed, 256 insertions(+), 0 deletions(-)
 create mode 100644 hw/i82378.c

diff --git a/Makefile.objs b/Makefile.objs
index 26af1f2..656ae62 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -225,6 +225,7 @@ hw-obj-$(CONFIG_I8259) += i8259.o
 
 # PPC devices
 hw-obj-$(CONFIG_PREP_PCI) += prep_pci.o
+hw-obj-$(CONFIG_I82378) += i82378.o
 # Mac shared devices
 hw-obj-$(CONFIG_MACIO) += macio.o
 hw-obj-$(CONFIG_CUDA) += cuda.o
diff --git a/default-configs/ppc-softmmu.mak b/default-configs/ppc-softmmu.mak
index e5905d5..1fe9c6d 100644
--- a/default-configs/ppc-softmmu.mak
+++ b/default-configs/ppc-softmmu.mak
@@ -14,7 +14,9 @@ CONFIG_DMA=y
 CONFIG_I82374=y
 CONFIG_OPENPIC=y
 CONFIG_PREP_PCI=y
+CONFIG_I82378=y
 CONFIG_MACIO=y
+CONFIG_PCSPK=y
 CONFIG_CUDA=y
 CONFIG_ADB=y
 CONFIG_MAC_NVRAM=y
diff --git a/hw/i82378.c b/hw/i82378.c
new file mode 100644
index 000..3808a90
--- /dev/null
+++ b/hw/i82378.c
@@ -0,0 +1,252 @@
+/*
+ * QEMU Intel i82378 emulation (PCI to ISA bridge)
+ *
+ * Copyright (c) 2010-2011 Hervé Poussineau
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+ */
+
+#include "pci.h"
+#include "pc.h"
+
+//#define DEBUG_I82378
+
+#ifdef DEBUG_I82378
+#define DPRINTF(fmt, ...) \
+do { fprintf(stderr, "i82378: " fmt , ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) \
+do {} while (0)
+#endif
+
+#define BADF(fmt, ...) \
+do { fprintf(stderr, "i82378 ERROR: " fmt , ## __VA_ARGS__); } while (0)
+
+typedef struct I82378State {
+qemu_irq out[2];
+MemoryRegion io;
+MemoryRegion mem;
+} I82378State;
+
+typedef struct PCIi82378State {
+PCIDevice pci_dev;
+uint32_t isa_io_base;
+uint32_t isa_mem_base;
+I82378State state;
+} PCIi82378State;
+
+static const VMStateDescription vmstate_pci_i82378 = {
+.name = "pci-i82378",
+.version_id = 0,
+.minimum_version_id = 0,
+.fields = (VMStateField[]) {
+VMSTATE_PCI_DEVICE(pci_dev, PCIi82378State),
+VMSTATE_END_OF_LIST()
+},
+};
+
+static void i82378_io_write(void *opaque, target_phys_addr_t addr,
+uint64_t value, unsigned int size)
+{
+switch (size) {
+case 1:
+DPRINTF("%s: " TARGET_FMT_plx "=%02" PRIx64 "\n", __func__,
+addr, value);
+cpu_outb(addr, value);
+break;
+case 2:
+DPRINTF("%s: " TARGET_FMT_plx "=%04" PRIx64 "\n", __func__,
+addr, value);
+cpu_outw(addr, value);
+break;
+case 4:
+DPRINTF("%s: " TARGET_FMT_plx "=%08" PRIx64 "\n", __func__,
+addr, value);
+cpu_outl(addr, value);
+break;
+default:
+abort();
+}
+}
+
+static uint64_t i82378_io_read(void *opaque, target_phys_addr_t addr,
+   unsigned int size)
+{
+DPRINTF("%s: " TARGET_FMT_plx "\n", __func__, addr);
+switch (size) {
+case 1:
+return cpu_inb(addr);
+case 2:
+return cpu_inw(addr);
+case 4:
+return cpu_inl(addr);
+default:
+abort();
+}
+}
+
+static const MemoryRegionOps i82378_io_ops = {
+.read = i82378_io_read,
+.write = i82378_io_write,
+.endianness = DEVICE_LITTLE_ENDIAN,
+};
+
+static void i82378_mem_write(void *opaque, target_phys_addr_t addr,
+ uint64_t value, unsigned int size)
+{
+switch (size) {
+case 1:
+DPRINTF("%s: " TARGET_FMT_plx "=%02" PRIx64 "\n", __func__,
+addr, value);
+cpu_outb(addr, value);
+break;
+case 2:
+DPRINTF("%s: " TARGET_FMT_plx "=%04" PRIx64 "\n", __func__,
+addr, value);
+cpu_outw(addr, value);
+break;
+case 4:
+DPRINTF("%s: " TARGET_FMT_plx "=%08" PRIx64 "\n", __func__,
+addr, value);
+cpu_outl(addr, value);
+break;
+

[Qemu-devel] [PATCH v3 2/8] prep_pci: Simplify I/O endianness

[Andreas Färber]

The prep PowerPC CPU is Big Endian. An explicit byte swap therefore
effectively becomes Little Endian.

Remove explicit byte swaps and mark as Little Endian.

Signed-off-by: Andreas Färber 
Cc: Alexander Graf 
Cc: Michael S. Tsirkin 
---
 hw/prep_pci.c |6 +-
 1 files changed, 1 insertions(+), 5 deletions(-)

diff --git a/hw/prep_pci.c b/hw/prep_pci.c
index 741b273..edfb25d 100644
--- a/hw/prep_pci.c
+++ b/hw/prep_pci.c
@@ -53,14 +53,12 @@ static void PPC_PCIIO_writeb (void *opaque, 
target_phys_addr_t addr, uint32_t va
 static void PPC_PCIIO_writew (void *opaque, target_phys_addr_t addr, uint32_t 
val)
 {
 PREPPCIState *s = opaque;
-val = bswap16(val);
 pci_data_write(s->bus, PPC_PCIIO_config(addr), val, 2);
 }
 
 static void PPC_PCIIO_writel (void *opaque, target_phys_addr_t addr, uint32_t 
val)
 {
 PREPPCIState *s = opaque;
-val = bswap32(val);
 pci_data_write(s->bus, PPC_PCIIO_config(addr), val, 4);
 }
 
@@ -77,7 +75,6 @@ static uint32_t PPC_PCIIO_readw (void *opaque, 
target_phys_addr_t addr)
 PREPPCIState *s = opaque;
 uint32_t val;
 val = pci_data_read(s->bus, PPC_PCIIO_config(addr), 2);
-val = bswap16(val);
 return val;
 }
 
@@ -86,7 +83,6 @@ static uint32_t PPC_PCIIO_readl (void *opaque, 
target_phys_addr_t addr)
 PREPPCIState *s = opaque;
 uint32_t val;
 val = pci_data_read(s->bus, PPC_PCIIO_config(addr), 4);
-val = bswap32(val);
 return val;
 }
 
@@ -95,7 +91,7 @@ static const MemoryRegionOps PPC_PCIIO_ops = {
 .read = { PPC_PCIIO_readb, PPC_PCIIO_readw, PPC_PCIIO_readl, },
 .write = { PPC_PCIIO_writeb, PPC_PCIIO_writew, PPC_PCIIO_writel, },
 },
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };
 
 static int prep_map_irq(PCIDevice *pci_dev, int irq_num)
-- 
1.7.7

[Qemu-devel] [PATCH v3 6/8] prep: Add i82374 DMA emulation

[Andreas Färber]

Prepare Intel 82374 emulation for use by Intel 82378 PCI->ISA bridge.

Signed-off-by: Hervé Poussineau 

Confine to CONFIG_I82374. Add VMState.

Signed-off-by: Andreas Färber 
---
 Makefile.objs   |1 +
 default-configs/ppc-softmmu.mak |1 +
 hw/i82374.c |  154 +++
 3 files changed, 156 insertions(+), 0 deletions(-)
 create mode 100644 hw/i82374.c

diff --git a/Makefile.objs b/Makefile.objs
index 4f6d26c..26af1f2 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -215,6 +215,7 @@ hw-obj-$(CONFIG_FDC) += fdc.o
 hw-obj-$(CONFIG_ACPI) += acpi.o acpi_piix4.o
 hw-obj-$(CONFIG_APM) += pm_smbus.o apm.o
 hw-obj-$(CONFIG_DMA) += dma.o
+hw-obj-$(CONFIG_I82374) += i82374.o
 hw-obj-$(CONFIG_HPET) += hpet.o
 hw-obj-$(CONFIG_APPLESMC) += applesmc.o
 hw-obj-$(CONFIG_SMARTCARD) += usb-ccid.o ccid-card-passthru.o
diff --git a/default-configs/ppc-softmmu.mak b/default-configs/ppc-softmmu.mak
index c85cdce..e5905d5 100644
--- a/default-configs/ppc-softmmu.mak
+++ b/default-configs/ppc-softmmu.mak
@@ -11,6 +11,7 @@ CONFIG_I8254=y
 CONFIG_PCKBD=y
 CONFIG_FDC=y
 CONFIG_DMA=y
+CONFIG_I82374=y
 CONFIG_OPENPIC=y
 CONFIG_PREP_PCI=y
 CONFIG_MACIO=y
diff --git a/hw/i82374.c b/hw/i82374.c
new file mode 100644
index 000..616d1fc
--- /dev/null
+++ b/hw/i82374.c
@@ -0,0 +1,154 @@
+/*
+ * QEMU Intel 82374 emulation (Enhanced DMA controller)
+ *
+ * Copyright (c) 2010 Hervé Poussineau
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "isa.h"
+
+//#define DEBUG_I82374
+
+#ifdef DEBUG_I82374
+#define DPRINTF(fmt, ...) \
+do { fprintf(stderr, "i82374: " fmt , ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) \
+do {} while (0)
+#endif
+#define BADF(fmt, ...) \
+do { fprintf(stderr, "i82374 ERROR: " fmt , ## __VA_ARGS__); } while (0)
+
+typedef struct I82374State {
+uint8_t commands[8];
+} I82374State;
+
+static const VMStateDescription vmstate_i82374 = {
+.name = "i82374",
+.version_id = 0,
+.minimum_version_id = 0,
+.fields = (VMStateField[]) {
+VMSTATE_UINT8_ARRAY(commands, I82374State, 8),
+VMSTATE_END_OF_LIST()
+},
+};
+
+static uint32_t i82374_read_isr(void *opaque, uint32_t nport)
+{
+uint32_t val = 0;
+
+BADF("%s: %08x\n", __func__, nport);
+
+DPRINTF("%s: %08x=%08x\n", __func__, nport, val);
+return val;
+}
+
+static void i82374_write_command(void *opaque, uint32_t nport, uint32_t data)
+{
+DPRINTF("%s: %08x=%08x\n", __func__, nport, data);
+
+if (data != 0x42) {
+/* Not Stop S/G command */
+BADF("%s: %08x=%08x\n", __func__, nport, data);
+}
+}
+
+static uint32_t i82374_read_status(void *opaque, uint32_t nport)
+{
+uint32_t val = 0;
+
+BADF("%s: %08x\n", __func__, nport);
+
+DPRINTF("%s: %08x=%08x\n", __func__, nport, val);
+return val;
+}
+
+static void i82374_write_descriptor(void *opaque, uint32_t nport, uint32_t 
data)
+{
+DPRINTF("%s: %08x=%08x\n", __func__, nport, data);
+
+BADF("%s: %08x=%08x\n", __func__, nport, data);
+}
+
+static uint32_t i82374_read_descriptor(void *opaque, uint32_t nport)
+{
+uint32_t val = 0;
+
+BADF("%s: %08x\n", __func__, nport);
+
+DPRINTF("%s: %08x=%08x\n", __func__, nport, val);
+return val;
+}
+
+static void i82374_init(I82374State *s)
+{
+DMA_init(1, NULL);
+memset(s->commands, 0, sizeof(s->commands));
+}
+
+typedef struct ISAi82374State {
+ISADevice dev;
+uint32_t iobase;
+I82374State state;
+} ISAi82374State;
+
+static const VMStateDescription vmstate_isa_i82374 = {
+.name = "isa-i82374",
+.version_id = 0,
+.minimum_version_id = 0,
+.fields = (VMStateField[]) {
+VMSTATE_STRUCT(state, ISAi82374State, 0, vmstate_i82374, I82374State),
+VMSTATE_END_OF_LIST()
+},
+};
+
+static int i82374_isa_init(ISADevice *dev)
+{
+ISAi82374State *isa = DO_UPCAST(ISAi82374State, dev, dev);
+I82374St

[Qemu-devel] [PATCH v3 1/8] prep: qdev'ify Raven host bridge (PCIDevice)

[Andreas Färber]

Move initialization of vendor ID, etc. to PCIDeviceInfo.
Introduce VMState.

Signed-off-by: Andreas Färber 
Cc: Hervé Poussineau 
Cc: Michael S. Tsirkin 
Cc: Alexander Graf 
Cc: Anthony Liguori 
---
 hw/prep_pci.c |   55 ++-
 1 files changed, 46 insertions(+), 9 deletions(-)

diff --git a/hw/prep_pci.c b/hw/prep_pci.c
index ea9fb69..741b273 100644
--- a/hw/prep_pci.c
+++ b/hw/prep_pci.c
@@ -29,6 +29,10 @@
 
 typedef PCIHostState PREPPCIState;
 
+typedef struct RavenPCIState {
+PCIDevice dev;
+} RavenPCIState;
+
 static inline uint32_t PPC_PCIIO_config(target_phys_addr_t addr)
 {
 int i;
@@ -111,7 +115,6 @@ PCIBus *pci_prep_init(qemu_irq *pic,
   MemoryRegion *address_space_io)
 {
 PREPPCIState *s;
-PCIDevice *d;
 
 s = g_malloc0(sizeof(PREPPCIState));
 s->bus = pci_register_bus(NULL, "pci",
@@ -133,16 +136,50 @@ PCIBus *pci_prep_init(qemu_irq *pic,
 memory_region_init_io(&s->mmcfg, &PPC_PCIIO_ops, s, "pciio", 0x0040);
 memory_region_add_subregion(address_space_mem, 0x8080, &s->mmcfg);
 
-/* PCI host bridge */
-d = pci_register_device(s->bus, "PREP Host Bridge - Motorola Raven",
-sizeof(PCIDevice), 0, NULL, NULL);
-pci_config_set_vendor_id(d->config, PCI_VENDOR_ID_MOTOROLA);
-pci_config_set_device_id(d->config, PCI_DEVICE_ID_MOTOROLA_RAVEN);
-d->config[0x08] = 0x00; // revision
-pci_config_set_class(d->config, PCI_CLASS_BRIDGE_HOST);
+pci_create_simple(s->bus, 0, "raven");
+
+return s->bus;
+}
+
+static int raven_init(PCIDevice *d)
+{
 d->config[0x0C] = 0x08; // cache_line_size
 d->config[0x0D] = 0x10; // latency_timer
 d->config[0x34] = 0x00; // capabilities_pointer
 
-return s->bus;
+return 0;
 }
+
+static const VMStateDescription vmstate_raven = {
+.name = "raven",
+.version_id = 0,
+.minimum_version_id = 0,
+.fields = (VMStateField[]) {
+VMSTATE_PCI_DEVICE(dev, RavenPCIState),
+VMSTATE_END_OF_LIST()
+},
+};
+
+static PCIDeviceInfo raven_info = {
+.qdev.name = "raven",
+.qdev.desc = "PReP Host Bridge - Motorola Raven",
+.qdev.size = sizeof(RavenPCIState),
+.qdev.vmsd = &vmstate_raven,
+.qdev.no_user = 1,
+.no_hotplug = 1,
+.init = raven_init,
+.vendor_id = PCI_VENDOR_ID_MOTOROLA,
+.device_id = PCI_DEVICE_ID_MOTOROLA_RAVEN,
+.revision = 0x00,
+.class_id = PCI_CLASS_BRIDGE_HOST,
+.qdev.props = (Property[]) {
+DEFINE_PROP_END_OF_LIST()
+},
+};
+
+static void raven_register_devices(void)
+{
+pci_qdev_register(&raven_info);
+}
+
+device_init(raven_register_devices)
-- 
1.7.7

[Qemu-devel] [PATCH v3 8/8] prep: Use i82378 PCI->ISA bridge for 'prep' machine

[Andreas Färber]

Speaker I/O, ISA bus, i8259 PIC, RTC and DMA are no longer set up
individually by the machine. Effectively, no-op speaker I/O is replaced
by pcspk; PIT and i82374 DMA are introduced.

Signed-off-by: Hervé Poussineau 

Remove related dead, alternative code.
Access i8259 IRQs via ISA bus to resolve cyclic dependency with PCI
host bridge.

Signed-off-by: Andreas Färber 
Cc: Alexander Graf 
Cc: Jan Kiszka 
---
 hw/ppc_prep.c |   54 +++---
 1 files changed, 11 insertions(+), 43 deletions(-)

diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c
index 747539f..9485d45 100644
--- a/hw/ppc_prep.c
+++ b/hw/ppc_prep.c
@@ -83,37 +83,9 @@ static const int ide_irq[2] = { 13, 13 };
 static uint32_t ne2000_io[NE2000_NB_MAX] = { 0x300, 0x320, 0x340, 0x360, 
0x280, 0x380 };
 static int ne2000_irq[NE2000_NB_MAX] = { 9, 10, 11, 3, 4, 5 };
 
-//static ISADevice *pit;
-
 /* ISA IO ports bridge */
 #define PPC_IO_BASE 0x8000
 
-#if 0
-/* Speaker port 0x61 */
-static int speaker_data_on;
-static int dummy_refresh_clock;
-#endif
-
-static void speaker_ioport_write (void *opaque, uint32_t addr, uint32_t val)
-{
-#if 0
-speaker_data_on = (val >> 1) & 1;
-pit_set_gate(pit, 2, val & 1);
-#endif
-}
-
-static uint32_t speaker_ioport_read (void *opaque, uint32_t addr)
-{
-#if 0
-int out;
-out = pit_get_out(pit, 2, qemu_get_clock_ns(vm_clock));
-dummy_refresh_clock ^= 1;
-return (speaker_data_on << 1) | pit_get_gate(pit, 2) | (out << 5) |
-(dummy_refresh_clock << 4);
-#endif
-return 0;
-}
-
 /* PCI intack register */
 /* Read-only register (?) */
 static void PPC_intack_write (void *opaque, target_phys_addr_t addr,
@@ -526,6 +498,7 @@ static void ppc_prep_init (ram_addr_t ram_size,
 SysBusDevice *sys;
 PCIHostState *pcihost;
 PCIBus *pci_bus;
+PCIDevice *pci;
 ISABus *isa_bus;
 qemu_irq *i8259;
 qemu_irq *cpu_exit_irq;
@@ -629,13 +602,9 @@ static void ppc_prep_init (ram_addr_t ram_size,
 }
 }
 
-isa_mem_base = 0xc000;
 if (PPC_INPUT(env) != PPC_FLAGS_INPUT_6xx) {
 hw_error("Only 6xx bus is supported on PREP machine\n");
 }
-/* Hmm, prep has no pci-isa bridge ??? */
-isa_bus = isa_bus_new(NULL, get_system_io());
-i8259 = i8259_init(isa_bus, first_cpu->irq_inputs[PPC6xx_INPUT_INT]);
 
 dev = qdev_create(NULL, "raven-pcihost");
 sys = sysbus_from_qdev(dev);
@@ -648,13 +617,21 @@ static void ppc_prep_init (ram_addr_t ram_size,
 fprintf(stderr, "Couldn't create PCI host controller.\n");
 exit(1);
 }
+
+/* PCI -> ISA bridge */
+pci = pci_create_simple(pci_bus, PCI_DEVFN(1, 0), "i82378");
+cpu_exit_irq = qemu_allocate_irqs(cpu_request_exit, NULL, 1);
+qdev_connect_gpio_out(&pci->qdev, 0,
+  first_cpu->irq_inputs[PPC6xx_INPUT_INT]);
+qdev_connect_gpio_out(&pci->qdev, 1, *cpu_exit_irq);
+isa_bus = DO_UPCAST(ISABus, qbus, qdev_get_child_bus(&pci->qdev, "isa.0"));
+
+i8259 = isa_bus->irqs;
 sysbus_connect_irq(&pcihost->busdev, 0, i8259[9]);
 sysbus_connect_irq(&pcihost->busdev, 1, i8259[11]);
 sysbus_connect_irq(&pcihost->busdev, 2, i8259[9]);
 sysbus_connect_irq(&pcihost->busdev, 3, i8259[11]);
 
-isa_bus_irqs(isa_bus, i8259);
-//pci_bus = i440fx_init();
 /* Register 8 MB of ISA IO space (needed for non-contiguous map) */
 memory_region_init_io(PPC_io_memory, &PPC_prep_io_ops, sysctrl,
   "ppc-io", 0x0080);
@@ -662,9 +639,6 @@ static void ppc_prep_init (ram_addr_t ram_size,
 
 /* init basic PC hardware */
 pci_vga_init(pci_bus);
-//openpic = openpic_init(0x, 0xF000, 1);
-//pit = pit_init(0x40, 0);
-rtc_init(isa_bus, 2000, NULL);
 
 if (serial_hds[0])
 serial_isa_init(isa_bus, 0, serial_hds[0]);
@@ -691,9 +665,6 @@ static void ppc_prep_init (ram_addr_t ram_size,
 }
 isa_create_simple(isa_bus, "i8042");
 
-cpu_exit_irq = qemu_allocate_irqs(cpu_request_exit, NULL, 1);
-DMA_init(1, cpu_exit_irq);
-
 //SB16_init();
 
 for(i = 0; i < MAX_FD; i++) {
@@ -701,9 +672,6 @@ static void ppc_prep_init (ram_addr_t ram_size,
 }
 fdctrl_init_isa(isa_bus, fd);
 
-/* Register speaker port */
-register_ioport_read(0x61, 1, 1, speaker_ioport_read, NULL);
-register_ioport_write(0x61, 1, 1, speaker_ioport_write, NULL);
 /* Register fake IO ports for PREP */
 sysctrl->reset_irq = first_cpu->irq_inputs[PPC6xx_INPUT_HRESET];
 register_ioport_read(0x398, 2, 1, &PREP_io_read, sysctrl);
-- 
1.7.7

[Qemu-devel] [PATCH v3 0/8] qdev'ify PReP PCI host bridge and add PCI-to-ISA bridge

[Andreas Färber]

Hello,

Here's an updated initial qdev'ification series for PReP, as prerequisite
for Anthony's second QOM series.

As stated before, this is NOT a complete conversion of all PReP devices
and of all those shared with x86. Please comment on what's there, not on
what may be done, too. I'm sitting on these patches for over a year now,
so let's start getting some of it merged so that we can move on with QOM
and get some of the design issues fixed that kept the pc87312 Super I/O
and 40P machine from getting merged in the first place!

Regards,
Andreas

Changes since v2:
* Simplify I/O byte swaps.
* Convert I/O from old_mmio to MemoryRegion ops.
* Drop pci_prep_init() and instantiate the PCI host bridge in the machine,
  reintroducing PREPPCIState extension.
* Connect IRQs via qdev after instantiating. Suggested by Alex.
* Add a rebased PCI-to-ISA-bridge from the 40P series on top, to show why
  some suggestions from v2 and IRC don't work out.
  * Merge fix-up by Hervé: Add indirection for late-connected out[0] IRQ.
  * Add VMState for i82374 and i82378.
  * From i82378 drop the I/O address translation duplicated from the board.
  * Rebase i82378 onto Memory API.
  http://patchwork.ozlabs.org/patch/100250/
  http://patchwork.ozlabs.org/patch/100272/
* Add new patch from Hervé to wire up the PCI-to-ISA bridge for 'prep'.

Changes since v1:
* Use the new .vendor_id etc. in PCIDeviceInfo
* Rename from PRePPCI to Raven, adopt naming scheme from i440FX
* Rebase onto multiple Memory API conversions
* Split into PCIDevice and SysBus patches, leave out PREPPCIState changes
http://patchwork.ozlabs.org/patch/100268/

Cc: Hervé Poussineau 
Cc: Anthony Liguori 
Cc: Alexander Graf 

Andreas Färber (8):
  prep: qdev'ify Raven host bridge (PCIDevice)
  prep_pci: Simplify I/O endianness
  prep_pci: Update I/O to MemoryRegion ops
  prep: qdev'ify Raven host bridge (SysBus)
  MAINTAINERS: Add PCI host bridge files to PReP machine
  prep: Add i82374 DMA emulation
  prep: Add i82378 PCI-to-ISA bridge emulation
  prep: Use i82378 PCI->ISA bridge for 'prep' machine

 MAINTAINERS |1 +
 Makefile.objs   |2 +
 default-configs/ppc-softmmu.mak |3 +
 hw/i82374.c |  154 
 hw/i82378.c |  252 +++
 hw/pci_ids.h|1 +
 hw/ppc_prep.c   |   77 +---
 hw/prep_pci.c   |  181 +---
 hw/prep_pci.h   |   11 --
 9 files changed, 553 insertions(+), 129 deletions(-)
 create mode 100644 hw/i82374.c
 create mode 100644 hw/i82378.c
 delete mode 100644 hw/prep_pci.h

-- 
1.7.7

[Qemu-devel] [PATCH v3 5/8] MAINTAINERS: Add PCI host bridge files to PReP machine

[Andreas Färber]

Signed-off-by: Andreas Färber 
Acked-by: Alexander Graf 
---
 MAINTAINERS |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index de2a916..148f0d2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -307,6 +307,7 @@ PReP
 M: Andreas Färber 
 S: Odd Fixes
 F: hw/ppc_prep.c
+F: hw/prep_pci.[hc]
 
 SH4 Machines
 
-- 
1.7.7

Re: [Qemu-devel] [PATCH 0/2][RFC] postcopy migration: Linux char device for postcopy

[Benoit Hudzia]

Hi,

Sorry to jump to hijack the thread  like that , however i would like
to just to inform you  that we recently achieve a milestone out of the
research project I'm leading. We enhanced KVM in order to deliver
post copy live migration using RDMA at kernel level.

Few point on the architecture of the system :

* RDMA communication engine in kernel ( you can use soft iwarp or soft
ROCE if you don't have hardware acceleration, however we also support
standard RDMA enabled NIC) .
* Naturally Page are transferred with Zerop copy protocol
* Leverage the async page fault system.
* Pre paging / faulting
* No context switch as everything is handled within kernel and using
the page fault system.
* Hybrid migration ( pre + post copy) available
* Rely on an independent Kernel Module
* No modification to the KVM kernel Module
* Minimal Modification to the Qemu-Kvm code
* We plan to add the page prioritization algo in order to optimise the
pre paging algo and background transfer


You can learn a little bit more and see a demo here:
http://tinyurl.com/8xa2bgl
I hope to be able to provide more detail on the design soon. As well
as more concrete demo of the system ( live migration of VM running
large  enterprise apps such as ERP or In memory DB)

Note: this is just a step stone as the post copy live migration mainly
enable us to validate the architecture design and  code.

Regards
Benoit







Regards
Benoit


On 12 January 2012 13:59, Avi Kivity  wrote:
> On 01/04/2012 05:03 AM, Isaku Yamahata wrote:
>> Yes, it's quite doable in user space(qemu) with a kernel-enhancement.
>> And it would be easy to convert a separated daemon process into a thread
>> in qemu.
>>
>> I think it should be done out side of qemu process for some reasons.
>> (I just repeat same discussion at the KVM-forum because no one remembers
>> it)
>>
>> - ptrace (and its variant)
>>   Some people want to investigate guest ram on host (qemu stopped or lively).
>>   For example, enhance crash utility and it will attach qemu process and
>>   debug guest kernel.
>
> To debug the guest kernel you don't need to stop qemu itself.   I agree
> it's a problem for qemu debugging though.
>
>>
>> - core dump
>>   qemu process may core-dump.
>>   As postmortem analysis, people want to investigate guest RAM.
>>   Again enhance crash utility and it will read the core file and analyze
>>   guest kernel.
>>   When creating core, the qemu process is already dead.
>
> Yes, strong point.
>
>> It precludes the above possibilities to handle fault in qemu process.
>
> I agree.
>
>
> --
> error compiling committee.c: too many arguments to function
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
" The production of too many useful things results in too many useless people"

Re: [Qemu-devel] [PATCH 0/2][RFC] postcopy migration: Linux char device for postcopy

[Isaku Yamahata]

One more question.
Does your architecture/implementation (in theory) allow KVM memory
features like swap, KSM, THP?


On Fri, Jan 13, 2012 at 11:03:23AM +0900, Isaku Yamahata wrote:
> Very interesting. We can cooperate for better (postcopy) live migration.
> The code doesn't seem available yet, I'm eager for it.
> 
> 
> On Fri, Jan 13, 2012 at 01:09:30AM +, Benoit Hudzia wrote:
> > Hi,
> > 
> > Sorry to jump to hijack the thread  like that , however i would like
> > to just to inform you  that we recently achieve a milestone out of the
> > research project I'm leading. We enhanced KVM in order to deliver
> > post copy live migration using RDMA at kernel level.
> > 
> > Few point on the architecture of the system :
> > 
> > * RDMA communication engine in kernel ( you can use soft iwarp or soft
> > ROCE if you don't have hardware acceleration, however we also support
> > standard RDMA enabled NIC) .
> 
> Do you mean infiniband subsystem?
> 
> 
> > * Naturally Page are transferred with Zerop copy protocol
> > * Leverage the async page fault system.
> > * Pre paging / faulting
> > * No context switch as everything is handled within kernel and using
> > the page fault system.
> > * Hybrid migration ( pre + post copy) available
> 
> Ah, I've been also planing this.
> After pre-copy phase, is the dirty bitmap sent?
> 
> So far I've thought naively that pre-copy phase would be finished by the
> number of iterations. On the other hand your choice is timeout of
> pre-copy phase. Do you have rationale? or it was just natural for you?
> 
> 
> > * Rely on an independent Kernel Module
> > * No modification to the KVM kernel Module
> > * Minimal Modification to the Qemu-Kvm code
> > * We plan to add the page prioritization algo in order to optimise the
> > pre paging algo and background transfer
> 
> Where do you plan to implement? in qemu or in your kernel module?
> This algo could be shared.
> 
> thanks in advance.
> 
> > You can learn a little bit more and see a demo here:
> > http://tinyurl.com/8xa2bgl
> > I hope to be able to provide more detail on the design soon. As well
> > as more concrete demo of the system ( live migration of VM running
> > large  enterprise apps such as ERP or In memory DB)
> > 
> > Note: this is just a step stone as the post copy live migration mainly
> > enable us to validate the architecture design and  code.
> > 
> > Regards
> > Benoit
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > Regards
> > Benoit
> > 
> > 
> > On 12 January 2012 13:59, Avi Kivity  wrote:
> > > On 01/04/2012 05:03 AM, Isaku Yamahata wrote:
> > >> Yes, it's quite doable in user space(qemu) with a kernel-enhancement.
> > >> And it would be easy to convert a separated daemon process into a thread
> > >> in qemu.
> > >>
> > >> I think it should be done out side of qemu process for some reasons.
> > >> (I just repeat same discussion at the KVM-forum because no one remembers
> > >> it)
> > >>
> > >> - ptrace (and its variant)
> > >> ?? Some people want to investigate guest ram on host (qemu stopped or 
> > >> lively).
> > >> ?? For example, enhance crash utility and it will attach qemu process and
> > >> ?? debug guest kernel.
> > >
> > > To debug the guest kernel you don't need to stop qemu itself. ?? I agree
> > > it's a problem for qemu debugging though.
> > >
> > >>
> > >> - core dump
> > >> ?? qemu process may core-dump.
> > >> ?? As postmortem analysis, people want to investigate guest RAM.
> > >> ?? Again enhance crash utility and it will read the core file and analyze
> > >> ?? guest kernel.
> > >> ?? When creating core, the qemu process is already dead.
> > >
> > > Yes, strong point.
> > >
> > >> It precludes the above possibilities to handle fault in qemu process.
> > >
> > > I agree.
> > >
> > >
> > > --
> > > error compiling committee.c: too many arguments to function
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe kvm" in
> > > the body of a message to majord...@vger.kernel.org
> > > More majordomo info at ??http://vger.kernel.org/majordomo-info.html
> > 
> > 
> > 
> > -- 
> > " The production of too many useful things results in too many useless 
> > people"
> > 
> 
> -- 
> yamahata
> 

-- 
yamahata

Re: [Qemu-devel] [PATCH 0/2][RFC] postcopy migration: Linux char device for postcopy

[Andrea Arcangeli]

On Thu, Jan 12, 2012 at 03:59:59PM +0200, Avi Kivity wrote:
> On 01/04/2012 05:03 AM, Isaku Yamahata wrote:
> > Yes, it's quite doable in user space(qemu) with a kernel-enhancement.
> > And it would be easy to convert a separated daemon process into a thread
> > in qemu.
> >
> > I think it should be done out side of qemu process for some reasons.
> > (I just repeat same discussion at the KVM-forum because no one remembers
> > it)
> >
> > - ptrace (and its variant)
> >   Some people want to investigate guest ram on host (qemu stopped or 
> > lively).
> >   For example, enhance crash utility and it will attach qemu process and
> >   debug guest kernel.
> 
> To debug the guest kernel you don't need to stop qemu itself.   I agree
> it's a problem for qemu debugging though.

But you need to debug postcopy migration too with gdb or not? I don't
see a big benefit in trying to prevent gdb to see really what is going
on in the qemu image.

> > - core dump
> >   qemu process may core-dump.
> >   As postmortem analysis, people want to investigate guest RAM.
> >   Again enhance crash utility and it will read the core file and analyze
> >   guest kernel.
> >   When creating core, the qemu process is already dead.
> 
> Yes, strong point.
> 
> > It precludes the above possibilities to handle fault in qemu process.
> 
> I agree.

In the receiving node if the memory is not there yet (and it isn't),
not sure how you plan to get a clean core dump (like if live migration
wasn't running) by preventing the kernel from dumping zeroes if qemu
crashes during post copy migration. Surely it won't be the kernel
crash handler completing the post migration, it won't even know where
to write the data in memory.

Re: [Qemu-devel] [PATCH 0/2][RFC] postcopy migration: Linux char device for postcopy

[Andrea Arcangeli]

On Thu, Jan 12, 2012 at 03:57:47PM +0200, Avi Kivity wrote:
> On 01/03/2012 04:25 PM, Andrea Arcangeli wrote:
> >  
> > > > So the problem is if we do it in
> > > > userland with the current functionality you'll run out of VMAs and
> > > > slowdown performance too much.
> > > >
> > > > But all you need is the ability to map single pages in the address
> > > > space.
> > > 
> > > Would this also let you set different pgprots for different pages in the 
> > > same VMA?  It would be useful for write barriers in garbage collectors 
> > > (such as boehm-gc).  These do not have _that_ many VMAs, because every 
> > > GC cycles could merge all of them back to a single VMA with PROT_READ 
> > > permissions; however, they still put some strain on the VM subsystem.
> >
> > Changing permission sounds more tricky as more code may make
> > assumptions on the vma before checking the pte.
> >
> > Adding a magic unmapped pte entry sounds fairly safe because there's
> > the migration pte already used by migrate which halts page faults and
> > wait, that creates a precedent. So I guess we could reuse the same
> > code that already exists for the migration entry and we'd need to fire
> > a signal and returns to userland instead of waiting. The signal should
> > be invoked before the page fault will trigger again. 
> 
> Delivering signals is slow, and you can't use signalfd for it, because
> that can be routed to a different task.  I would like an fd based
> protocol with an explicit ack so the other end can be implemented by the
> kernel, to use with RDMA.  Kind of like how vhost-net talks to a guest
> via a kvm ioeventfd/irqfd.

As long as we tell qemu to run some per-vcpu handler (or io-thread
handler in case of access through the I/O thread) before accessing the
same memory address again, I don't see a problem in using a faster
mechanism than signals. In theory we could even implement this
functionality in kvm itself and just add two ioctl to the kvm fd,
instead of a syscall in fact but it'd be mangling over VM things like
page->index.

> > Of course if the
> > signal returns and does nothing it'll loop at 100% cpu load but that's
> > ok. Maybe it's possible to tweak the permissions but it will need a
> > lot more thoughts. Specifically for anon pages marking them readonly
> > sounds possible if they are supposed to behave like regular COWs (not
> > segfaulting or anything), as you already can have a mixture of
> > readonly and read-write ptes (not to tell readonly KSM pages), but for
> > any other case it's non trivial. Last but not the least the API here
> > would be like a vma-less-mremap, moving a page from one address to
> > another without modifying the vmas, the permission tweak sounds more
> > like an mprotect, so I'm unsure if it could do both or if it should be
> > an optimization to consider independently.
> 
> Doesn't this stuff require tlb flushes across all threads?

It does, to do it zerocopy and atomic we must move the pte.

> > In theory I suspect we could also teach mremap to do a
> > not-vma-mangling mremap if we move pages that aren't shared and so we
> > can adjust the page->index of the pages, instead of creating new vmas
> > at the dst address with an adjusted vma->vm_pgoff, but I suspect a
> > syscall that only works on top of fault-unmapped areas is simpler and
> > safer. mremap semantics requires nuking the dst region before the move
> > starts. If we would teach mremap how to handle the fault-unmapped
> > areas we could just add one syscall prepare_fault_area (or whatever
> > name you choose).
> >
> > The locking of doing a vma-less-mremap still sounds tricky but I doubt
> > you can avoid that locking complexity by using the chardevice as long
> > as the chardevice backed-memory still allows THP, migration and swap,
> > if you want to do it atomic-zerocopy and I think zerocopy would be
> > better especially if the network card is fast and all vcpus are
> > faulting into unmapped pages simultaneously so triggering heavy amount
> > of copying from all physical cpus.
> >
> > I don't mean the current device driver doing a copy_user won't work or
> > is bad idea, it's more self contained and maybe easier to merge
> > upstream. I'm just presenting another option more VM integrated
> > zerocopy with just 2 syscalls.
> 
> Zerocopy is really interesting here, esp. w/ RDMA.  But while adding
> ptes is cheap, removing them is not.  I wonder if we can make a
> write-only page?  Of course it's unmapped for cpu access, but we can
> allow DMA write access from the NIC.  Probably too wierd.

Keeping it mapped in two places gives problem with the non-linearity
of the page->index. We've 1 page->index and two different
vma->vm_pgoff, so it's just not a problem of readonly. We could even
it let it read-write as long as it is nuked when we swap. Problem is
we can't leave it there, we must update page->index, if we don't the
rmap walk breaks and swap/migrate with it... we would allow any thread
to see random memory th

Re: [Qemu-devel] [PATCH 0/2][RFC] postcopy migration: Linux char device for postcopy

[Isaku Yamahata]

Very interesting. We can cooperate for better (postcopy) live migration.
The code doesn't seem available yet, I'm eager for it.


On Fri, Jan 13, 2012 at 01:09:30AM +, Benoit Hudzia wrote:
> Hi,
> 
> Sorry to jump to hijack the thread  like that , however i would like
> to just to inform you  that we recently achieve a milestone out of the
> research project I'm leading. We enhanced KVM in order to deliver
> post copy live migration using RDMA at kernel level.
> 
> Few point on the architecture of the system :
> 
> * RDMA communication engine in kernel ( you can use soft iwarp or soft
> ROCE if you don't have hardware acceleration, however we also support
> standard RDMA enabled NIC) .

Do you mean infiniband subsystem?


> * Naturally Page are transferred with Zerop copy protocol
> * Leverage the async page fault system.
> * Pre paging / faulting
> * No context switch as everything is handled within kernel and using
> the page fault system.
> * Hybrid migration ( pre + post copy) available

Ah, I've been also planing this.
After pre-copy phase, is the dirty bitmap sent?

So far I've thought naively that pre-copy phase would be finished by the
number of iterations. On the other hand your choice is timeout of
pre-copy phase. Do you have rationale? or it was just natural for you?


> * Rely on an independent Kernel Module
> * No modification to the KVM kernel Module
> * Minimal Modification to the Qemu-Kvm code
> * We plan to add the page prioritization algo in order to optimise the
> pre paging algo and background transfer

Where do you plan to implement? in qemu or in your kernel module?
This algo could be shared.

thanks in advance.

> You can learn a little bit more and see a demo here:
> http://tinyurl.com/8xa2bgl
> I hope to be able to provide more detail on the design soon. As well
> as more concrete demo of the system ( live migration of VM running
> large  enterprise apps such as ERP or In memory DB)
> 
> Note: this is just a step stone as the post copy live migration mainly
> enable us to validate the architecture design and  code.
> 
> Regards
> Benoit
> 
> 
> 
> 
> 
> 
> 
> Regards
> Benoit
> 
> 
> On 12 January 2012 13:59, Avi Kivity  wrote:
> > On 01/04/2012 05:03 AM, Isaku Yamahata wrote:
> >> Yes, it's quite doable in user space(qemu) with a kernel-enhancement.
> >> And it would be easy to convert a separated daemon process into a thread
> >> in qemu.
> >>
> >> I think it should be done out side of qemu process for some reasons.
> >> (I just repeat same discussion at the KVM-forum because no one remembers
> >> it)
> >>
> >> - ptrace (and its variant)
> >> ?? Some people want to investigate guest ram on host (qemu stopped or 
> >> lively).
> >> ?? For example, enhance crash utility and it will attach qemu process and
> >> ?? debug guest kernel.
> >
> > To debug the guest kernel you don't need to stop qemu itself. ?? I agree
> > it's a problem for qemu debugging though.
> >
> >>
> >> - core dump
> >> ?? qemu process may core-dump.
> >> ?? As postmortem analysis, people want to investigate guest RAM.
> >> ?? Again enhance crash utility and it will read the core file and analyze
> >> ?? guest kernel.
> >> ?? When creating core, the qemu process is already dead.
> >
> > Yes, strong point.
> >
> >> It precludes the above possibilities to handle fault in qemu process.
> >
> > I agree.
> >
> >
> > --
> > error compiling committee.c: too many arguments to function
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at ??http://vger.kernel.org/majordomo-info.html
> 
> 
> 
> -- 
> " The production of too many useful things results in too many useless people"
> 

-- 
yamahata

Re: [Qemu-devel] [Qemu-ppc] [PATCH 3/9] pci: Make bounds checks on config space accesses actually work

[David Gibson]

On Fri, Jan 13, 2012 at 03:23:37AM +0200, Michael S. Tsirkin wrote:
> On Fri, Jan 13, 2012 at 11:26:12AM +1100, David Gibson wrote:
> > On Thu, Jan 12, 2012 at 03:32:32PM +0200, Michael S. Tsirkin wrote:
> > > On Thu, Jan 12, 2012 at 04:46:22PM +1100, David Gibson wrote:
> > > > The pci_host_config_{read,write}_common() functions perform PCI config
> > > > accesses.  They take a limit parameter which they appear to be supposed
> > > > to bounds check against, however the bounds checking logic, such as it 
> > > > is,
> > > > is completely broken.
> > > > 
> > > > Currently, it takes the minimum of the supplied length and the remaining
> > > > space in the region and passes that as the length to the underlying
> > > > config_{read,write} function pointer.  This means that accesses which
> > > > partially overrun the region will be silently truncated - which makes
> > > > little sense.
> > > 
> > > Why does it make little sense? Makes sense to me.
> > 
> > Well, for starters a partial overrun would have to be an unaligned
> > config space access, which is not supported by PCI.  The behaviour if
> > you try is undefined on most bridges and unlikely to be a partial
> > read/write (ignoring the low addr bits would be more likely).
> 
> Yes, bus level cycles have dword granularity in PCI.
> But look e.g. at our express implementation.
> Config is memory mapped, so we simply map this as memory into guest.

So?

> If you do a large read, what happens on real hardware?
> I'm not sure, but it looks possible that it will get split
> and multiple dword transactions generated on the bus.

Totally irrelevant in this context.  The function definition only
allows a maximum of 4 byte transfers (because of the uint32_ts), so
the bus emulation logic would already have to split a long read into
multiple calls to the function.

> OTOH our implementation passes the read on as is, so
> it can get a multi-dword.
> I'll try to play with some real systems to see what they do.
> 
> > Even if a bridge somehow did a partial access, it's still wrong for
> > reads, since the overrunning bits would typically return 0xff not
> > 0x00, and so you'd need to 0xff pad the result.
> 
> Or maybe an error needs to be generated. We really don't know,
> it's up to the caller.
> 
> > There's just no point doing anything other than simply failing partial
> > overruns.
> 
> There's no point in random code churn either.

Removing an insane semantic os not random code churn.

> > > >  Accesses which entirely overrun the region will *not*
> > > > be blocked (an exploitable bug)
> > > >, because in that case (limit - addr) will
> > > > be negative and so the unsigned MIN will always return len instead.  
> > > > Even
> > > > if signed arithmetic was used, the config_{read,write} callback wouldn't
> > > > know what to do with a negative len parameter.
> > > 
> > > The assumption was callers never pass in such values.
> > 
> > So, callers are to to treat this function, taking a limit parameter as
> > having semantics of "checks a pointless edge case, but not the obvious
> > type of overrun".  You think that's a sensible semantic for a general
> > helper function?  Seriously?
> 
> I don't mind adding an extra check at this level. But
> the comment would need to be reworded from
> 'fix a bug' to 'pseries wants to pass out of range
> values so let's check this'.

Oh, FFS, you're just making excuses for not making a simple fix to
stupid code.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson

[Qemu-devel] buildbot failure in qemu on block_x86_64_debian_6_0

[qemu]

The Buildbot has detected a new failure on builder block_x86_64_debian_6_0 
while building qemu.
Full details are available at:
 http://buildbot.b1-systems.de/qemu/builders/block_x86_64_debian_6_0/builds/151

Buildbot URL: http://buildbot.b1-systems.de/qemu/

Buildslave for this Build: yuzuki

Build Reason: The Nightly scheduler named 'nightly_block' triggered this build
Build Source Stamp: [branch block] HEAD
Blamelist: 

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

[Qemu-devel] buildbot failure in qemu on block_i386_debian_6_0

[qemu]

The Buildbot has detected a new failure on builder block_i386_debian_6_0 while 
building qemu.
Full details are available at:
 http://buildbot.b1-systems.de/qemu/builders/block_i386_debian_6_0/builds/151

Buildbot URL: http://buildbot.b1-systems.de/qemu/

Buildslave for this Build: yuzuki

Build Reason: The Nightly scheduler named 'nightly_block' triggered this build
Build Source Stamp: [branch block] HEAD
Blamelist: 

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

Re: [Qemu-devel] [PATCH 0/2][RFC] postcopy migration: Linux char device for postcopy

[Takuya Yoshikawa]

(2012/01/13 10:09), Benoit Hudzia wrote:

Hi,

Sorry to jump to hijack the thread  like that , however i would like
to just to inform you  that we recently achieve a milestone out of the
research project I'm leading. We enhanced KVM in order to deliver
post copy live migration using RDMA at kernel level.

Few point on the architecture of the system :

* RDMA communication engine in kernel ( you can use soft iwarp or soft
ROCE if you don't have hardware acceleration, however we also support
standard RDMA enabled NIC) .
* Naturally Page are transferred with Zerop copy protocol
* Leverage the async page fault system.
* Pre paging / faulting
* No context switch as everything is handled within kernel and using
the page fault system.
* Hybrid migration ( pre + post copy) available
* Rely on an independent Kernel Module
* No modification to the KVM kernel Module
* Minimal Modification to the Qemu-Kvm code
* We plan to add the page prioritization algo in order to optimise the
pre paging algo and background transfer


You can learn a little bit more and see a demo here:
http://tinyurl.com/8xa2bgl
I hope to be able to provide more detail on the design soon. As well
as more concrete demo of the system ( live migration of VM running
large  enterprise apps such as ERP or In memory DB)

Note: this is just a step stone as the post copy live migration mainly
enable us to validate the architecture design and  code.


Do you have any plan to send the patch series of your implementation?

Takuya

Re: [Qemu-devel] [Qemu-ppc] [PATCH 3/9] pci: Make bounds checks on config space accesses actually work

[Michael S. Tsirkin]

On Fri, Jan 13, 2012 at 11:26:12AM +1100, David Gibson wrote:
> On Thu, Jan 12, 2012 at 03:32:32PM +0200, Michael S. Tsirkin wrote:
> > On Thu, Jan 12, 2012 at 04:46:22PM +1100, David Gibson wrote:
> > > The pci_host_config_{read,write}_common() functions perform PCI config
> > > accesses.  They take a limit parameter which they appear to be supposed
> > > to bounds check against, however the bounds checking logic, such as it is,
> > > is completely broken.
> > > 
> > > Currently, it takes the minimum of the supplied length and the remaining
> > > space in the region and passes that as the length to the underlying
> > > config_{read,write} function pointer.  This means that accesses which
> > > partially overrun the region will be silently truncated - which makes
> > > little sense.
> > 
> > Why does it make little sense? Makes sense to me.
> 
> Well, for starters a partial overrun would have to be an unaligned
> config space access, which is not supported by PCI.  The behaviour if
> you try is undefined on most bridges and unlikely to be a partial
> read/write (ignoring the low addr bits would be more likely).

Yes, bus level cycles have dword granularity in PCI.
But look e.g. at our express implementation.
Config is memory mapped, so we simply map this as memory into guest.
If you do a large read, what happens on real hardware?
I'm not sure, but it looks possible that it will get split
and multiple dword transactions generated on the bus.
OTOH our implementation passes the read on as is, so
it can get a multi-dword.
I'll try to play with some real systems to see what they do.

> Even if a bridge somehow did a partial access, it's still wrong for
> reads, since the overrunning bits would typically return 0xff not
> 0x00, and so you'd need to 0xff pad the result.

Or maybe an error needs to be generated. We really don't know,
it's up to the caller.

> There's just no point doing anything other than simply failing partial
> overruns.

There's no point in random code churn either.

> > >  Accesses which entirely overrun the region will *not*
> > > be blocked (an exploitable bug)
> > >, because in that case (limit - addr) will
> > > be negative and so the unsigned MIN will always return len instead.  Even
> > > if signed arithmetic was used, the config_{read,write} callback wouldn't
> > > know what to do with a negative len parameter.
> > 
> > The assumption was callers never pass in such values.
> 
> So, callers are to to treat this function, taking a limit parameter as
> having semantics of "checks a pointless edge case, but not the obvious
> type of overrun".  You think that's a sensible semantic for a general
> helper function?  Seriously?

I don't mind adding an extra check at this level. But
the comment would need to be reworded from
'fix a bug' to 'pseries wants to pass out of range
values so let's check this'.

> > Could you please give an example how this exploitable bug
> > can get triggered?
> 
> Ah, yes, it's not actually exploitable in the current code, since the
> only callers mask the address down.  It becomes exploitable if someone
> writes a new bridge which doesn't go via the existing accessors and
> assumes that the function which looks like it bounds checks actually
> bounds checks (which I'm about to do for the pseries PCI code.
> 
> Factoring the bounds checking into pci_host_config_{read,write} just
> makes more sense.
> 
> -- 
> David Gibson  | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au| minimalist, thank you.  NOT _the_ 
> _other_
>   | _way_ _around_!
> http://www.ozlabs.org/~dgibson

Re: [Qemu-devel] [PATCH] build: fix target_phys_addr_t to 64-bit

[Peter Maydell]

On 12 January 2012 23:47, Andreas Färber  wrote:
> PRI* should never include % or width specifier or prefix.
>
> What we should IMO do is:
>
> #define PRIdPLX PRId64
> #define PRIxPLX PRIx64
> #define PRIXPLX PRIX64
> /* or TARGET_PRI*PHYS or whatever */
>
> This can then be used as "... %02" PRIxPLX for shortened output.

Yes, I like this -- it's using the PRI* as a way of getting
"right format specifier for the type" without imposing the
width etc on the user, and it lines up with the standard
PRI* macros rather than being an oddity like TARGET_FMT_plx
is at the moment.

-- PMM

[Qemu-devel] buildbot failure in qemu on disable_kvm_x86_64_out_of_tree

[qemu]

The Buildbot has detected a new failure on builder 
disable_kvm_x86_64_out_of_tree while building qemu.
Full details are available at:
 
http://buildbot.b1-systems.de/qemu/builders/disable_kvm_x86_64_out_of_tree/builds/339

Buildbot URL: http://buildbot.b1-systems.de/qemu/

Buildslave for this Build: yuzuki

Build Reason: The Nightly scheduler named 'nightly_disable_kvm' triggered this 
build
Build Source Stamp: [branch master] HEAD
Blamelist: 

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

[Qemu-devel] buildbot failure in qemu on disable_kvm_i386_out_of_tree

[qemu]

The Buildbot has detected a new failure on builder disable_kvm_i386_out_of_tree 
while building qemu.
Full details are available at:
 
http://buildbot.b1-systems.de/qemu/builders/disable_kvm_i386_out_of_tree/builds/339

Buildbot URL: http://buildbot.b1-systems.de/qemu/

Buildslave for this Build: yuzuki

Build Reason: The Nightly scheduler named 'nightly_disable_kvm' triggered this 
build
Build Source Stamp: [branch master] HEAD
Blamelist: 

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

[Qemu-devel] buildbot failure in qemu on disable_kvm_x86_64_debian_6_0

[qemu]

The Buildbot has detected a new failure on builder 
disable_kvm_x86_64_debian_6_0 while building qemu.
Full details are available at:
 
http://buildbot.b1-systems.de/qemu/builders/disable_kvm_x86_64_debian_6_0/builds/152

Buildbot URL: http://buildbot.b1-systems.de/qemu/

Buildslave for this Build: yuzuki

Build Reason: The Nightly scheduler named 'nightly_disable_kvm' triggered this 
build
Build Source Stamp: [branch master] HEAD
Blamelist: 

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

[Qemu-devel] buildbot failure in qemu on disable_kvm_i386_debian_6_0

[qemu]

The Buildbot has detected a new failure on builder disable_kvm_i386_debian_6_0 
while building qemu.
Full details are available at:
 
http://buildbot.b1-systems.de/qemu/builders/disable_kvm_i386_debian_6_0/builds/152

Buildbot URL: http://buildbot.b1-systems.de/qemu/

Buildslave for this Build: yuzuki

Build Reason: The Nightly scheduler named 'nightly_disable_kvm' triggered this 
build
Build Source Stamp: [branch master] HEAD
Blamelist: 

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

Re: [Qemu-devel] [PATCH 00/11] virtio-scsi device model

[Hu Tao]

On Thu, Jan 12, 2012 at 10:47:48AM +0100, Paolo Bonzini wrote:
> On 01/12/2012 06:17 AM, Hu Tao wrote:
> >Hi Paolo,
> >
> >How to add a virtio-scsi device? What parameters should I specify
> >in qemu command line?
> 
> Same as with other SCSI devices:
> 
>   -device virtio-scsi-pci
> 
> then for every disk
> 
>   -drive if=none,file=PATH,id=NAME
>   -device scsi-hd,drive=NAME
> 
> (or scsi-cd for a CD-ROM drive).

Thank you. I'll have a try.

-- 
Thanks,
Hu Tao

Re: [Qemu-devel] [Qemu-ppc] [PATCH 3/9] pci: Make bounds checks on config space accesses actually work

[David Gibson]

On Thu, Jan 12, 2012 at 03:32:32PM +0200, Michael S. Tsirkin wrote:
> On Thu, Jan 12, 2012 at 04:46:22PM +1100, David Gibson wrote:
> > The pci_host_config_{read,write}_common() functions perform PCI config
> > accesses.  They take a limit parameter which they appear to be supposed
> > to bounds check against, however the bounds checking logic, such as it is,
> > is completely broken.
> > 
> > Currently, it takes the minimum of the supplied length and the remaining
> > space in the region and passes that as the length to the underlying
> > config_{read,write} function pointer.  This means that accesses which
> > partially overrun the region will be silently truncated - which makes
> > little sense.
> 
> Why does it make little sense? Makes sense to me.

Well, for starters a partial overrun would have to be an unaligned
config space access, which is not supported by PCI.  The behaviour if
you try is undefined on most bridges and unlikely to be a partial
read/write (ignoring the low addr bits would be more likely).

Even if a bridge somehow did a partial access, it's still wrong for
reads, since the overrunning bits would typically return 0xff not
0x00, and so you'd need to 0xff pad the result.

There's just no point doing anything other than simply failing partial
overruns.

> >  Accesses which entirely overrun the region will *not*
> > be blocked (an exploitable bug)
> >, because in that case (limit - addr) will
> > be negative and so the unsigned MIN will always return len instead.  Even
> > if signed arithmetic was used, the config_{read,write} callback wouldn't
> > know what to do with a negative len parameter.
> 
> The assumption was callers never pass in such values.

So, callers are to to treat this function, taking a limit parameter as
having semantics of "checks a pointless edge case, but not the obvious
type of overrun".  You think that's a sensible semantic for a general
helper function?  Seriously?

> Could you please give an example how this exploitable bug
> can get triggered?

Ah, yes, it's not actually exploitable in the current code, since the
only callers mask the address down.  It becomes exploitable if someone
writes a new bridge which doesn't go via the existing accessors and
assumes that the function which looks like it bounds checks actually
bounds checks (which I'm about to do for the pseries PCI code.

Factoring the bounds checking into pci_host_config_{read,write} just
makes more sense.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [Qemu-devel] [PATCH] build: fix target_phys_addr_t to 64-bit

[Andreas Färber]

Am 12.01.2012 23:56, schrieb Anthony Liguori:
> On 01/12/2012 04:46 PM, Peter Maydell wrote:
> I think a reasonable thing to do is:
> 
> #define PRIp64 "0x%08" PRIx64
> 
> s:TARGET_FMT_plx:PRIp64:g

Nack, that is unreasonable naming and does not solve the issue pointed
out by Peter. PRI* should never include % or width specifier or prefix.

What we should IMO do is:

#define PRIdPLX PRId64
#define PRIxPLX PRIx64
#define PRIXPLX PRIX64
/* or TARGET_PRI*PHYS or whatever */

This can then be used as "... %02" PRIxPLX for shortened output.

And leave TARGET_FMT_plx untouched except for having it reuse PRIxPLX.

You might want to compare OpenBIOS code, where we've been through that
trouble before.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

[Qemu-devel] buildbot failure in qemu on default_i386_debian_6_0

[qemu]

The Buildbot has detected a new failure on builder default_i386_debian_6_0 
while building qemu.
Full details are available at:
 http://buildbot.b1-systems.de/qemu/builders/default_i386_debian_6_0/builds/151

Buildbot URL: http://buildbot.b1-systems.de/qemu/

Buildslave for this Build: yuzuki

Build Reason: The Nightly scheduler named 'nightly_default' triggered this build
Build Source Stamp: [branch master] HEAD
Blamelist: 

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

[Qemu-devel] buildbot failure in qemu on default_i386_out_of_tree

[qemu]

The Buildbot has detected a new failure on builder default_i386_out_of_tree 
while building qemu.
Full details are available at:
 http://buildbot.b1-systems.de/qemu/builders/default_i386_out_of_tree/builds/337

Buildbot URL: http://buildbot.b1-systems.de/qemu/

Buildslave for this Build: yuzuki

Build Reason: The Nightly scheduler named 'nightly_default' triggered this build
Build Source Stamp: [branch master] HEAD
Blamelist: 

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

[Qemu-devel] buildbot failure in qemu on default_x86_64_out_of_tree

[qemu]

The Buildbot has detected a new failure on builder default_x86_64_out_of_tree 
while building qemu.
Full details are available at:
 
http://buildbot.b1-systems.de/qemu/builders/default_x86_64_out_of_tree/builds/337

Buildbot URL: http://buildbot.b1-systems.de/qemu/

Buildslave for this Build: yuzuki

Build Reason: The Nightly scheduler named 'nightly_default' triggered this build
Build Source Stamp: [branch master] HEAD
Blamelist: 

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

[Qemu-devel] buildbot failure in qemu on default_x86_64_debian_6_0

[qemu]

The Buildbot has detected a new failure on builder default_x86_64_debian_6_0 
while building qemu.
Full details are available at:
 
http://buildbot.b1-systems.de/qemu/builders/default_x86_64_debian_6_0/builds/151

Buildbot URL: http://buildbot.b1-systems.de/qemu/

Buildslave for this Build: yuzuki

Build Reason: The Nightly scheduler named 'nightly_default' triggered this build
Build Source Stamp: [branch master] HEAD
Blamelist: 

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

Re: [Qemu-devel] [PATCH v2] qemu-ga: add guest-set-support-level command

[Michael Roth]

On 01/12/2012 12:57 PM, Luiz Capitulino wrote:

On Wed, 11 Jan 2012 17:56:05 -0600
Michael Roth  wrote:


Recently commands where introduced on the mailing that involved adding
commands to the guest agent that could potentially break older versions
of QEMU. While it's okay to expect that qemu-ga can be updated to support
newer host features, it's unrealistic to require a host to be updated to
support qemu-ga features, or to expect that qemu-ga should be downgraded
in these circumstances, especially considering that a large mix of
guests/agents may be running on a particular host.

To address this, we introduce here a mechanism to set qemu-ga's
feature-set to one that is known to be compatible with
the host/QEMU running the guest. As new commands/options are added, we
can maintain backward-compatibility by adding conditional checks to filter
out host-incompatible functionality based on the host-specified support
level (generally analogous to the host QEMU version) set by the
client.

The current default/minimum support level supports all versions of QEMU
that have had qemu-ga in-tree (0.15.0, 1.0.0) and so should be
backward-compatible with existing hosts/clients.


The approach looks fine to me. I have a few review comments below.



Signed-off-by: Michael Roth
---
  qapi-schema-guest.json |   31 -
  qemu-ga.c  |   46 
  qga/guest-agent-commands.c |   13 
  qga/guest-agent-core.h |   11 ++
  4 files changed, 100 insertions(+), 1 deletions(-)

diff --git a/qapi-schema-guest.json b/qapi-schema-guest.json
index 5f8a18d..32bc041 100644
--- a/qapi-schema-guest.json
+++ b/qapi-schema-guest.json
@@ -43,15 +43,44 @@
  #
  # Since: 0.15.0
  ##
+{ 'type': 'GuestAgentSupportLevel',
+  'data': { 'major': 'int', 'minor': 'int', 'micro': 'int' } }


This and GuestAgentCommandInfo are missing good documentation. Looks like
we don't document types as we do in qapi-schema.json. I think we should.



Agreed, I'll precede this with a patch to add the documentation for 
existing types, and update this patch accordingly.



  { 'type': 'GuestAgentCommandInfo',
'data': { 'name': 'str', 'enabled': 'bool' } }
  { 'type': 'GuestAgentInfo',
'data': { 'version': 'str',
-'supported_commands': ['GuestAgentCommandInfo'] } }
+'supported_commands': ['GuestAgentCommandInfo']
+'support_level': 'GuestAgentSupportLevel' } }
  { 'command': 'guest-info',
'returns': 'GuestAgentInfo' }


For example, something important that's is not totally clear to me just by
reading the command definition is if 'support_level' refers to the support
level that can be changed by a client.



  ##
+# @guest-set-support-level:
+#
+# Set guest agent feature-set to one that is compatible with/supported by
+# the host.
+#
+# Certain commands/options may have dependencies on host
+# version/support-level, such as specific QEMU features (such
+# dependencies will be noted in this schema). By default we assume 1.0.0,
+# which is backward-compatible with QEMU 0.15.0/1.0, and should be compatible
+# with later versions of QEMU as well. To enable newer guest agent features,
+# this command must be issued to raise the support-level to one corresponding
+# to supported host QEMU/KVM/etc capabilities.
+#
+# The currently set support level is obtainable via the guest-info command.
+#
+# @level: Desired host support-level, generally<= host QEMU version
+# level. Note that undefined behavior may occur if a support-level is
+# provided that exceeds the capabilities of the version of QEMU currently
+# running the guest.


It's also better to note that if @level<  1.0.0 then the support level will
be set to 1.0.0.



I must've looked at this like 5 times and made a mental note to do that, 
but in the end it escaped me...



+#
+# Returns: Nothing on success
+#
+{ 'command': 'guest-set-support-level',
+  'data':{ 'major': 'int', 'minor': 'int', '*micro': 'int' } }
+
+##
  # @guest-shutdown:
  #
  # Initiate guest-activated shutdown. Note: this is an asynchronous
diff --git a/qemu-ga.c b/qemu-ga.c
index 200bb15..6840233 100644
--- a/qemu-ga.c
+++ b/qemu-ga.c
@@ -28,6 +28,7 @@
  #include "qerror.h"
  #include "error_int.h"
  #include "qapi/qmp-core.h"
+#include "qga-qapi-types.h"

  #define QGA_VIRTIO_PATH_DEFAULT "/dev/virtio-ports/org.qemu.guest_agent.0"
  #define QGA_PIDFILE_DEFAULT "/var/run/qemu-ga.pid"
@@ -102,6 +103,45 @@ static void usage(const char *cmd)

  static void conn_channel_close(GAState *s);

+static GuestAgentSupportLevel ga_support_level;
+
+static int ga_cmp_support_levels(GuestAgentSupportLevel a,
+ GuestAgentSupportLevel b)
+{
+if (a.major == b.major) {
+if (a.minor == b.minor) {
+return a.micro - b.micro;
+}
+return a.minor - b.minor;
+}
+return a.major - b.major;
+}
+
+bool ga_has_support_level(int major, int minor

Re: [Qemu-devel] [PATCH] build: fix target_phys_addr_t to 64-bit

[Peter Maydell]

On 12 January 2012 22:56, Anthony Liguori  wrote:
> This code is broken in its current form.  target_phys_addr_t has an
> unspecified width which is why we provide a FMT for it.

I don't think it's been clear that target_phys_addr_t has a
width which might not be the width of the target's physical
addresses (as opposed to it having a width that's unspecified
because you don't know what target you're running on and
therefore don't know how big its physical addresses are).

It might be worth adding a note to HACKING that
target_phys_addr_t is guaranteed to be able to hold a
physical address but might be bigger than one.

-- PMM

Re: [Qemu-devel] [PATCH] build: fix target_phys_addr_t to 64-bit

[Anthony Liguori]

On 01/12/2012 04:46 PM, Peter Maydell wrote:

On 12 January 2012 22:42, Peter Maydell  wrote:

You're the one changing what was previously a known-to-be-32-bit
type to one that's much bigger, you get to fix the printing
issues.


This code is broken in its current form.  target_phys_addr_t has an unspecified 
width which is why we provide a FMT for it.


Assuming it's 32-bit is just as bad as assuming that all hosts are 64-bit or all 
guests are little endian.  It may have worked up until now for a particular 
device, but it doesn't change the fact that it was wrong.



...which isn't to say that I don't think this is a good
plan (indeed I suspect I'm going to need wider physaddrs
for Cortex-A15 at some point :-)), just that I think we
ought to have at least a sketch of how the average device
for which the offset is going to be<4096,


I think a reasonable thing to do is:

#define PRIp64 "0x%08" PRIx64

s:TARGET_FMT_plx:PRIp64:g

Then in places where desired, you can just use PRIx64 directly to specify a 
custom width.


But that's a touch-everything change that I think should be done in a separate 
series.



let alone<32bits
can print messages involving the offsets without it looking
really ugly in either the code or the output (and that
where in this patch you're actually touching output formats
you should use whatever the reasonable-looking thing is
rather than just something that compiles.)


To print a target_phys_addr_t, you need to use TARGET_FMT_plx.  If code wasn't 
using TARGET_FMT_plx, then it was broken.


If you want something more flexible than TARGET_FMT_plx, I'm supportive of that, 
but that should have been done to begin with instead of making bad assumptions 
about sizeof(target_phys_addr_t).


Regards,

Anthony Liguori


-- PMM

Re: [Qemu-devel] [PATCH] build: fix target_phys_addr_t to 64-bit

[Peter Maydell]

On 12 January 2012 22:42, Peter Maydell  wrote:
> You're the one changing what was previously a known-to-be-32-bit
> type to one that's much bigger, you get to fix the printing
> issues.

...which isn't to say that I don't think this is a good
plan (indeed I suspect I'm going to need wider physaddrs
for Cortex-A15 at some point :-)), just that I think we
ought to have at least a sketch of how the average device
for which the offset is going to be <4096, let alone <32bits
can print messages involving the offsets without it looking
really ugly in either the code or the output (and that
where in this patch you're actually touching output formats
you should use whatever the reasonable-looking thing is
rather than just something that compiles.)

-- PMM

Re: [Qemu-devel] [PATCH] build: fix target_phys_addr_t to 64-bit

[Peter Maydell]

On 12 January 2012 20:32, Anthony Liguori  wrote:
> On 01/12/2012 02:06 PM, Peter Maydell wrote:
>>
>> On 12 January 2012 17:54, Anthony Liguori  wrote:
>>>
>>> This simplifies the build quite a bit and improves the builds performance
>>> by
>>> not rebuilding many objects twice.
>>>
>>> There were a surprising number of places that had assumed wrong things
>>> about the
>>> size of target_phys_addr_t including that it was fixed at 32-bit and that
>>> it
>>> was identical to target_ulong.
>>
>>
>> Up until now, in a lot of CPU-specific code it has been perfectly
>> reasonable to assume target_phys_addr_t was 32 bits.
>
>
> No, that's never been a reasonable thing to assume.

Having target_phys_addr_t be possibly larger than the guest
physical address type is exactly the thing this patch is
changing...

>> I don't like this. When target_phys_addr_t was 32 bits, then
>> using TARGET_FMT_plx to print offsets into devices isn't
>> too unreasonable as you only get 8 hex digits. If you expand
>> to 64 bits then suddenly all these offsets which are actually
>> really typically small numbers get printed as 16 hex digits,
>> which I think looks bad.

> Then cast it to a 32-bit number and print it however you like.

You're the one changing what was previously a known-to-be-32-bit
type to one that's much bigger, you get to fix the printing
issues.

-- PMM

Re: [Qemu-devel] [PATCH 0/5] VFIO core framework

[Konrad Rzeszutek Wilk]

On Tue, Jan 10, 2012 at 11:35:54AM -0700, Alex Williamson wrote:
> On Tue, 2012-01-10 at 11:26 -0500, Konrad Rzeszutek Wilk wrote:
> > On Wed, Dec 21, 2011 at 02:42:02PM -0700, Alex Williamson wrote:
> > > This series includes the core framework for the VFIO driver.
> > > VFIO is a userspace driver interface meant to replace both the
> > > KVM device assignment code as well as interfaces like UIO.  Please
> > > see patch 1/5 for a complete description of VFIO, what it can do,
> > > and how it's designed.
> > > 
> > > This version and the VFIO PCI bus driver, for exposing PCI devices
> > > through VFIO, can be found here:
> > > 
> > > git://github.com/awilliam/linux-vfio.git vfio-next-20111221
> > > 
> > > A development version of qemu which includes a full working
> > > vfio-pci driver, indepdendent of KVM support, can be found here:
> > > 
> > > git://github.com/awilliam/qemu-vfio.git vfio-ng
> > > 
> > > Thanks,
> > 
> > Alex,
> > 
> > So I took a look at the patchset with two different things in mind this 
> > time:
> >  - What if you do not need to do any IRQ ack/de-ack etc in the host all of 
> > that
> >is done in the guest (say you have an actual IOAPIC in the guest that is
> >_not_ managed by QEMU).
> >  - What would be required to make this work with a different hypervisor - 
> > say Xen.
> > 
> > And the conclusions I came to that it would require some surgery - 
> > especially
> > as some of the IRQ, irqfs, etc code support is not required per say.
> > 
> > To me it seems to get this working with Xen (or perhaps with the Power 
> > machines
> > as well, as their hypervisor is similar to Xen in architecture?) we would 
> > need at
> > least two extra pieces of Linux kernel code: 
> > - Xen IOMMU, which really is just doing a whole bunch of 
> > xc_domain_memory_mapping
> >   the user-space iova calls. For the normal PCI devices operations it would 
> > just
> >   offload them to the existing DMA API.
> > - Xen VFIO PCI. Or at least make the VFIO PCI (in your vfio-next-20111221 
> > branch)
> >   driver allow some abstraction. There are certain things we might done via 
> > alternate
> >   operations. Such as the interrupt handling - where we "bind" the IRQ to 
> > an event
> >   channel or make a hypercall to program the guest' MSI vectors. Perhaps 
> > there can
> >   be an "platform-specific" part of it.
> 
> Sure, I've envisioned that we'll have multiple iommu interfaces.  We'll
> need build-time and run-time selection.  I haven't implemented that yet
> since the iommu requirements are still developing.  Likewise, a
> vfio-xen-pci module is possible or we can look at whether we make the
> vfio-pci code too ugly by incorporating a dual-mode into that.

Yuck. Well, I am all up for making it pretty.

> 
> > In the userland:
> >  - In QEMU VFIO, make the interrupt part optional for certain parts (like 
> > we don't
> >expect an IRQ to happen in the host).
> 
> Or can it be handled by vfio-xen-pci, which enables event channels
> through to xen?  It's possible the GET_IRQ_INFO ioctls could report a

Sure.
> flag indicating the type of notification available (eventfds being the
> initial option) and SET_IRQ_EVENTFDS could be generalized to take an
> array of structs other than eventfds.  For the non-Xen case, eventfds
> seem to provide us with the most flexibility since we can either connect
> them to userspace or just have userspace be the agent that connects the
> eventfd to an irqfd in another module.  See the (outdated) version of
> qemu-kvm vfio in this tree for an example (look for QEMU_KVM_BUILD):
> https://github.com/awilliam/qemu-kvm-vfio/blob/vfio/hw/vfio.c

Ah I see.
> 
> > I am curious to see how the Power folks have to deal with this? Perhaps the 
> > requirement
> > to write an PV IOMMU is not something they need to write?
> > 
> > In terms of this patchset, the "big" thing for me is that it moves the 
> > usual mechanism
> > of "unbind"/"bind" of using the SysFS to be done via ioctls. I get the 
> > reasoning for it
> > - cannot guarantee any locking, but doing it all in ioctls instead of 
> > configfs or sysfs
> > seems odd. But perhaps that is just me having gotten use to doing it in 
> > sysfs/configfs.
> > Certainly it makes it easier to program in QEMU/libvirt. And ultimately 
> > that is going
> > to be user for 99% of this.
> 
> Can you be more specific about which ioctl part you're referring to?  We
> bind/unbind each device to vfio-pci via the normal sysfs driver

Let me look again at the QEMU changes. I was thinking you did a bunch
of ioctls to assign a device, but I am probably getting it confused
with the vfio-group ioctls.

> interfaces.  Userspace binds itself to a group via ioctls, but that's
> because neither configfs or sysfs allow ioctl and I don't think it's
> possible to implement an ioctl-free vfio.  Trying to implement vfio
> across both configfs and chardev presents issues with ownership.

Right, one of them works. No need to do it across different su

Re: [Qemu-devel] [Bug] System emulation with flash broken?

[Gerhard Wiesinger]

On Sun, 8 Jan 2012, Avi Kivity wrote:


On 01/08/2012 02:23 PM, Gerhard Wiesinger wrote:

On Sun, 8 Jan 2012, Avi Kivity wrote:


On 01/07/2012 08:03 PM, Gerhard Wiesinger wrote:

On Fri, 6 Jan 2012, Stefan Weil wrote:


Hello Avi,

latest QEMU seems to be broken when a system emulation with flash is
started.

I did not run git bisect, but it looks like the problem started with
this change:

c5705a7728b4a6bc9e4f2d35911adbaf28042b25
Author: Avi Kivity   2011-12-20 14:59:12
vmstate, memory: decouple vmstate from memory API

I first noticed the problem with my AR7 emulation (not part
of official QEMU), but also got it with MIPS Malta, so I assume
that all systems with flash are broken and fail with this assertion:

/qemu/exec.c:2785: qemu_ram_set_idstr: Assertion `new_block' failed.

The function is searching for address 0x1009 which is 0x1000
plus an index. Without the index, the address would have been found.


Hello Avi,

I'm having also problems with this patch:
# VGA bank switching problems under DOS
git checkout 682a3c07f0e28d2532c911a44a9b6142d6299cc2

# OK
git checkout aad3b517a1b83561f2755dc4451596a421399c19

And commit 682a3c07f0e28d2532c911a44a9b6142d6299cc2 is the Merge
commit 'c5705a7728b4a6bc9e4f2d35911adbaf28042b25' into upstream-merge.



A patch for this has already been posted; hopefully to be merged soon.


To test: Which patch do you exactly mean?



Original patch:

 http://article.gmane.org/gmane.comp.emulators.qemu/131082

My alternative:

 http://article.gmane.org/gmane.comp.emulators.qemu/131164


Helo Avi,

Can NOT confirm that one of these or both changes work well. So 
something else is (still) wrong.


Ciao,
Gerhard

--
http://www.wiesinger.com/

Re: [Qemu-devel] [PATCH] build: fix target_phys_addr_t to 64-bit

[Anthony Liguori]

On 01/12/2012 02:06 PM, Peter Maydell wrote:

On 12 January 2012 17:54, Anthony Liguori  wrote:

This simplifies the build quite a bit and improves the builds performance by
not rebuilding many objects twice.

There were a surprising number of places that had assumed wrong things about the
size of target_phys_addr_t including that it was fixed at 32-bit and that it
was identical to target_ulong.


Up until now, in a lot of CPU-specific code it has been perfectly reasonable
to assume target_phys_addr_t was 32 bits.


No, that's never been a reasonable thing to assume.






Signed-off-by: Anthony Liguori
---
  Makefile|2 +-
  Makefile.hw |   25 
  Makefile.objs   |  182 +++
  Makefile.target |4 -
  configure   |   13 +
  cpu-common.h|8 ---
  dma.h   |2 -
  hw/a9mpcore.c   |4 +-
  hw/hw.h |2 +-
  hw/intel-hda.c  |4 -
  hw/omap.h   |6 --
  hw/pxa2xx_dma.c |6 +-
  hw/pxa2xx_lcd.c |6 +-
  hw/rtl8139.c|4 -
  hw/sh_serial.c  |6 +-
  monitor.c   |   21 --
  qemu-log.h  |4 +-
  targphys.h  |   11 ---
  18 files changed, 106 insertions(+), 204 deletions(-)
  delete mode 100644 Makefile.hw

diff --git a/Makefile b/Makefile
index 2bbc547..32a8ec6 100644
--- a/Makefile
+++ b/Makefile
@@ -197,7 +197,7 @@ $(qga-obj-y) qemu-ga.o: $(QGALIB_GEN) $(GENERATED_HEADERS)

  qemu-ga$(EXESUF): qemu-ga.o $(qga-obj-y) $(qapi-obj-y) $(tools-obj-y) 
$(qobject-obj-y) $(version-obj-y) $(QGALIB_OBJ)

-QEMULIBS=libhw32 libhw64 libuser libdis libdis-user
+QEMULIBS=libuser libdis libdis-user

  clean:
  # avoid old build problems by removing potentially incorrect old files
diff --git a/Makefile.hw b/Makefile.hw
deleted file mode 100644
index 63eb7e4..000
--- a/Makefile.hw
+++ /dev/null
@@ -1,25 +0,0 @@
-# Makefile for qemu target independent devices.
-
-include ../config-host.mak
-include ../config-all-devices.mak
-include config.mak
-include $(SRC_PATH)/rules.mak
-
-.PHONY: all
-
-$(call set-vpath, $(SRC_PATH):$(SRC_PATH)/hw)
-
-QEMU_CFLAGS+=-I..
-QEMU_CFLAGS += $(GLIB_CFLAGS)
-
-include $(SRC_PATH)/Makefile.objs
-
-all: $(hw-obj-y)
-# Dummy command so that make thinks it has done something
-   @true
-
-clean:
-   rm -f *.o */*.o *.d */*.d *.a */*.a *~ */*~
-
-# Include automatically generated dependency files
--include $(wildcard *.d */*.d)
diff --git a/Makefile.objs b/Makefile.objs
index 4f6d26c..13a2281 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -179,118 +179,114 @@ user-obj-y += tcg-runtime.o host-utils.o
  user-obj-y += cutils.o cache-utils.o
  user-obj-y += $(trace-obj-y)

-##
-# libhw
-
-hw-obj-y =
-hw-obj-y += vl.o loader.o
-hw-obj-$(CONFIG_VIRTIO) += virtio-console.o
-hw-obj-y += usb-libhw.o
-hw-obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o
-hw-obj-y += fw_cfg.o
-hw-obj-$(CONFIG_PCI) += pci.o pci_bridge.o
-hw-obj-$(CONFIG_PCI) += msix.o msi.o
-hw-obj-$(CONFIG_PCI) += pci_host.o pcie_host.o
-hw-obj-$(CONFIG_PCI) += ioh3420.o xio3130_upstream.o xio3130_downstream.o
-hw-obj-y += watchdog.o
-hw-obj-$(CONFIG_ISA_MMIO) += isa_mmio.o
-hw-obj-$(CONFIG_ECC) += ecc.o
-hw-obj-$(CONFIG_NAND) += nand.o
-hw-obj-$(CONFIG_PFLASH_CFI01) += pflash_cfi01.o
-hw-obj-$(CONFIG_PFLASH_CFI02) += pflash_cfi02.o
-
-hw-obj-$(CONFIG_M48T59) += m48t59.o
-hw-obj-$(CONFIG_ESCC) += escc.o
-hw-obj-$(CONFIG_EMPTY_SLOT) += empty_slot.o
-
-hw-obj-$(CONFIG_SERIAL) += serial.o
-hw-obj-$(CONFIG_PARALLEL) += parallel.o
-hw-obj-$(CONFIG_I8254) += i8254.o
-hw-obj-$(CONFIG_PCSPK) += pcspk.o
-hw-obj-$(CONFIG_PCKBD) += pckbd.o
-hw-obj-$(CONFIG_USB_UHCI) += usb-uhci.o
-hw-obj-$(CONFIG_USB_OHCI) += usb-ohci.o
-hw-obj-$(CONFIG_USB_EHCI) += usb-ehci.o
-hw-obj-$(CONFIG_FDC) += fdc.o
-hw-obj-$(CONFIG_ACPI) += acpi.o acpi_piix4.o
-hw-obj-$(CONFIG_APM) += pm_smbus.o apm.o
-hw-obj-$(CONFIG_DMA) += dma.o
-hw-obj-$(CONFIG_HPET) += hpet.o
-hw-obj-$(CONFIG_APPLESMC) += applesmc.o
-hw-obj-$(CONFIG_SMARTCARD) += usb-ccid.o ccid-card-passthru.o
-hw-obj-$(CONFIG_SMARTCARD_NSS) += ccid-card-emulated.o
-hw-obj-$(CONFIG_USB_REDIR) += usb-redir.o
-hw-obj-$(CONFIG_I8259) += i8259.o
+common-obj-y += vl.o loader.o
+common-obj-$(CONFIG_VIRTIO) += virtio-console.o
+common-obj-y += usb-libhw.o
+common-obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o
+common-obj-y += fw_cfg.o
+common-obj-$(CONFIG_PCI) += pci.o pci_bridge.o
+common-obj-$(CONFIG_PCI) += msix.o msi.o
+common-obj-$(CONFIG_PCI) += pci_host.o pcie_host.o
+common-obj-$(CONFIG_PCI) += ioh3420.o xio3130_upstream.o xio3130_downstream.o
+common-obj-y += watchdog.o
+common-obj-$(CONFIG_ISA_MMIO) += isa_mmio.o
+common-obj-$(CONFIG_ECC) += ecc.o
+common-obj-$(CONFIG_NAND) += nand.o
+common-obj-$(CONFIG_PFLASH_CFI01) += pflash_cfi01.o
+common-obj-$(CONFIG_PFLASH_CFI02) += pflash_cfi02.o
+
+common-obj-$(CONFIG_M48T59) += m48t59.o
+common-obj-$(CONFIG_ESCC) += escc.o
+common-obj-$(CONFIG_EMPTY_SLOT) += empt

Re: [Qemu-devel] [PATCH] build: fix target_phys_addr_t to 64-bit

[Peter Maydell]

On 12 January 2012 17:54, Anthony Liguori  wrote:
> This simplifies the build quite a bit and improves the builds performance by
> not rebuilding many objects twice.
>
> There were a surprising number of places that had assumed wrong things about 
> the
> size of target_phys_addr_t including that it was fixed at 32-bit and that it
> was identical to target_ulong.

Up until now, in a lot of CPU-specific code it has been perfectly reasonable
to assume target_phys_addr_t was 32 bits.


>
> Signed-off-by: Anthony Liguori 
> ---
>  Makefile        |    2 +-
>  Makefile.hw     |   25 
>  Makefile.objs   |  182 
> +++
>  Makefile.target |    4 -
>  configure       |   13 +
>  cpu-common.h    |    8 ---
>  dma.h           |    2 -
>  hw/a9mpcore.c   |    4 +-
>  hw/hw.h         |    2 +-
>  hw/intel-hda.c  |    4 -
>  hw/omap.h       |    6 --
>  hw/pxa2xx_dma.c |    6 +-
>  hw/pxa2xx_lcd.c |    6 +-
>  hw/rtl8139.c    |    4 -
>  hw/sh_serial.c  |    6 +-
>  monitor.c       |   21 --
>  qemu-log.h      |    4 +-
>  targphys.h      |   11 ---
>  18 files changed, 106 insertions(+), 204 deletions(-)
>  delete mode 100644 Makefile.hw
>
> diff --git a/Makefile b/Makefile
> index 2bbc547..32a8ec6 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -197,7 +197,7 @@ $(qga-obj-y) qemu-ga.o: $(QGALIB_GEN) $(GENERATED_HEADERS)
>
>  qemu-ga$(EXESUF): qemu-ga.o $(qga-obj-y) $(qapi-obj-y) $(tools-obj-y) 
> $(qobject-obj-y) $(version-obj-y) $(QGALIB_OBJ)
>
> -QEMULIBS=libhw32 libhw64 libuser libdis libdis-user
> +QEMULIBS=libuser libdis libdis-user
>
>  clean:
>  # avoid old build problems by removing potentially incorrect old files
> diff --git a/Makefile.hw b/Makefile.hw
> deleted file mode 100644
> index 63eb7e4..000
> --- a/Makefile.hw
> +++ /dev/null
> @@ -1,25 +0,0 @@
> -# Makefile for qemu target independent devices.
> -
> -include ../config-host.mak
> -include ../config-all-devices.mak
> -include config.mak
> -include $(SRC_PATH)/rules.mak
> -
> -.PHONY: all
> -
> -$(call set-vpath, $(SRC_PATH):$(SRC_PATH)/hw)
> -
> -QEMU_CFLAGS+=-I..
> -QEMU_CFLAGS += $(GLIB_CFLAGS)
> -
> -include $(SRC_PATH)/Makefile.objs
> -
> -all: $(hw-obj-y)
> -# Dummy command so that make thinks it has done something
> -       @true
> -
> -clean:
> -       rm -f *.o */*.o *.d */*.d *.a */*.a *~ */*~
> -
> -# Include automatically generated dependency files
> --include $(wildcard *.d */*.d)
> diff --git a/Makefile.objs b/Makefile.objs
> index 4f6d26c..13a2281 100644
> --- a/Makefile.objs
> +++ b/Makefile.objs
> @@ -179,118 +179,114 @@ user-obj-y += tcg-runtime.o host-utils.o
>  user-obj-y += cutils.o cache-utils.o
>  user-obj-y += $(trace-obj-y)
>
> -##
> -# libhw
> -
> -hw-obj-y =
> -hw-obj-y += vl.o loader.o
> -hw-obj-$(CONFIG_VIRTIO) += virtio-console.o
> -hw-obj-y += usb-libhw.o
> -hw-obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o
> -hw-obj-y += fw_cfg.o
> -hw-obj-$(CONFIG_PCI) += pci.o pci_bridge.o
> -hw-obj-$(CONFIG_PCI) += msix.o msi.o
> -hw-obj-$(CONFIG_PCI) += pci_host.o pcie_host.o
> -hw-obj-$(CONFIG_PCI) += ioh3420.o xio3130_upstream.o xio3130_downstream.o
> -hw-obj-y += watchdog.o
> -hw-obj-$(CONFIG_ISA_MMIO) += isa_mmio.o
> -hw-obj-$(CONFIG_ECC) += ecc.o
> -hw-obj-$(CONFIG_NAND) += nand.o
> -hw-obj-$(CONFIG_PFLASH_CFI01) += pflash_cfi01.o
> -hw-obj-$(CONFIG_PFLASH_CFI02) += pflash_cfi02.o
> -
> -hw-obj-$(CONFIG_M48T59) += m48t59.o
> -hw-obj-$(CONFIG_ESCC) += escc.o
> -hw-obj-$(CONFIG_EMPTY_SLOT) += empty_slot.o
> -
> -hw-obj-$(CONFIG_SERIAL) += serial.o
> -hw-obj-$(CONFIG_PARALLEL) += parallel.o
> -hw-obj-$(CONFIG_I8254) += i8254.o
> -hw-obj-$(CONFIG_PCSPK) += pcspk.o
> -hw-obj-$(CONFIG_PCKBD) += pckbd.o
> -hw-obj-$(CONFIG_USB_UHCI) += usb-uhci.o
> -hw-obj-$(CONFIG_USB_OHCI) += usb-ohci.o
> -hw-obj-$(CONFIG_USB_EHCI) += usb-ehci.o
> -hw-obj-$(CONFIG_FDC) += fdc.o
> -hw-obj-$(CONFIG_ACPI) += acpi.o acpi_piix4.o
> -hw-obj-$(CONFIG_APM) += pm_smbus.o apm.o
> -hw-obj-$(CONFIG_DMA) += dma.o
> -hw-obj-$(CONFIG_HPET) += hpet.o
> -hw-obj-$(CONFIG_APPLESMC) += applesmc.o
> -hw-obj-$(CONFIG_SMARTCARD) += usb-ccid.o ccid-card-passthru.o
> -hw-obj-$(CONFIG_SMARTCARD_NSS) += ccid-card-emulated.o
> -hw-obj-$(CONFIG_USB_REDIR) += usb-redir.o
> -hw-obj-$(CONFIG_I8259) += i8259.o
> +common-obj-y += vl.o loader.o
> +common-obj-$(CONFIG_VIRTIO) += virtio-console.o
> +common-obj-y += usb-libhw.o
> +common-obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o
> +common-obj-y += fw_cfg.o
> +common-obj-$(CONFIG_PCI) += pci.o pci_bridge.o
> +common-obj-$(CONFIG_PCI) += msix.o msi.o
> +common-obj-$(CONFIG_PCI) += pci_host.o pcie_host.o
> +common-obj-$(CONFIG_PCI) += ioh3420.o xio3130_upstream.o xio3130_downstream.o
> +common-obj-y += watchdog.o
> +common-obj-$(CONFIG_ISA_MMIO) += isa_mmio.o
> +common-obj-$(CONFIG_ECC) += ecc.o
> +common-obj-$(CONFIG_NAND) += nand.o
> +common-obj-$(CONFIG_PFLASH_CFI01) += pflash_cfi01.o
> +common-obj-$(CONFIG_PFL

[Qemu-devel] [PATCH 1/2] pxa2xx_keypad: make single automatic scans work

[Vasily Khoruzhick]

u-boot uses single automatic scans and polling in
pxa2xx_keypad driver, so clear KPC_AS bit immediately
and update keys state even if KPC_AS and KPC_ASACT are
cleared.

Signed-off-by: Vasily Khoruzhick 
---
 hw/pxa2xx_keypad.c |   72 ++--
 1 files changed, 36 insertions(+), 36 deletions(-)

diff --git a/hw/pxa2xx_keypad.c b/hw/pxa2xx_keypad.c
index f86323f..1b9abbb 100644
--- a/hw/pxa2xx_keypad.c
+++ b/hw/pxa2xx_keypad.c
@@ -126,48 +126,45 @@ static void pxa27x_keyboard_event (PXA2xxKeyPadState *kp, 
int keycode)
 if(!(kp->kpc & KPC_ME)) /* skip if not enabled */
 return;
 
-if(kp->kpc & KPC_AS || kp->kpc & KPC_ASACT) {
-if(kp->kpc & KPC_AS)
-kp->kpc &= ~(KPC_AS);
-
-rel = (keycode & 0x80) ? 1 : 0; /* key release from qemu */
-keycode &= ~(0x80); /* strip qemu key release bit */
-if (kp->alt_code) {
-keycode |= 0x80;
-kp->alt_code = 0;
-}
+rel = (keycode & 0x80) ? 1 : 0; /* key release from qemu */
+keycode &= ~(0x80); /* strip qemu key release bit */
+if (kp->alt_code) {
+keycode |= 0x80;
+kp->alt_code = 0;
+}
 
-row = kp->map[keycode].row;
-col = kp->map[keycode].column;
-if(row == -1 || col == -1)
-return;
+row = kp->map[keycode].row;
+col = kp->map[keycode].column;
+if (row == -1 || col == -1) {
+return;
+}
 
-val = KPASMKPx_MKC(row, col);
-if (rel) {
-if (kp->kpasmkp[col / 2] & val) {
-kp->kpasmkp[col / 2] &= ~val;
-kp->pressed_cnt--;
-assert_irq = 1;
-}
-} else {
-if (!(kp->kpasmkp[col / 2] & val)) {
-kp->kpasmkp[col / 2] |= val;
-kp->pressed_cnt++;
-assert_irq = 1;
-}
+val = KPASMKPx_MKC(row, col);
+if (rel) {
+if (kp->kpasmkp[col / 2] & val) {
+kp->kpasmkp[col / 2] &= ~val;
+kp->pressed_cnt--;
+assert_irq = 1;
 }
-kp->kpas = ((kp->pressed_cnt & 0x1f) << 26) | (0xf << 4) | 0xf;
-if (kp->pressed_cnt == 1) {
-kp->kpas &= ~((0xf << 4) | 0xf);
-if (rel)
-pxa27x_keypad_find_pressed_key(kp, &row, &col);
-kp->kpas |= ((row & 0xf) << 4) | (col & 0xf);
+} else {
+if (!(kp->kpasmkp[col / 2] & val)) {
+kp->kpasmkp[col / 2] |= val;
+kp->pressed_cnt++;
+assert_irq = 1;
 }
-goto out;
 }
-return;
+kp->kpas = ((kp->pressed_cnt & 0x1f) << 26) | (0xf << 4) | 0xf;
+if (kp->pressed_cnt == 1) {
+kp->kpas &= ~((0xf << 4) | 0xf);
+if (rel) {
+pxa27x_keypad_find_pressed_key(kp, &row, &col);
+}
+kp->kpas |= ((row & 0xf) << 4) | (col & 0xf);
+}
+
+if (!(kp->kpc & KPC_AS || kp->kpc & KPC_ASACT))
+assert_irq = 0;
 
-out:
 if (assert_irq && (kp->kpc & KPC_MIE)) {
 kp->kpc |= KPC_MI;
 qemu_irq_raise(kp->irq);
@@ -245,6 +242,9 @@ static void pxa2xx_keypad_write(void *opaque, 
target_phys_addr_t offset,
 switch (offset) {
 case KPC:
 s->kpc = value;
+if (s->kpc & KPC_AS) {
+s->kpc &= ~(KPC_AS);
+}
 break;
 case KPDK:
 s->kpdk = value;
-- 
1.7.8.3

[Qemu-devel] [PATCH 2/2] pxa2xx_lcd: fix palette parser

[Vasily Khoruzhick]

Pallete entry size for 16bpp format is 2 bytes, not 4

Signed-off-by: Vasily Khoruzhick 
---
 hw/pxa2xx_lcd.c |   51 ---
 1 files changed, 28 insertions(+), 23 deletions(-)

diff --git a/hw/pxa2xx_lcd.c b/hw/pxa2xx_lcd.c
index 5dd4ef0..02e237e 100644
--- a/hw/pxa2xx_lcd.c
+++ b/hw/pxa2xx_lcd.c
@@ -574,7 +574,8 @@ static const MemoryRegionOps pxa2xx_lcdc_ops = {
 static void pxa2xx_palette_parse(PXA2xxLCDState *s, int ch, int bpp)
 {
 int i, n, format, r, g, b, alpha;
-uint32_t *dest, *src;
+uint32_t *dest;
+uint8_t *src;
 s->pal_for = LCCR4_PALFOR(s->control[4]);
 format = s->pal_for;
 
@@ -593,7 +594,7 @@ static void pxa2xx_palette_parse(PXA2xxLCDState *s, int ch, 
int bpp)
 return;
 }
 
-src = (uint32_t *) s->dma_ch[ch].pbuffer;
+src = (uint8_t *) s->dma_ch[ch].pbuffer;
 dest = (uint32_t *) s->dma_ch[ch].palette;
 alpha = r = g = b = 0;
 
@@ -601,43 +602,48 @@ static void pxa2xx_palette_parse(PXA2xxLCDState *s, int 
ch, int bpp)
 switch (format) {
 case 0: /* 16 bpp, no transparency */
 alpha = 0;
-if (s->control[0] & LCCR0_CMS)
-r = g = b = *src & 0xff;
+if (s->control[0] & LCCR0_CMS) {
+r = g = b = *(uint16_t *)src & 0xff;
+}
 else {
-r = (*src & 0xf800) >> 8;
-g = (*src & 0x07e0) >> 3;
-b = (*src & 0x001f) << 3;
+r = (*(uint16_t *)src & 0xf800) >> 8;
+g = (*(uint16_t *)src & 0x07e0) >> 3;
+b = (*(uint16_t *)src & 0x001f) << 3;
 }
+src += 2;
 break;
 case 1: /* 16 bpp plus transparency */
-alpha = *src & (1 << 24);
+alpha = *(uint16_t *)src & (1 << 24);
 if (s->control[0] & LCCR0_CMS)
-r = g = b = *src & 0xff;
+r = g = b = *(uint16_t *)src & 0xff;
 else {
-r = (*src & 0xf800) >> 8;
-g = (*src & 0x07e0) >> 3;
-b = (*src & 0x001f) << 3;
+r = (*(uint16_t *)src & 0xf800) >> 8;
+g = (*(uint16_t *)src & 0x07e0) >> 3;
+b = (*(uint16_t *)src & 0x001f) << 3;
 }
+src += 2;
 break;
 case 2: /* 18 bpp plus transparency */
-alpha = *src & (1 << 24);
+alpha = *(uint32_t *)src & (1 << 24);
 if (s->control[0] & LCCR0_CMS)
-r = g = b = *src & 0xff;
+r = g = b = *(uint32_t *)src & 0xff;
 else {
-r = (*src & 0xf8) >> 16;
-g = (*src & 0x00fc00) >> 8;
-b = (*src & 0xf8);
+r = (*(uint32_t *)src & 0xf8) >> 16;
+g = (*(uint32_t *)src & 0x00fc00) >> 8;
+b = (*(uint32_t *)src & 0xf8);
 }
+src += 4;
 break;
 case 3: /* 24 bpp plus transparency */
-alpha = *src & (1 << 24);
+alpha = *(uint32_t *)src & (1 << 24);
 if (s->control[0] & LCCR0_CMS)
-r = g = b = *src & 0xff;
+r = g = b = *(uint32_t *)src & 0xff;
 else {
-r = (*src & 0xff) >> 16;
-g = (*src & 0x00ff00) >> 8;
-b = (*src & 0xff);
+r = (*(uint32_t *)src & 0xff) >> 16;
+g = (*(uint32_t *)src & 0x00ff00) >> 8;
+b = (*(uint32_t *)src & 0xff);
 }
+src += 4;
 break;
 }
 switch (ds_get_bits_per_pixel(s->ds)) {
@@ -657,7 +663,6 @@ static void pxa2xx_palette_parse(PXA2xxLCDState *s, int ch, 
int bpp)
 *dest = rgb_to_pixel32(r, g, b) | alpha;
 break;
 }
-src ++;
 dest ++;
 }
 }
-- 
1.7.8.3

[Qemu-devel] icount and tb chaining

[James Greensky]

Hello all, I have a question about icount and tb chaining that I hope
somebody can clear up.  In cpu-exec.c, when the icount_decr.u16.low
counter expires, it passes back the current tb as the next_tb and add
a jump with the least significant bits = 2. This falls through to tb
add jump, which then updates the jmp_first field of the current tb.
why is this done? Thanks -Jim

[Qemu-devel] icount and tb chaining

[James Greensky]

Hello all, I have a question about icount and tb chaining that I hope
somebody can clear up.  In cpu-exec.c, when the icount_decr.u16.low
counter expires, it passes back the current tb as the next_tb and add
a jump with the least significant bits = 2. This falls through to tb
add jump, which then updates the jmp_first field of the current tb.
why is this done? Thanks -Jim

Re: [Qemu-devel] [PATCH v2] qemu-ga: add guest-set-support-level command

[Luiz Capitulino]

On Wed, 11 Jan 2012 17:56:05 -0600
Michael Roth  wrote:

> Recently commands where introduced on the mailing that involved adding
> commands to the guest agent that could potentially break older versions
> of QEMU. While it's okay to expect that qemu-ga can be updated to support
> newer host features, it's unrealistic to require a host to be updated to
> support qemu-ga features, or to expect that qemu-ga should be downgraded
> in these circumstances, especially considering that a large mix of
> guests/agents may be running on a particular host.
> 
> To address this, we introduce here a mechanism to set qemu-ga's
> feature-set to one that is known to be compatible with
> the host/QEMU running the guest. As new commands/options are added, we
> can maintain backward-compatibility by adding conditional checks to filter
> out host-incompatible functionality based on the host-specified support
> level (generally analogous to the host QEMU version) set by the
> client.
> 
> The current default/minimum support level supports all versions of QEMU
> that have had qemu-ga in-tree (0.15.0, 1.0.0) and so should be
> backward-compatible with existing hosts/clients.

The approach looks fine to me. I have a few review comments below.

> 
> Signed-off-by: Michael Roth 
> ---
>  qapi-schema-guest.json |   31 -
>  qemu-ga.c  |   46 
> 
>  qga/guest-agent-commands.c |   13 
>  qga/guest-agent-core.h |   11 ++
>  4 files changed, 100 insertions(+), 1 deletions(-)
> 
> diff --git a/qapi-schema-guest.json b/qapi-schema-guest.json
> index 5f8a18d..32bc041 100644
> --- a/qapi-schema-guest.json
> +++ b/qapi-schema-guest.json
> @@ -43,15 +43,44 @@
>  #
>  # Since: 0.15.0
>  ##
> +{ 'type': 'GuestAgentSupportLevel',
> +  'data': { 'major': 'int', 'minor': 'int', 'micro': 'int' } }

This and GuestAgentCommandInfo are missing good documentation. Looks like
we don't document types as we do in qapi-schema.json. I think we should.

>  { 'type': 'GuestAgentCommandInfo',
>'data': { 'name': 'str', 'enabled': 'bool' } }
>  { 'type': 'GuestAgentInfo',
>'data': { 'version': 'str',
> -'supported_commands': ['GuestAgentCommandInfo'] } }
> +'supported_commands': ['GuestAgentCommandInfo']
> +'support_level': 'GuestAgentSupportLevel' } }
>  { 'command': 'guest-info',
>'returns': 'GuestAgentInfo' }

For example, something important that's is not totally clear to me just by
reading the command definition is if 'support_level' refers to the support
level that can be changed by a client.

>  
>  ##
> +# @guest-set-support-level:
> +#
> +# Set guest agent feature-set to one that is compatible with/supported by
> +# the host.
> +#
> +# Certain commands/options may have dependencies on host
> +# version/support-level, such as specific QEMU features (such
> +# dependencies will be noted in this schema). By default we assume 1.0.0,
> +# which is backward-compatible with QEMU 0.15.0/1.0, and should be compatible
> +# with later versions of QEMU as well. To enable newer guest agent features,
> +# this command must be issued to raise the support-level to one corresponding
> +# to supported host QEMU/KVM/etc capabilities.
> +#
> +# The currently set support level is obtainable via the guest-info command.
> +#
> +# @level: Desired host support-level, generally <= host QEMU version
> +# level. Note that undefined behavior may occur if a support-level is
> +# provided that exceeds the capabilities of the version of QEMU currently
> +# running the guest.

It's also better to note that if @level < 1.0.0 then the support level will
be set to 1.0.0.

> +#
> +# Returns: Nothing on success
> +#
> +{ 'command': 'guest-set-support-level',
> +  'data':{ 'major': 'int', 'minor': 'int', '*micro': 'int' } }
> +
> +##
>  # @guest-shutdown:
>  #
>  # Initiate guest-activated shutdown. Note: this is an asynchronous
> diff --git a/qemu-ga.c b/qemu-ga.c
> index 200bb15..6840233 100644
> --- a/qemu-ga.c
> +++ b/qemu-ga.c
> @@ -28,6 +28,7 @@
>  #include "qerror.h"
>  #include "error_int.h"
>  #include "qapi/qmp-core.h"
> +#include "qga-qapi-types.h"
>  
>  #define QGA_VIRTIO_PATH_DEFAULT "/dev/virtio-ports/org.qemu.guest_agent.0"
>  #define QGA_PIDFILE_DEFAULT "/var/run/qemu-ga.pid"
> @@ -102,6 +103,45 @@ static void usage(const char *cmd)
>  
>  static void conn_channel_close(GAState *s);
>  
> +static GuestAgentSupportLevel ga_support_level;
> +
> +static int ga_cmp_support_levels(GuestAgentSupportLevel a,
> + GuestAgentSupportLevel b)
> +{
> +if (a.major == b.major) {
> +if (a.minor == b.minor) {
> +return a.micro - b.micro;
> +}
> +return a.minor - b.minor;
> +}
> +return a.major - b.major;
> +}
> +
> +bool ga_has_support_level(int major, int minor, int micro)
> +{
> +GuestAgentSupportLevel level = { major, minor, micro };
> +r

Re: [Qemu-devel] [PATCH] build: fix target_phys_addr_t to 64-bit

[Andreas Färber]

Am 12.01.2012 18:54, schrieb Anthony Liguori:
> This simplifies the build quite a bit and improves the builds performance by
> not rebuilding many objects twice.
> 
> There were a surprising number of places that had assumed wrong things about 
> the
> size of target_phys_addr_t including that it was fixed at 32-bit and that it
> was identical to target_ulong.
> 
> Signed-off-by: Anthony Liguori 
> ---
>  Makefile|2 +-
>  Makefile.hw |   25 
>  Makefile.objs   |  182 
> +++
>  Makefile.target |4 -
>  configure   |   13 +
>  cpu-common.h|8 ---
>  dma.h   |2 -
>  hw/a9mpcore.c   |4 +-
>  hw/hw.h |2 +-
>  hw/intel-hda.c  |4 -
>  hw/omap.h   |6 --
>  hw/pxa2xx_dma.c |6 +-
>  hw/pxa2xx_lcd.c |6 +-
>  hw/rtl8139.c|4 -
>  hw/sh_serial.c  |6 +-
>  monitor.c   |   21 --
>  qemu-log.h  |4 +-
>  targphys.h  |   11 ---
>  18 files changed, 106 insertions(+), 204 deletions(-)
>  delete mode 100644 Makefile.hw

> diff --git a/cpu-common.h b/cpu-common.h
> index a40c57d..85a3b35 100644
> --- a/cpu-common.h
> +++ b/cpu-common.h

> @@ -23,15 +21,9 @@ enum device_endian {
>  };
>  
>  /* address in the RAM (different from a physical address) */
> -#if defined(CONFIG_XEN_BACKEND) && TARGET_PHYS_ADDR_BITS == 64
>  typedef uint64_t ram_addr_t;
>  #  define RAM_ADDR_MAX UINT64_MAX
>  #  define RAM_ADDR_FMT "%" PRIx64
> -#else
> -typedef unsigned long ram_addr_t;
> -#  define RAM_ADDR_MAX ULONG_MAX
> -#  define RAM_ADDR_FMT "%lx"
> -#endif

$subject should mention ram_addr_t being changed as well.

> diff --git a/hw/pxa2xx_dma.c b/hw/pxa2xx_dma.c
> index cb28107..ffb391d 100644
> --- a/hw/pxa2xx_dma.c
> +++ b/hw/pxa2xx_dma.c
> @@ -512,9 +512,9 @@ static VMStateDescription vmstate_pxa2xx_dma_chan = {
>  .minimum_version_id = 1,
>  .minimum_version_id_old = 1,
>  .fields = (VMStateField[]) {
> -VMSTATE_UINTTL(descr, PXA2xxDMAChannel),
> -VMSTATE_UINTTL(src, PXA2xxDMAChannel),
> -VMSTATE_UINTTL(dest, PXA2xxDMAChannel),
> +VMSTATE_UINT64(descr, PXA2xxDMAChannel),
> +VMSTATE_UINT64(src, PXA2xxDMAChannel),
> +VMSTATE_UINT64(dest, PXA2xxDMAChannel),
>  VMSTATE_UINT32(cmd, PXA2xxDMAChannel),
>  VMSTATE_UINT32(state, PXA2xxDMAChannel),
>  VMSTATE_INT32(request, PXA2xxDMAChannel),
> diff --git a/hw/pxa2xx_lcd.c b/hw/pxa2xx_lcd.c
> index 5dd4ef0..a84cd77 100644
> --- a/hw/pxa2xx_lcd.c
> +++ b/hw/pxa2xx_lcd.c
> @@ -921,11 +921,11 @@ static const VMStateDescription vmstate_dma_channel = {
>  .minimum_version_id = 0,
>  .minimum_version_id_old = 0,
>  .fields  = (VMStateField[]) {
> -VMSTATE_UINTTL(branch, struct DMAChannel),
> +VMSTATE_UINT64(branch, struct DMAChannel),
>  VMSTATE_UINT8(up, struct DMAChannel),
>  VMSTATE_BUFFER(pbuffer, struct DMAChannel),
> -VMSTATE_UINTTL(descriptor, struct DMAChannel),
> -VMSTATE_UINTTL(source, struct DMAChannel),
> +VMSTATE_UINT64(descriptor, struct DMAChannel),
> +VMSTATE_UINT64(source, struct DMAChannel),
>  VMSTATE_UINT32(id, struct DMAChannel),
>  VMSTATE_UINT32(command, struct DMAChannel),
>  VMSTATE_END_OF_LIST()

I'm pretty sure that PXA was 32-bit (arm), so version_id and
minimum_version_id need to be bumped.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

[Qemu-devel] Serious regression of 9p read performance, huge amount of openat syscalls on plain file descriptors

[Lutz Vieweg]

Hi all,

I have been using 9p mounts on guests for quite some time, and enjoyed
their nice performance.

But not anymore: I noticed that just "dd"-ing large plain files to /dev/zero
on the guest system became very slow, even if the data is completely
in the cache of the host. The rate maxes at ~ 30MB/s while the qemu process
on the host eats lots of CPU).
Both qemu (from source repository) and host kernel (3.1.6)
were upgraded since the last good benchmark, so this could be the
result of some recent change...

Looking for the cause I noticed that the qemu process, according to strace,
does an insane amount of "openat" syscalls - about 820 per second! - while
the guest system is reading the file (in 64kB chunks, if that matters).
I guess it's no wonder that this huge amount of "open" operations per
second will slow down whatever I/O qemu is trying to do.

Especially strange is that the fds passed into the openat syscall as the
first parameter refers to the file being read (not the directory it is in,
which has a different fd), according to "lsof".
And the openat syscall always returns 0x1000 as a result (if strace is not
lying), which is neither a credible fd, nor an errno I'd know of:


[pid 29236] syscall_295(0x1b, 0x7fe46044a670, 0x1, 0x109e000, 0, 0, 0x7fe46034ae00, 
0x7fe46034ae00, 0x7fe46034ae00, 0x7fe46034ae00, 0x7fe46034ae00, 0x7fe46034ae00, 
0x7fe46034ae00, 0x7fe46034ae00, 0x7fe46034ae00, 0x7fe46034ae00, 0x7fe46034ae00, 
0x7fe46034ae00, 0x7fe46034ae00, 0x7fe46034ae00, 0x7fe46034ae00, 0x7fe46034ae00, 
0x7fe46034ae00, 0x7fe46034ae00, 0x7fe46034ae00, 0x7fe46034ae00, 0x7fe46034ae00, 
0x7fe46034ae00, 0x7fe46034ae00, 0x7fe46034ae00, 0x7fe46034ae00, 0x7fe46034ae00 

[pid 29236] <... syscall_295 resumed> ) = 0x1000
[pid 29235] syscall_295(0x1c, 0x7fe4659d8070, 0x1, 0x16df000, 0, 0, 0x7fe4658d8800, 
0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800, 
0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800, 
0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800, 
0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800, 
0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800 

[pid 29235] <... syscall_295 resumed> ) = 0x1000
[pid 29234] syscall_295(0x1b, 0x7fe4659d8070, 0x1, 0x109f000, 0, 0, 0x7fe4658d8800, 
0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800, 
0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800, 
0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800, 
0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800, 
0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800, 0x7fe4658d8800 

[pid 29234] <... syscall_295 resumed> ) = 0x1000


Alas, I could not get gdb to tell me exactly where those openat calls are
made from (in the qemu-kvm source) - the functions that contain those calls
are static and seem to become inlined.

Does anyone have an idea what may have caused this? Do you still see
good read performance when reading big plain files from a 9p mount.

Regards,

Lutz Vieweg

Re: [Qemu-devel] [PATCH] hw/vmmouse.c: Fix to disable vmmouse after reboot

[Andreas Färber]

Am 08.01.2012 17:31, schrieb Andreas Färber:
> Am 08.01.2012 13:01, schrieb Gerhard Wiesinger:
>> On Wed, 4 Jan 2012, Gerhard Wiesinger wrote:
>>
>>> Testscenario:
>>> 1.) Boot e.g. OS with VMMouse support (e.g. Windows)
>>> 2.) reboot
>>> 3.) Boot e.g. OS without VMMouse support (e.g. DOS) => PS/2 mouse
>>> doesn't work any more. Fixes that issue.
>>>
>>> Reason is that VMMouse has priority and disables all other mouse
>>> entities and therefore must be disabled on reset.
>>
>> Any further comments before integrating the patch?
> 
> I implicitly asked you for a more verbose commit message.
> 
> For example, based on the info you provided as a reply above:
> 
> --8<--
> hw/vmmouse.c: Disable vmmouse on reboot
> 
> When a guest activated the vmmouse, following a reboot the vmmouse
> stayed enabled and the PS/2 mouse was unusable. That way, when rebooting
> to guests without vmmouse support the mouse would not work.
> 
> Fix this by disabling the vmmouse in its reset handler.
> --8<--

I have been unable to reproduce this issue with our qemu-kvm 0.15.1.
SLES 11 uses vmmouse, whereas SLES installation does not use vmmouse.
After doing a kdump or reboot in SLES, the mouse worked just fine in
either of them.

The patch doesn't break anything for me though.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

[Qemu-devel] [PATCH 3/7] kvm-ppc: halt secondary cpus when guest reset

[Alexander Graf]

From: Liu Yu-B13201 

When guest reset, we need to halt secondary cpus until guest kick them.
This already works for tcg. The patch add the support for kvm.

Signed-off-by: Liu Yu 
Signed-off-by: Alexander Graf 
[agraf: remove in-kernel irqchip code]
(cherry picked from commit 157feeadbaec09fe4dca539a24f6f6d327d6eeb6)
---
 hw/ppce500_spin.c |1 +
 target-ppc/kvm.c  |2 +-
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/hw/ppce500_spin.c b/hw/ppce500_spin.c
index cccd940..2b52728 100644
--- a/hw/ppce500_spin.c
+++ b/hw/ppce500_spin.c
@@ -112,6 +112,7 @@ static void spin_kick(void *data)
 
 env->halted = 0;
 env->exception_index = -1;
+env->stopped = 0;
 qemu_cpu_kick(env);
 }
 
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 429349f..9b2e605 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -504,7 +504,7 @@ void kvm_arch_post_run(CPUState *env, struct kvm_run *run)
 
 int kvm_arch_process_async_events(CPUState *env)
 {
-return 0;
+return env->halted;
 }
 
 static int kvmppc_handle_halt(CPUState *env)
-- 
1.6.0.2

[Qemu-devel] [PATCH 5/7] pseries: Add a routine to find a stable "default" vty and use it

[Alexander Graf]

From: David Gibson 

In vty_lookup() we have a special case for supporting early debug in
the kernel. This accepts reg == 0 as a special case to mean "any vty".

We implement this by searching the vtys on the bus and returning the
first we find. This means that the vty we chose depends on the order
the vtys are specified on the QEMU command line - because that determines
the order of the vtys on the bus.

We'd rather the command line order was irrelevant, so instead return
the vty with the lowest reg value. This is still a guess as to what the
user really means, but it is at least stable WRT command line ordering.

Signed-off-by: Michael Ellerman 
Signed-off-by: David Gibson 
Signed-off-by: Alexander Graf 

[agraf] fix braces
(cherry picked from commit 98331f8ad6a3e2cfbb402d72e6be47eac7706251)
---
 hw/spapr_vty.c |   47 ++-
 1 files changed, 38 insertions(+), 9 deletions(-)

diff --git a/hw/spapr_vty.c b/hw/spapr_vty.c
index f23cc36..e2fec58 100644
--- a/hw/spapr_vty.c
+++ b/hw/spapr_vty.c
@@ -156,24 +156,53 @@ static VIOsPAPRDeviceInfo spapr_vty = {
 },
 };
 
+static VIOsPAPRDevice *spapr_vty_get_default(VIOsPAPRBus *bus)
+{
+VIOsPAPRDevice *sdev, *selected;
+DeviceState *iter;
+
+/*
+ * To avoid the console bouncing around we want one VTY to be
+ * the "default". We haven't really got anything to go on, so
+ * arbitrarily choose the one with the lowest reg value.
+ */
+
+selected = NULL;
+QTAILQ_FOREACH(iter, &bus->bus.children, sibling) {
+/* Only look at VTY devices */
+if (iter->info != &spapr_vty.qdev) {
+continue;
+}
+
+sdev = DO_UPCAST(VIOsPAPRDevice, qdev, iter);
+
+/* First VTY we've found, so it is selected for now */
+if (!selected) {
+selected = sdev;
+continue;
+}
+
+/* Choose VTY with lowest reg value */
+if (sdev->reg < selected->reg) {
+selected = sdev;
+}
+}
+
+return selected;
+}
+
 static VIOsPAPRDevice *vty_lookup(sPAPREnvironment *spapr, target_ulong reg)
 {
 VIOsPAPRDevice *sdev;
 
 sdev = spapr_vio_find_by_reg(spapr->vio_bus, reg);
 if (!sdev && reg == 0) {
-DeviceState *qdev;
-
 /* Hack for kernel early debug, which always specifies reg==0.
- * We search all VIO devices, and grab the first available vty
- * device.  This attempts to mimic existing PowerVM behaviour
+ * We search all VIO devices, and grab the vty with the lowest
+ * reg.  This attempts to mimic existing PowerVM behaviour
  * (early debug does work there, despite having no vty with
  * reg==0. */
-QTAILQ_FOREACH(qdev, &spapr->vio_bus->bus.children, sibling) {
-if (qdev->info == &spapr_vty.qdev) {
-return DO_UPCAST(VIOsPAPRDevice, qdev, qdev);
-}
-}
+return spapr_vty_get_default(spapr->vio_bus);
 }
 
 return sdev;
-- 
1.6.0.2

[Qemu-devel] [PATCH 1/7] console: Fix segfault on screendump without VGA adapter

[Alexander Graf]

When trying to create a screen dump without having any VGA adapter
inside the guest, QEMU segfaults.

This is because it's trying to switch back to the "previous" screen
it was on before dumping the VGA screen. Unfortunately, in my case
there simply is no previous screen so it accesses a NULL pointer.

Fix it by checking if previous_active_console is actually available.

This is 1.0 material.

Signed-off-by: Alexander Graf 
---
 console.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/console.c b/console.c
index f6fe441..ed6a653 100644
--- a/console.c
+++ b/console.c
@@ -186,7 +186,9 @@ void vga_hw_screen_dump(const char *filename)
 consoles[0]->hw_screen_dump(consoles[0]->hw, filename);
 }
 
-console_select(previous_active_console->index);
+if (previous_active_console) {
+console_select(previous_active_console->index);
+}
 }
 
 void vga_hw_text_update(console_ch_t *chardata)
-- 
1.6.0.2

[Qemu-devel] [PATCH 4/7] pseries: Emit device tree nodes in reg order

[Alexander Graf]

From: David Gibson 

Although in theory the device tree has no inherent ordering, in practice
the order of nodes in the device tree does effect the order that devices
are detected by software.

Currently the ordering is determined by the order the devices appear on
the QEMU command line. Although that does give the user control over the
ordering, it is fragile, especially when the user does not generate the
command line manually - eg. when using libvirt etc.

So order the device tree based on the reg value, ie. the address of on
the VIO bus of the devices. This gives us a sane and stable ordering.

Signed-off-by: Michael Ellerman 
Signed-off-by: David Gibson 
Signed-off-by: Alexander Graf 

[agraf] add braces
(cherry picked from commit 05c194384f836240ea4c2da5fa3be43a54bff021)
---
 hw/spapr_vio.c |   50 +-
 1 files changed, 45 insertions(+), 5 deletions(-)

diff --git a/hw/spapr_vio.c b/hw/spapr_vio.c
index 2dcc036..8bd00ca 100644
--- a/hw/spapr_vio.c
+++ b/hw/spapr_vio.c
@@ -749,21 +749,61 @@ static void spapr_vio_register_devices(void)
 device_init(spapr_vio_register_devices)
 
 #ifdef CONFIG_FDT
+static int compare_reg(const void *p1, const void *p2)
+{
+VIOsPAPRDevice const *dev1, *dev2;
+
+dev1 = (VIOsPAPRDevice *)*(DeviceState **)p1;
+dev2 = (VIOsPAPRDevice *)*(DeviceState **)p2;
+
+if (dev1->reg < dev2->reg) {
+return -1;
+}
+if (dev1->reg == dev2->reg) {
+return 0;
+}
+
+/* dev1->reg > dev2->reg */
+return 1;
+}
+
 int spapr_populate_vdevice(VIOsPAPRBus *bus, void *fdt)
 {
-DeviceState *qdev;
-int ret = 0;
+DeviceState *qdev, **qdevs;
+int i, num, ret = 0;
 
+/* Count qdevs on the bus list */
+num = 0;
 QTAILQ_FOREACH(qdev, &bus->bus.children, sibling) {
-VIOsPAPRDevice *dev = (VIOsPAPRDevice *)qdev;
+num++;
+}
+
+/* Copy out into an array of pointers */
+qdevs = g_malloc(sizeof(qdev) * num);
+num = 0;
+QTAILQ_FOREACH(qdev, &bus->bus.children, sibling) {
+qdevs[num++] = qdev;
+}
+
+/* Sort the array */
+qsort(qdevs, num, sizeof(qdev), compare_reg);
+
+/* Hack alert. Give the devices to libfdt in reverse order, we happen
+ * to know that will mean they are in forward order in the tree. */
+for (i = num - 1; i >= 0; i--) {
+VIOsPAPRDevice *dev = (VIOsPAPRDevice *)(qdevs[i]);
 
 ret = vio_make_devnode(dev, fdt);
 
 if (ret < 0) {
-return ret;
+goto out;
 }
 }
 
-return 0;
+ret = 0;
+out:
+free(qdevs);
+
+return ret;
 }
 #endif /* CONFIG_FDT */
-- 
1.6.0.2

[Qemu-devel] [PATCH 7/7] pseries: Don't try to munmap() a malloc()ed TCE table

[Alexander Graf]

From: David Gibson 

For the pseries machine, TCE (IOMMU) tables can either be directly
malloc()ed in qemu or, when running on a KVM which supports it, mmap()ed
from a KVM ioctl.  The latter option is used when available, because it
allows the (frequent bottlenext) H_PUT_TCE hypercall to be KVM accelerated.
However, even when KVM is persent, TCE acceleration is not always possible.
Only KVM HV supports this ioctl(), not KVM PR, or the kernel could run out
of contiguous memory to allocate the new table.  In this case we need to
fall back on the malloc()ed table.

When a device is removed, and we need to remove the TCE table, we need to
either munmap() or free() the table as appropriate for how it was
allocated.  The code is supposed to do that, but we buggily fail to
initialize the tcet->fd variable in the malloc() case, which is used as a
flag to determine which is the right choice.

This patch fixes the bug, and cleans up error messages relating to this
path while we're at it.

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: David Gibson 
Signed-off-by: Alexander Graf 
---
 target-ppc/kvm.c |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 9b2e605..0410901 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -838,12 +838,18 @@ void *kvmppc_create_spapr_tce(uint32_t liobn, uint32_t 
window_size, int *pfd)
 int fd;
 void *table;
 
+/* Must set fd to -1 so we don't try to munmap when called for
+ * destroying the table, which the upper layers -will- do
+ */
+*pfd = -1;
 if (!cap_spapr_tce) {
 return NULL;
 }
 
 fd = kvm_vm_ioctl(kvm_state, KVM_CREATE_SPAPR_TCE, &args);
 if (fd < 0) {
+fprintf(stderr, "KVM: Failed to create TCE table for liobn 0x%x\n",
+liobn);
 return NULL;
 }
 
@@ -852,6 +858,8 @@ void *kvmppc_create_spapr_tce(uint32_t liobn, uint32_t 
window_size, int *pfd)
 
 table = mmap(NULL, len, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
 if (table == MAP_FAILED) {
+fprintf(stderr, "KVM: Failed to map TCE table for liobn 0x%x\n",
+liobn);
 close(fd);
 return NULL;
 }
@@ -871,8 +879,8 @@ int kvmppc_remove_spapr_tce(void *table, int fd, uint32_t 
window_size)
 len = (window_size / SPAPR_VIO_TCE_PAGE_SIZE)*sizeof(VIOsPAPR_RTCE);
 if ((munmap(table, len) < 0) ||
 (close(fd) < 0)) {
-fprintf(stderr, "KVM: Unexpected error removing KVM SPAPR TCE "
-"table: %s", strerror(errno));
+fprintf(stderr, "KVM: Unexpected error removing TCE table: %s",
+strerror(errno));
 /* Leak the table */
 }
 
-- 
1.6.0.2

[Qemu-devel] [PATCH -V2] hw/9pfs: Add new security model mapped-file.

[Aneesh Kumar K.V]

From: "Aneesh Kumar K.V" 

This enable us to do passthrough equivalent security model on NFS directory.
NFS server mostly do root squashing and don't support xattr. Hence we cannot
use 'passthrough' or 'mapped' security model

Also added "mapped-xattr" security to indicate earlier "mapped" security model
Older name is still supported.

POSIX rules regarding ctime update on chmod are not followed by this security 
model.

Signed-off-by: Aneesh Kumar K.V 
---
 fsdev/file-op-9p.h |   12 +-
 hw/9pfs/cofile.c   |   14 ++
 hw/9pfs/virtio-9p-device.c |9 --
 hw/9pfs/virtio-9p-local.c  |  341 +++-
 4 files changed, 359 insertions(+), 17 deletions(-)

diff --git a/fsdev/file-op-9p.h b/fsdev/file-op-9p.h
index 1e96c8b..956fda0 100644
--- a/fsdev/file-op-9p.h
+++ b/fsdev/file-op-9p.h
@@ -56,11 +56,15 @@ typedef struct extended_ops {
  * On failure ignore the error.
  */
 #define V9FS_SM_NONE0x0010
-#define V9FS_RDONLY 0x0020
-#define V9FS_PROXY_SOCK_FD  0x0040
-#define V9FS_PROXY_SOCK_NAME0x0080
+/*
+ * uid/gid part of .virtfs_meatadata namespace
+ */
+#define V9FS_SM_MAPPED_FILE 0x0020
+#define V9FS_RDONLY 0x0040
+#define V9FS_PROXY_SOCK_FD  0x0080
+#define V9FS_PROXY_SOCK_NAME0x0100
 
-#define V9FS_SEC_MASK   0x001C
+#define V9FS_SEC_MASK   0x003C
 
 
 typedef struct FileOperations FileOperations;
diff --git a/hw/9pfs/cofile.c b/hw/9pfs/cofile.c
index b15838c..9345aae 100644
--- a/hw/9pfs/cofile.c
+++ b/hw/9pfs/cofile.c
@@ -76,6 +76,20 @@ int v9fs_co_fstat(V9fsPDU *pdu, V9fsFidState *fidp, struct 
stat *stbuf)
 err = -errno;
 }
 });
+/*
+ * Some FS driver (local:mapped-file) can't support fetching attributes
+ * using file descriptor. Use Path name in that case.
+ */
+if (err == -EOPNOTSUPP) {
+err = v9fs_co_lstat(pdu, &fidp->path, stbuf);
+if (err == -ENOENT) {
+/*
+ * fstat on an unlinked file. Work with partial results
+ * returned from s->ops->fstat
+ */
+err = 0;
+}
+}
 return err;
 }
 
diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
index 642d5e2..41a1a82 100644
--- a/hw/9pfs/virtio-9p-device.c
+++ b/hw/9pfs/virtio-9p-device.c
@@ -91,15 +91,6 @@ VirtIODevice *virtio_9p_init(DeviceState *dev, V9fsConf 
*conf)
 s->ctx.fs_root = NULL;
 }
 s->ctx.exops.get_st_gen = NULL;
-
-if (fse->export_flags & V9FS_SM_PASSTHROUGH) {
-s->ctx.xops = passthrough_xattr_ops;
-} else if (fse->export_flags & V9FS_SM_MAPPED) {
-s->ctx.xops = mapped_xattr_ops;
-} else if (fse->export_flags & V9FS_SM_NONE) {
-s->ctx.xops = none_xattr_ops;
-}
-
 len = strlen(conf->tag);
 if (len > MAX_TAG_LEN - 1) {
 fprintf(stderr, "mount tag '%s' (%d bytes) is longer than "
diff --git a/hw/9pfs/virtio-9p-local.c b/hw/9pfs/virtio-9p-local.c
index 3ae6ef2..b86d874 100644
--- a/hw/9pfs/virtio-9p-local.c
+++ b/hw/9pfs/virtio-9p-local.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include "qemu-xattr.h"
+#include 
 #include 
 #ifdef CONFIG_LINUX_MAGIC_H
 #include 
@@ -39,6 +40,54 @@
 #define BTRFS_SUPER_MAGIC 0x9123683E
 #endif
 
+#define VIRTFS_META_DIR ".virtfs_metadata"
+
+static const char *local_mapped_attr_path(FsContext *ctx,
+  const char *path, char *buffer)
+{
+char *dir_name;
+char *tmp_path = strdup(path);
+char *base_name = basename(tmp_path);
+
+/* NULL terminate the directory */
+dir_name = tmp_path;
+*(base_name - 1) = '\0';
+
+snprintf(buffer, PATH_MAX, "%s/%s/%s/%s",
+ ctx->fs_root, dir_name, VIRTFS_META_DIR, base_name);
+free(tmp_path);
+return buffer;
+}
+
+#define ATTR_MAX 100
+static void local_mapped_file_attr(FsContext *ctx, const char *path,
+   struct stat *stbuf)
+{
+FILE *fp;
+char buf[ATTR_MAX];
+char attr_path[PATH_MAX];
+
+local_mapped_attr_path(ctx, path, attr_path);
+fp = fopen(attr_path, "r");
+if (!fp) {
+return;
+}
+memset(buf, 0, ATTR_MAX);
+while (fgets(buf, ATTR_MAX, fp)) {
+if (!strncmp(buf, "virtfs.uid", 10)) {
+stbuf->st_uid = atoi(buf+11);
+} else if (!strncmp(buf, "virtfs.gid", 10)) {
+stbuf->st_gid = atoi(buf+11);
+} else if (!strncmp(buf, "virtfs.mode", 11)) {
+stbuf->st_mode = atoi(buf+12);
+} else if (!strncmp(buf, "virtfs.rdev", 11)) {
+stbuf->st_rdev = atoi(buf+12);
+}
+memset(buf, 0, ATTR_MAX);
+}
+fclose(fp);
+}
+
 static int local_lstat(FsContext *fs_ctx, V9fsPath *fs_path, struct stat 
*stbuf)
 {
 int err;
@@ -71,10 +120,94 @@ static int local_lstat(FsContext *fs_ctx, V9fsPath 
*fs_path, struct s

Re: [Qemu-devel] [PATCH V14 0/7] Qemu Trusted Platform Module (TPM) integration

[Paul Moore]

On Wednesday, December 14, 2011 08:43:15 AM Stefan Berger wrote:
> The following series of patches adds TPM (Trusted Platform Module) support
> to Qemu. An emulator for the TIS (TPM Interface Spec) interface is
> added that provides the basis for accessing a 'backend' implementing the
> actual TPM functionality. The TIS emulator serves as a 'frontend' enabling
> for example Linux's TPM TIS (tpm_tis) driver.

Hi Stefan,

Thanks for updating these, I apologize for not tracking the updates very 
closely over the past several revisions but I do have the v14 revision up and 
running and while my testing so far has been fairly basic and crude, 
everything appears to be working as it should.  I'm going to try and throw 
some more comprehensive tests at it and I'll let you know if anything goes 
awry.

To the rest of the QEMU crew,

The comments on the patchset seems to be dwindling, we're on the 14th revision 
and it looks like most of the issues have been addressed - any hope on getting 
this merged in the near future?

Thanks.

-- 
paul moore
virtualization @ redhat

[Qemu-devel] [PATCH 2/7] pseries: Fix array overrun bug in PCI code

[Alexander Graf]

From: David Gibson 

spapr_populate_pci_devices() containd a loop with PCI_NUM_REGIONS (7)
iterations.  However this overruns the 'bars' global array, which only has
6 elements. In fact we only want to run this loop for things listed in the
bars array, so this patch corrects the loop bounds to reflect that.

Signed-off-by: David Gibson 
Signed-off-by: Alexander Graf 
(cherry picked from commit 135712de61dfa22368e98914d65b8b0860ec8505)
---
 hw/spapr_pci.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/spapr_pci.c b/hw/spapr_pci.c
index 7162588..9b6a032 100644
--- a/hw/spapr_pci.c
+++ b/hw/spapr_pci.c
@@ -454,7 +454,7 @@ int spapr_populate_pci_devices(sPAPRPHBState *phb,
 reg[0].size = 0;
 
 n = 0;
-for (i = 0; i < PCI_NUM_REGIONS; ++i) {
+for (i = 0; i < ARRAY_SIZE(bars); ++i) {
 if (0 == dev->io_regions[i].size) {
 continue;
 }
-- 
1.6.0.2

[Qemu-devel] [PATCH 6/7] pseries: Populate "/chosen/linux, stdout-path" in the FDT

[Alexander Graf]

From: David Gibson 

There is a device tree property "/chosen/linux,stdout-path" which indicates
which device should be used as stdout - ie. "the console".

Currently we don't specify anything, which means both firmware and Linux
choose something arbitrarily. Use the routine we added in the last patch
to pick a default vty and specify it as stdout.

Currently SLOF doesn't use the property, but we are hoping to update it
to do so.

Signed-off-by: Michael Ellerman 
Signed-off-by: David Gibson 
Signed-off-by: Alexander Graf 
(cherry picked from commit 68f3a94c64bbaaf8c7f2daa70de1b5d87a432f86)
---
 hw/spapr.c |2 ++
 hw/spapr_vio.c |   34 ++
 hw/spapr_vio.h |3 +++
 hw/spapr_vty.c |2 +-
 4 files changed, 40 insertions(+), 1 deletions(-)

diff --git a/hw/spapr.c b/hw/spapr.c
index 2b901f1..5a98d86 100644
--- a/hw/spapr.c
+++ b/hw/spapr.c
@@ -351,6 +351,8 @@ static void spapr_finalize_fdt(sPAPREnvironment *spapr,
 fprintf(stderr, "Couldn't set up RTAS device tree properties\n");
 }
 
+spapr_populate_chosen_stdout(fdt, spapr->vio_bus);
+
 _FDT((fdt_pack(fdt)));
 
 cpu_physical_memory_write(fdt_addr, fdt, fdt_totalsize(fdt));
diff --git a/hw/spapr_vio.c b/hw/spapr_vio.c
index 8bd00ca..464fe87 100644
--- a/hw/spapr_vio.c
+++ b/hw/spapr_vio.c
@@ -806,4 +806,38 @@ out:
 
 return ret;
 }
+
+int spapr_populate_chosen_stdout(void *fdt, VIOsPAPRBus *bus)
+{
+VIOsPAPRDevice *dev;
+char *name, *path;
+int ret, offset;
+
+dev = spapr_vty_get_default(bus);
+if (!dev)
+return 0;
+
+offset = fdt_path_offset(fdt, "/chosen");
+if (offset < 0) {
+return offset;
+}
+
+name = vio_format_dev_name(dev);
+if (!name) {
+return -ENOMEM;
+}
+
+if (asprintf(&path, "/vdevice/%s", name) < 0) {
+path = NULL;
+ret = -ENOMEM;
+goto out;
+}
+
+ret = fdt_setprop_string(fdt, offset, "linux,stdout-path", path);
+out:
+free(name);
+free(path);
+
+return ret;
+}
 #endif /* CONFIG_FDT */
diff --git a/hw/spapr_vio.h b/hw/spapr_vio.h
index a325a5f..9fcd304 100644
--- a/hw/spapr_vio.h
+++ b/hw/spapr_vio.h
@@ -83,6 +83,7 @@ extern VIOsPAPRBus *spapr_vio_bus_init(void);
 extern VIOsPAPRDevice *spapr_vio_find_by_reg(VIOsPAPRBus *bus, uint32_t reg);
 extern void spapr_vio_bus_register_withprop(VIOsPAPRDeviceInfo *info);
 extern int spapr_populate_vdevice(VIOsPAPRBus *bus, void *fdt);
+extern int spapr_populate_chosen_stdout(void *fdt, VIOsPAPRBus *bus);
 
 extern int spapr_vio_signal(VIOsPAPRDevice *dev, target_ulong mode);
 
@@ -108,6 +109,8 @@ void spapr_vty_create(VIOsPAPRBus *bus, uint32_t reg, 
CharDriverState *chardev);
 void spapr_vlan_create(VIOsPAPRBus *bus, uint32_t reg, NICInfo *nd);
 void spapr_vscsi_create(VIOsPAPRBus *bus, uint32_t reg);
 
+VIOsPAPRDevice *spapr_vty_get_default(VIOsPAPRBus *bus);
+
 int spapr_tce_set_bypass(uint32_t unit, uint32_t enable);
 void spapr_vio_quiesce(void);
 
diff --git a/hw/spapr_vty.c b/hw/spapr_vty.c
index e2fec58..386ccf7 100644
--- a/hw/spapr_vty.c
+++ b/hw/spapr_vty.c
@@ -156,7 +156,7 @@ static VIOsPAPRDeviceInfo spapr_vty = {
 },
 };
 
-static VIOsPAPRDevice *spapr_vty_get_default(VIOsPAPRBus *bus)
+VIOsPAPRDevice *spapr_vty_get_default(VIOsPAPRBus *bus)
 {
 VIOsPAPRDevice *sdev, *selected;
 DeviceState *iter;
-- 
1.6.0.2

[Qemu-devel] [PATCH] build: fix target_phys_addr_t to 64-bit

[Anthony Liguori]

This simplifies the build quite a bit and improves the builds performance by
not rebuilding many objects twice.

There were a surprising number of places that had assumed wrong things about the
size of target_phys_addr_t including that it was fixed at 32-bit and that it
was identical to target_ulong.

Signed-off-by: Anthony Liguori 
---
 Makefile|2 +-
 Makefile.hw |   25 
 Makefile.objs   |  182 +++
 Makefile.target |4 -
 configure   |   13 +
 cpu-common.h|8 ---
 dma.h   |2 -
 hw/a9mpcore.c   |4 +-
 hw/hw.h |2 +-
 hw/intel-hda.c  |4 -
 hw/omap.h   |6 --
 hw/pxa2xx_dma.c |6 +-
 hw/pxa2xx_lcd.c |6 +-
 hw/rtl8139.c|4 -
 hw/sh_serial.c  |6 +-
 monitor.c   |   21 --
 qemu-log.h  |4 +-
 targphys.h  |   11 ---
 18 files changed, 106 insertions(+), 204 deletions(-)
 delete mode 100644 Makefile.hw

diff --git a/Makefile b/Makefile
index 2bbc547..32a8ec6 100644
--- a/Makefile
+++ b/Makefile
@@ -197,7 +197,7 @@ $(qga-obj-y) qemu-ga.o: $(QGALIB_GEN) $(GENERATED_HEADERS)
 
 qemu-ga$(EXESUF): qemu-ga.o $(qga-obj-y) $(qapi-obj-y) $(tools-obj-y) 
$(qobject-obj-y) $(version-obj-y) $(QGALIB_OBJ)
 
-QEMULIBS=libhw32 libhw64 libuser libdis libdis-user
+QEMULIBS=libuser libdis libdis-user
 
 clean:
 # avoid old build problems by removing potentially incorrect old files
diff --git a/Makefile.hw b/Makefile.hw
deleted file mode 100644
index 63eb7e4..000
--- a/Makefile.hw
+++ /dev/null
@@ -1,25 +0,0 @@
-# Makefile for qemu target independent devices.
-
-include ../config-host.mak
-include ../config-all-devices.mak
-include config.mak
-include $(SRC_PATH)/rules.mak
-
-.PHONY: all
-
-$(call set-vpath, $(SRC_PATH):$(SRC_PATH)/hw)
-
-QEMU_CFLAGS+=-I..
-QEMU_CFLAGS += $(GLIB_CFLAGS)
-
-include $(SRC_PATH)/Makefile.objs
-
-all: $(hw-obj-y)
-# Dummy command so that make thinks it has done something
-   @true
-
-clean:
-   rm -f *.o */*.o *.d */*.d *.a */*.a *~ */*~
-
-# Include automatically generated dependency files
--include $(wildcard *.d */*.d)
diff --git a/Makefile.objs b/Makefile.objs
index 4f6d26c..13a2281 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -179,118 +179,114 @@ user-obj-y += tcg-runtime.o host-utils.o
 user-obj-y += cutils.o cache-utils.o
 user-obj-y += $(trace-obj-y)
 
-##
-# libhw
-
-hw-obj-y =
-hw-obj-y += vl.o loader.o
-hw-obj-$(CONFIG_VIRTIO) += virtio-console.o
-hw-obj-y += usb-libhw.o
-hw-obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o
-hw-obj-y += fw_cfg.o
-hw-obj-$(CONFIG_PCI) += pci.o pci_bridge.o
-hw-obj-$(CONFIG_PCI) += msix.o msi.o
-hw-obj-$(CONFIG_PCI) += pci_host.o pcie_host.o
-hw-obj-$(CONFIG_PCI) += ioh3420.o xio3130_upstream.o xio3130_downstream.o
-hw-obj-y += watchdog.o
-hw-obj-$(CONFIG_ISA_MMIO) += isa_mmio.o
-hw-obj-$(CONFIG_ECC) += ecc.o
-hw-obj-$(CONFIG_NAND) += nand.o
-hw-obj-$(CONFIG_PFLASH_CFI01) += pflash_cfi01.o
-hw-obj-$(CONFIG_PFLASH_CFI02) += pflash_cfi02.o
-
-hw-obj-$(CONFIG_M48T59) += m48t59.o
-hw-obj-$(CONFIG_ESCC) += escc.o
-hw-obj-$(CONFIG_EMPTY_SLOT) += empty_slot.o
-
-hw-obj-$(CONFIG_SERIAL) += serial.o
-hw-obj-$(CONFIG_PARALLEL) += parallel.o
-hw-obj-$(CONFIG_I8254) += i8254.o
-hw-obj-$(CONFIG_PCSPK) += pcspk.o
-hw-obj-$(CONFIG_PCKBD) += pckbd.o
-hw-obj-$(CONFIG_USB_UHCI) += usb-uhci.o
-hw-obj-$(CONFIG_USB_OHCI) += usb-ohci.o
-hw-obj-$(CONFIG_USB_EHCI) += usb-ehci.o
-hw-obj-$(CONFIG_FDC) += fdc.o
-hw-obj-$(CONFIG_ACPI) += acpi.o acpi_piix4.o
-hw-obj-$(CONFIG_APM) += pm_smbus.o apm.o
-hw-obj-$(CONFIG_DMA) += dma.o
-hw-obj-$(CONFIG_HPET) += hpet.o
-hw-obj-$(CONFIG_APPLESMC) += applesmc.o
-hw-obj-$(CONFIG_SMARTCARD) += usb-ccid.o ccid-card-passthru.o
-hw-obj-$(CONFIG_SMARTCARD_NSS) += ccid-card-emulated.o
-hw-obj-$(CONFIG_USB_REDIR) += usb-redir.o
-hw-obj-$(CONFIG_I8259) += i8259.o
+common-obj-y += vl.o loader.o
+common-obj-$(CONFIG_VIRTIO) += virtio-console.o
+common-obj-y += usb-libhw.o
+common-obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o
+common-obj-y += fw_cfg.o
+common-obj-$(CONFIG_PCI) += pci.o pci_bridge.o
+common-obj-$(CONFIG_PCI) += msix.o msi.o
+common-obj-$(CONFIG_PCI) += pci_host.o pcie_host.o
+common-obj-$(CONFIG_PCI) += ioh3420.o xio3130_upstream.o xio3130_downstream.o
+common-obj-y += watchdog.o
+common-obj-$(CONFIG_ISA_MMIO) += isa_mmio.o
+common-obj-$(CONFIG_ECC) += ecc.o
+common-obj-$(CONFIG_NAND) += nand.o
+common-obj-$(CONFIG_PFLASH_CFI01) += pflash_cfi01.o
+common-obj-$(CONFIG_PFLASH_CFI02) += pflash_cfi02.o
+
+common-obj-$(CONFIG_M48T59) += m48t59.o
+common-obj-$(CONFIG_ESCC) += escc.o
+common-obj-$(CONFIG_EMPTY_SLOT) += empty_slot.o
+
+common-obj-$(CONFIG_SERIAL) += serial.o
+common-obj-$(CONFIG_PARALLEL) += parallel.o
+common-obj-$(CONFIG_I8254) += i8254.o
+common-obj-$(CONFIG_PCSPK) += pcspk.o
+common-obj-$(CONFIG_PCKBD) += pckbd.o
+common-obj-$(CONFIG_USB_UHCI) += usb-uhci.o
+common-obj-$(CONFIG_USB_OHCI) += usb-o

Re: [Qemu-devel] [PATCH v9 5/6] arm: SoC model for Calxeda Highbank

[Peter Maydell]

On 11 January 2012 16:31, Mark Langsdorf  wrote:
> +    highbank_binfo.ram_size = ram_size;
> +    highbank_binfo.kernel_filename = kernel_filename;
> +    highbank_binfo.kernel_cmdline = kernel_cmdline;
> +    highbank_binfo.initrd_filename = initrd_filename;
> +    highbank_binfo.board_id = -1; /* provided by deviceTree */
> +    highbank_binfo.nb_cpus = smp_cpus;
> +    highbank_binfo.loader_start = 0;
> +    highbank_binfo.smp_loader_start = SMP_BOOT_ADDR;
> +    arm_load_kernel(env, &highbank_binfo);

So at the moment this will use address 0x1030 as the location
that the bootloader for secondary CPUs polls to find out whether
it can release the secondary CPUs. This is right for realview
and vexpress, because it's the sysreg SYS_FLAGS (implemented in
arm_sysctl.c). Is this really the right location to poll for
Highbank?

(There's a patch in the Samsung Exynos4 patch series which
addresses this by allowing boards to specify a polling location.
So I'm wondering what that location ought to be for Highbank...)

thanks
-- PMM

Re: [Qemu-devel] [PATCH] bt-host: add missing break statement

[Stefan Weil]

Am 12.01.2012 15:17, schrieb Stefan Hajnoczi:

The switch statement in bt_host_read() is missing a break in one case.
Andrzej Zaborowski  confirmed that this is
not an intentional fall-through.

Signed-off-by: Stefan Hajnoczi 
---
bt-host.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/bt-host.c b/bt-host.c
index df5b7cd..0d3ad28 100644
--- a/bt-host.c
+++ b/bt-host.c
@@ -130,6 +130,7 @@ static void bt_host_read(void *opaque)
pktlen = MIN(pkt[2] + 3, s->len);
s->len -= pktlen;
pkt += pktlen;
+ break;

default:
bad_pkt:


Reviewed-by: Stefan Weil 

[Qemu-devel] [PATCH 2/2] s390: fix cpu hotplug / cpu activity on interrupts

[Alexander Graf]

From: Christian Borntraeger 

The add_del/running_cpu code and env->halted are tracking stopped cpus.
Sleeping cpus (idle and enabled for interrupts) are waiting inside the
kernel.
No interrupt besides the restart can move a cpu from stopped to
operational. This is already handled over there. So lets just remove
the bogus wakup from the common interrupt delivery, otherwise any
interrupt will wake up a cpu, even if this cpu is stopped (Thus leading
to strange hangs on sigp restart)

This fixes
echo 0 > /sys/devices/system/cpu/cpu0/online
echo 1 > /sys/devices/system/cpu/cpu0/online
in the guest

Signed-off-by: Christian Borntraeger
Signed-off-by: Alexander Graf 
(cherry picked from commit 93116ac0cf9734e7b28886aedf03848b37d6785e)
---
 target-s390x/kvm.c |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index 40b0ab1..b1404bf 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -185,9 +185,6 @@ void kvm_s390_interrupt_internal(CPUState *env, int type, 
uint32_t parm,
 return;
 }
 
-s390_add_running_cpu(env);
-qemu_cpu_kick(env);
-
 kvmint.type = type;
 kvmint.parm = parm;
 kvmint.parm64 = parm64;
-- 
1.6.0.2

[Qemu-devel] [PULL 1.0 0/2] s390 stable-1.0 patch queue 2012-01-12

[Alexander Graf]

Hi Justin,

This is my current patch queue for s390 for stable-1.0. Please pull.

Alex


The following changes since commit 85a4ca797dbe25f27df0a66aa4df1cab63245cd3:
  Justin M. Forbes (1):
Merge branch 'master' of ssh://git.qemu.org/pub/git/qemu-stable-1.0

are available in the git repository at:

  git://repo.or.cz/qemu/agraf.git s390-1.0

Alexander Graf (1):
  s390x: add TR function for EXECUTE

Christian Borntraeger (1):
  s390: fix cpu hotplug / cpu activity on interrupts

 target-s390x/kvm.c   |3 ---
 target-s390x/op_helper.c |3 +++
 2 files changed, 3 insertions(+), 3 deletions(-)

[Qemu-devel] [PATCH 1/2] s390x: add TR function for EXECUTE

[Alexander Graf]

Newer gcc versions (or glibc?) also generate code that tries to EXECUTE
the TR opcode. Implement it so that we don't break valid guests.

Reported-by: Andreas Faerber 
Signed-off-by: Alexander Graf 
---
 target-s390x/op_helper.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/target-s390x/op_helper.c b/target-s390x/op_helper.c
index 137bae7..5ddc7b9 100644
--- a/target-s390x/op_helper.c
+++ b/target-s390x/op_helper.c
@@ -636,6 +636,9 @@ uint32_t HELPER(ex)(uint32_t cc, uint64_t v1, uint64_t 
addr, uint64_t ret)
 case 0x700:
 cc = helper_xc(l, get_address(0, b1, d1), get_address(0, b2, d2));
 break;
+case 0xc00:
+helper_tr(l, get_address(0, b1, d1), get_address(0, b2, d2));
+break;
 default:
 goto abort;
 break;
-- 
1.6.0.2

[Qemu-devel] [PATCH] check-qstring: remove check.h include

[Anthony Liguori]

Reported-by: Peter Maydell 
Signed-off-by: Anthony Liguori 
---
 check-qstring.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/check-qstring.c b/check-qstring.c
index 681bb68..addad6c 100644
--- a/check-qstring.c
+++ b/check-qstring.c
@@ -9,7 +9,7 @@
  * This work is licensed under the terms of the GNU LGPL, version 2.1 or later.
  * See the COPYING.LIB file in the top-level directory.
  */
-#include 
+#include 
 
 #include "qstring.h"
 #include "qemu-common.h"
-- 
1.7.4.1

[Qemu-devel] [PULL 1.0 0/7] ppc-stable-1.0 patch queue 2012-01-12

[Alexander Graf]

Hi Justin,

This is my current patch queue for ppc in stable-1.0. Please pull.

Alex


The following changes since commit 85a4ca797dbe25f27df0a66aa4df1cab63245cd3:
  Justin M. Forbes (1):
Merge branch 'master' of ssh://git.qemu.org/pub/git/qemu-stable-1.0

are available in the git repository at:

  git://repo.or.cz/qemu/agraf.git ppc-1.0

Alexander Graf (1):
  console: Fix segfault on screendump without VGA adapter

David Gibson (5):
  pseries: Fix array overrun bug in PCI code
  pseries: Emit device tree nodes in reg order
  pseries: Add a routine to find a stable "default" vty and use it
  pseries: Populate "/chosen/linux,stdout-path" in the FDT
  pseries: Don't try to munmap() a malloc()ed TCE table

Liu Yu-B13201 (1):
  kvm-ppc: halt secondary cpus when guest reset

 console.c |4 ++-
 hw/ppce500_spin.c |1 +
 hw/spapr.c|2 +
 hw/spapr_pci.c|2 +-
 hw/spapr_vio.c|   84 +---
 hw/spapr_vio.h|3 ++
 hw/spapr_vty.c|   47 --
 target-ppc/kvm.c  |   14 +++--
 8 files changed, 138 insertions(+), 19 deletions(-)

Re: [Qemu-devel] [PATCH] Add tab-completion for device_add.

[Anthony Liguori]

On 01/08/2012 09:28 AM, Andrzej Zaborowski wrote:

Signed-off-by: Andrzej Zaborowski
---
There are other ways to do this, but adding an API for querying
available qdev drivers was the one that made most sense to me.
---
  hw/qdev.c |   38 ++
  hw/qdev.h |7 +++
  monitor.c |   41 +
  3 files changed, 86 insertions(+), 0 deletions(-)

diff --git a/hw/qdev.c b/hw/qdev.c
index d0cf66d..ba97312 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -1535,3 +1535,41 @@ void qdev_machine_init(void)
  qdev_get_peripheral_anon();
  qdev_get_peripheral();
  }
+
+int qdev_driver_foreach(qdev_driver_foreach_func func, void *opaque)
+{
+DeviceInfo *info;
+int ret = 0;
+
+for (info = device_info_list; info != NULL; info = info->next) {
+ret |= (*func)(info, opaque);
+}
+
+return ret;
+}
+
+int qdev_driver_prop_foreach(qdev_driver_prop_foreach_func func,
+const char *driver, void *opaque)
+{
+DeviceInfo *info;
+Property *prop;
+int ret = 0;
+
+info = qdev_find_info(NULL, driver);
+if (!info) {
+return -1;
+}
+
+for (prop = info->props; prop&&  prop->name; prop++) {
+/*
+ * TODO Properties without a parser are just for dirty hacks.
+ * See comment in qdev_device_help.
+ */
+if (!prop->info->parse) {
+continue;   /* no way to set it, don't show */
+}
+ret |= (*func)(prop, opaque);


Would be better to pass prop->name here as Property is going to go away soon.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 1/2] cleanup, Remove duplicated code

[Anthony Liguori]

On 01/12/2012 03:05 AM, Lai Jiangshan wrote:

These two blocks of code are exactly the same, remove one.

Signed-off-by: Lai Jiangshan


Applied all.  Thanks.

Regards,

Anthony Liguori


---
  cpus.c |8 
  1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/cpus.c b/cpus.c
index 857f96f..f45a438 100644
--- a/cpus.c
+++ b/cpus.c
@@ -565,14 +565,6 @@ static void qemu_kvm_init_cpu_signals(CPUState *env)
  fprintf(stderr, "kvm_set_signal_mask: %s\n", strerror(-r));
  exit(1);
  }
-
-sigdelset(&set, SIG_IPI);
-sigdelset(&set, SIGBUS);
-r = kvm_set_signal_mask(env,&set);
-if (r) {
-fprintf(stderr, "kvm_set_signal_mask: %s\n", strerror(-r));
-exit(1);
-}
  }

  static void qemu_tcg_init_cpu_signals(void)

Re: [Qemu-devel] [PATCH] vga: optimize ppm_save() divisions

[Anthony Liguori]

On 01/03/2012 07:32 AM, Avi Kivity wrote:

ppm_save() spends upwards of 50% of its time doing divisions. Replace them
with shifts.

Signed-off-by: Avi Kivity


Applied.  Thanks.

Regards,

Anthony Liguori


---
  hw/vga.c |   10 --
  1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/hw/vga.c b/hw/vga.c
index ca79aa1..a228cde 100644
--- a/hw/vga.c
+++ b/hw/vga.c
@@ -2370,12 +2370,10 @@ int ppm_save(const char *filename, struct 
DisplaySurface *ds)
  v = *(uint32_t *)d;
  else
  v = (uint32_t) (*(uint16_t *)d);
-r = ((v>>  ds->pf.rshift)&  ds->pf.rmax) * 256 /
-(ds->pf.rmax + 1);
-g = ((v>>  ds->pf.gshift)&  ds->pf.gmax) * 256 /
-(ds->pf.gmax + 1);
-b = ((v>>  ds->pf.bshift)&  ds->pf.bmax) * 256 /
-(ds->pf.bmax + 1);
+/* Limited to 8 or fewer bits per channel: */
+r = ((v>>  ds->pf.rshift)&  ds->pf.rmax)<<  (8 - ds->pf.rbits);
+g = ((v>>  ds->pf.gshift)&  ds->pf.gmax)<<  (8 - ds->pf.gbits);
+b = ((v>>  ds->pf.bshift)&  ds->pf.bmax)<<  (8 - ds->pf.bbits);
  *pbuf++ = r;
  *pbuf++ = g;
  *pbuf++ = b;

Re: [Qemu-devel] [PATCH] Fix qapi code generation fix

[Anthony Liguori]

On 12/28/2011 04:26 AM, Avi Kivity wrote:

The fixes to qapi code generation had multiple bugs:
- the Null class used to drop output was missing some methods
- in some scripts it was never instantiated, leading to a None return,
   which is missing even more methods
- the --source and --header options were swapped

Luckily, all those bugs were hidden by a makefile bug which caused the
old behaviour (with the race) to be invoked.

Signed-off-by: Avi Kivity


Applied.  Thanks.

Regards,

Anthony Liguori


---
  Makefile |2 +-
  scripts/qapi-commands.py |   12 
  scripts/qapi-types.py|   12 +---
  scripts/qapi-visit.py|   12 +---
  4 files changed, 15 insertions(+), 23 deletions(-)

diff --git a/Makefile b/Makefile
index 0838bc4..8118478 100644
--- a/Makefile
+++ b/Makefile
@@ -173,7 +173,7 @@ qapi-dir := $(BUILD_DIR)/qapi-generated
  test-qmp-input-visitor.o test-qmp-output-visitor.o test-qmp-commands.o 
qemu-ga$(EXESUF): QEMU_CFLAGS += -I $(qapi-dir)
  qemu-ga$(EXESUF): LIBS = $(LIBS_QGA)

-gen-out-type = $(subst .,-,$@)
+gen-out-type = $(subst .,-,$(suffix $@))

  $(qapi-dir)/test-qapi-types.c $(qapi-dir)/test-qapi-types.h :\
  $(SRC_PATH)/qapi-schema-test.json $(SRC_PATH)/scripts/qapi-types.py
diff --git a/scripts/qapi-commands.py b/scripts/qapi-commands.py
index bd7b207..3aabf61 100644
--- a/scripts/qapi-commands.py
+++ b/scripts/qapi-commands.py
@@ -399,9 +399,9 @@ for o, a in opts:
  elif o in ("-m", "--middle"):
  middle_mode = True
  elif o in ("-c", "--source"):
-do_h = True
-elif o in ("-h", "--header"):
  do_c = True
+elif o in ("-h", "--header"):
+do_h = True

  if not do_c and not do_h:
  do_c = True
@@ -411,15 +411,11 @@ c_file = output_dir + prefix + c_file
  h_file = output_dir + prefix + h_file

  def maybe_open(really, name, opt):
-class Null(object):
-def write(self, str):
-pass
-def read(self):
-return ''
  if really:
  return open(name, opt)
  else:
-return Null()
+import StringIO
+return StringIO.StringIO()

  try:
  os.makedirs(output_dir)
diff --git a/scripts/qapi-types.py b/scripts/qapi-types.py
index ae644bc..b56225b 100644
--- a/scripts/qapi-types.py
+++ b/scripts/qapi-types.py
@@ -183,9 +183,9 @@ for o, a in opts:
  elif o in ("-o", "--output-dir"):
  output_dir = a + "/"
  elif o in ("-c", "--source"):
-do_h = True
-elif o in ("-h", "--header"):
  do_c = True
+elif o in ("-h", "--header"):
+do_h = True

  if not do_c and not do_h:
  do_c = True
@@ -201,13 +201,11 @@ except os.error, e:
  raise

  def maybe_open(really, name, opt):
-class Null(object):
-def write(self, str):
-pass
-def read(self):
-return ''
  if really:
  return open(name, opt)
+else:
+import StringIO
+return StringIO.StringIO()

  fdef = maybe_open(do_c, c_file, 'w')
  fdecl = maybe_open(do_h, h_file, 'w')
diff --git a/scripts/qapi-visit.py b/scripts/qapi-visit.py
index e9d0584..5160d83 100644
--- a/scripts/qapi-visit.py
+++ b/scripts/qapi-visit.py
@@ -159,9 +159,9 @@ for o, a in opts:
  elif o in ("-o", "--output-dir"):
  output_dir = a + "/"
  elif o in ("-c", "--source"):
-do_h = True
-elif o in ("-h", "--header"):
  do_c = True
+elif o in ("-h", "--header"):
+do_h = True

  if not do_c and not do_h:
  do_c = True
@@ -177,13 +177,11 @@ except os.error, e:
  raise

  def maybe_open(really, name, opt):
-class Null(object):
-def write(self, str):
-pass
-def read(self):
-return ''
  if really:
  return open(name, opt)
+else:
+import StringIO
+return StringIO.StringIO()

  fdef = maybe_open(do_c, c_file, 'w')
  fdecl = maybe_open(do_h, h_file, 'w')

Re: [Qemu-devel] [PATCH v4] Support for UDP unicast network backend

[Anthony Liguori]

On 01/10/2012 06:20 PM, Benjamin wrote:

Signed-off-by: Benjamin MARSILI


Applied.  Thanks.

Regards,

Anthony Liguori


---
Added my last name. Check that localaddr= is supplied with udp=,
it crashed when misused...

  net.c   |6 +++-
  net/socket.c|   77 +-
  qemu-options.hx |2 +
  3 files changed, 82 insertions(+), 3 deletions(-)

diff --git a/net.c b/net.c
index f7bebf8..2b0f766 100644
--- a/net.c
+++ b/net.c
@@ -1000,7 +1000,11 @@ static const struct {
  }, {
  .name = "localaddr",
  .type = QEMU_OPT_STRING,
-.help = "source address for multicast packets",
+.help = "source address and port for multicast and udp 
packets",
+}, {
+.name = "udp",
+.type = QEMU_OPT_STRING,
+.help = "UDP unicast address and port number",
  },
  { /* end of list */ }
  },
diff --git a/net/socket.c b/net/socket.c
index c9d70d3..d4c2002 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -534,6 +534,57 @@ static int net_socket_mcast_init(VLANState *vlan,

  }

+static int net_socket_udp_init(VLANState *vlan,
+ const char *model,
+ const char *name,
+ const char *rhost,
+ const char *lhost)
+{
+NetSocketState *s;
+int fd, val, ret;
+struct sockaddr_in laddr, raddr;
+
+if (parse_host_port(&laddr, lhost)<  0) {
+return -1;
+}
+
+if (parse_host_port(&raddr, rhost)<  0) {
+return -1;
+}
+
+fd = qemu_socket(PF_INET, SOCK_DGRAM, 0);
+if (fd<  0) {
+perror("socket(PF_INET, SOCK_DGRAM)");
+return -1;
+}
+val = 1;
+ret = setsockopt(fd, SOL_SOCKET, SO_REUSEADDR,
+   (const char *)&val, sizeof(val));
+if (ret<  0) {
+perror("setsockopt(SOL_SOCKET, SO_REUSEADDR)");
+closesocket(fd);
+return -1;
+}
+ret = bind(fd, (struct sockaddr *)&laddr, sizeof(laddr));
+if (ret<  0) {
+perror("bind");
+closesocket(fd);
+return -1;
+}
+
+s = net_socket_fd_init(vlan, model, name, fd, 0);
+if (!s) {
+return -1;
+}
+
+s->dgram_dst = raddr;
+
+snprintf(s->nc.info_str, sizeof(s->nc.info_str),
+ "socket: udp=%s:%d",
+ inet_ntoa(raddr.sin_addr), ntohs(raddr.sin_port));
+return 0;
+}
+
  int net_init_socket(QemuOpts *opts,
  Monitor *mon,
  const char *name,
@@ -606,10 +657,32 @@ int net_init_socket(QemuOpts *opts,
  if (net_socket_mcast_init(vlan, "socket", name, mcast, localaddr) == 
-1) {
  return -1;
  }
+} else if (qemu_opt_get(opts, "udp")) {
+const char *udp, *localaddr;
+
+if (qemu_opt_get(opts, "fd") ||
+qemu_opt_get(opts, "connect") ||
+qemu_opt_get(opts, "listen") ||
+qemu_opt_get(opts, "mcast")) {
+error_report("fd=, connect=, listen=\
+ and mcast= is invalid with udp=");
+return -1;
+}
+
+udp = qemu_opt_get(opts, "udp");
+localaddr = qemu_opt_get(opts, "localaddr");
+if (localaddr == NULL) {
+error_report("localaddr= is mandatory with udp=");
+return -1;
+}
+
+if (net_socket_udp_init(vlan, "udp", name, udp, localaddr) == -1) {
+return -1;
+}
  } else {
-error_report("-socket requires fd=, listen=, connect= or mcast=");
+error_report("-socket requires fd=, listen=, \
+ connect=, mcast= or udp=");
  return -1;
  }
-
  return 0;
  }
diff --git a/qemu-options.hx b/qemu-options.hx
index 7903e5c..6295cde 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1239,6 +1239,8 @@ DEF("net", HAS_ARG, QEMU_OPTION_net,
  "-net 
socket[,vlan=n][,name=str][,fd=h][,mcast=maddr:port[,localaddr=addr]]\n"
  "connect the vlan 'n' to multicast maddr and port\n"
  "use 'localaddr=addr' to specify the host address to send 
packets from\n"
+"-net 
socket[,vlan=n][,name=str][,fd=h][,udp=host:port][,localaddr=host:port]\n"
+"connect the vlan 'n' to another VLAN using an UDP 
tunnel\n"
  #ifdef CONFIG_VDE
  "-net 
vde[,vlan=n][,name=str][,sock=socketpath][,port=n][,group=groupname][,mode=octalmode]\n"
  "connect the vlan 'n' to port 'n' of a vde switch 
running\n"
--
1.7.6

Re: [Qemu-devel] [PATCH] MAINTAINERS: update tracing repo git URL

[Anthony Liguori]

On 01/11/2012 04:02 AM, Stefan Hajnoczi wrote:

I have moved git hosting services.

Signed-off-by: Stefan Hajnoczi
---
  MAINTAINERS |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)


Applied.  Thanks.

Regards,

Anthony Liguori



diff --git a/MAINTAINERS b/MAINTAINERS
index 764c92d..de2a916 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -490,7 +490,7 @@ Tracing
  M: Stefan Hajnoczi
  S: Maintained
  F: trace/
-T: git://repo.or.cz/qemu/stefanha.git tracing
+T: git://github.com/stefanha/qemu.git tracing

  Checkpatch
  M: Blue Swirl

Re: [Qemu-devel] [PATCH] usb-redir: Add the posibility to filter out certain devices from redirecion

[Jan Kiszka]

On 2012-01-12 17:31, Hans de Goede wrote:
> This patch adds the posibility to filter out certain devices from redirecion.
> To use this pass the filter property to -device usb-redir.  The filter
> property takes a string consisting of filter rules, the format for a rule is:
> 
> 
> -1 can be used to allow any value for a field.
> 
> Muliple rules can be concatonated using | as a separator. Note that if
> a device matches none of the passed in rules, redirecting it will not be
> allowed!
> 

Hmm, '|' makes quoting mandatory. And the : is also not that
beautiful IMHO.

What about

[+]|-:::[/[+]|-:...]

? Optional '+' means allow, '-' disallow. An empty field could also
serve as wildcard (instead of explicit -1 which would collide with
disallow).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

[Qemu-devel] [PATCH] usb-redir: Add the posibility to filter out certain devices from redirecion

[Hans de Goede]

This patch adds the posibility to filter out certain devices from redirecion.
To use this pass the filter property to -device usb-redir.  The filter
property takes a string consisting of filter rules, the format for a rule is:


-1 can be used to allow any value for a field.

Muliple rules can be concatonated using | as a separator. Note that if
a device matches none of the passed in rules, redirecting it will not be
allowed!

Example:
-device usb-redir,filter='-1:0x0781:0x5567:-1:0|0x08:-1:-1:-1:1'

This example will deny the Sandisk Cruzer Blade being redirected, as it
has a usb id of 0781:5567, it will allow any other usb mass storage devices,
and it will deny any other devices (the default for devices not matching any
of the rules.

Signed-off-by: Hans de Goede 
---
 configure   |2 +-
 usb-redir.c |  114 +-
 2 files changed, 105 insertions(+), 11 deletions(-)

diff --git a/configure b/configure
index 7ecf44e..c7e37df 100755
--- a/configure
+++ b/configure
@@ -2541,7 +2541,7 @@ fi
 
 # check for usbredirparser for usb network redirection support
 if test "$usb_redir" != "no" ; then
-if $pkg_config libusbredirparser >/dev/null 2>&1 ; then
+if $pkg_config --atleast-version=0.3.3 libusbredirparser >/dev/null 2>&1 ; 
then
 usb_redir="yes"
 usb_redir_cflags=$($pkg_config --cflags libusbredirparser 2>/dev/null)
 usb_redir_libs=$($pkg_config --libs libusbredirparser 2>/dev/null)
diff --git a/usb-redir.c b/usb-redir.c
index 6e92f14..41c0745 100644
--- a/usb-redir.c
+++ b/usb-redir.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "hw/usb.h"
 
@@ -72,6 +73,7 @@ struct USBRedirDevice {
 /* Properties */
 CharDriverState *cs;
 uint8_t debug;
+char *filter_str;
 /* Data passed from chardev the fd_read cb to the usbredirparser read cb */
 const uint8_t *read_buf;
 int read_buf_size;
@@ -84,6 +86,11 @@ struct USBRedirDevice {
 struct endp_data endpoint[MAX_ENDPOINTS];
 uint32_t packet_id;
 QTAILQ_HEAD(, AsyncURB) asyncq;
+/* Data for device filtering */
+struct usb_redir_device_connect_header device_info;
+struct usb_redir_interface_info_header interface_info;
+struct usbredirfilter_rule *filter_rules;
+int filter_rules_count;
 };
 
 struct AsyncURB {
@@ -790,6 +797,7 @@ static int usbredir_handle_control(USBDevice *udev, 
USBPacket *p,
 static void usbredir_open_close_bh(void *opaque)
 {
 USBRedirDevice *dev = opaque;
+uint32_t caps[USB_REDIR_CAPS_SIZE] = { 0, };
 
 usbredir_device_disconnect(dev);
 
@@ -820,7 +828,9 @@ static void usbredir_open_close_bh(void *opaque)
 dev->parser->interrupt_packet_func = usbredir_interrupt_packet;
 dev->read_buf = NULL;
 dev->read_buf_size = 0;
-usbredirparser_init(dev->parser, VERSION, NULL, 0, 0);
+
+usbredirparser_caps_set_cap(caps, 
usb_redir_cap_connect_device_version);
+usbredirparser_init(dev->parser, VERSION, caps, USB_REDIR_CAPS_SIZE, 
0);
 usbredirparser_do_write(dev->parser);
 }
 }
@@ -908,6 +918,16 @@ static int usbredir_initfn(USBDevice *udev)
 return -1;
 }
 
+if (dev->filter_str) {
+i = usbredirfilter_string_to_rules(dev->filter_str, ":", "|",
+   &dev->filter_rules,
+   &dev->filter_rules_count);
+if (i) {
+qerror_report(QERR_INVALID_PARAMETER_VALUE, "filter", "a usb 
device filter string");
+return -1;
+}
+}
+
 dev->open_close_bh = qemu_bh_new(usbredir_open_close_bh, dev);
 dev->attach_timer = qemu_new_timer_ms(vm_clock, usbredir_do_attach, dev);
 
@@ -956,6 +976,44 @@ static void usbredir_handle_destroy(USBDevice *udev)
 if (dev->parser) {
 usbredirparser_destroy(dev->parser);
 }
+
+free(dev->filter_rules);
+}
+
+static int usbredir_check_filter(USBRedirDevice *dev)
+{
+if (dev->interface_info.interface_count == 0) {
+ERROR("No interface info for device\n");
+return -1;
+}
+
+if (dev->filter_rules) {
+if (!usbredirparser_peer_has_cap(dev->parser,
+usb_redir_cap_connect_device_version)) {
+ERROR("Device filter specified and peer does not have the "
+  "connect_device_version capability\n");
+return -1;
+}
+
+if (usbredirfilter_check(
+dev->filter_rules,
+dev->filter_rules_count,
+dev->device_info.device_class,
+dev->device_info.device_subclass,
+dev->device_info.device_protocol,
+dev->interface_info.interface_class,
+dev->interface_info.interface_subclass,
+dev->interface_info.interface_protocol,
+dev->interface_info.interface_count,
+dev->device_info.vendor_id

Re: [Qemu-devel] [PATCH v4 13/15] block stream: add support for partial streaming

[Stefan Hajnoczi]

On Thu, Jan 12, 2012 at 12:42 PM, Kevin Wolf  wrote:
> Am 06.01.2012 15:01, schrieb Stefan Hajnoczi:
>> From: Marcelo Tosatti 
>>
>> Add support for streaming data from an intermediate section of the
>> image chain (see patch and documentation for details).
>>
>> Signed-off-by: Marcelo Tosatti 
>> Signed-off-by: Stefan Hajnoczi 
>> ---
>>  block.c        |   64 
>> 
>>  block.h        |    4 +++
>>  block/stream.c |   28 +---
>>  block_int.h    |    3 +-
>>  blockdev.c     |   11 ++---
>>  5 files changed, 101 insertions(+), 9 deletions(-)
>>
>> diff --git a/block.c b/block.c
>> index 9b688a0..d2143b1 100644
>> --- a/block.c
>> +++ b/block.c
>> @@ -2263,6 +2263,70 @@ int bdrv_is_allocated(BlockDriverState *bs, int64_t 
>> sector_num, int nb_sectors,
>>      return data.ret;
>>  }
>>
>> +/*
>> + * Given an image chain: [BASE] -> [INTER1] -> [INTER2] -> [TOP]
>> + *
>> + * Return true if the given sector is allocated in top or base.
>> + * Return false if the given sector is allocated in intermediate images.
>
> This description is inexact. A sector could be allocated both in base in
> an intermediate image.
>
> Also initially I thought that we not only need to check whether the
> sector is allocated in BASE, but also in any parents of BASE. You don't
> do this: Clusters that are completely unallocated all through the chain
> are reported as allocated.
>
> After reading all of the patch, I believe this provides the right
> semantics: "Normal" image streaming would copy them into the topmost
> file, but if you keep a backing file, you want to copy as little as
> possible and keep using the backing file whenever possible.
>
> So I suggest to fix the description rather than the implementation.
>
> Maybe we should also rename the function. With this semantics it's not a
> generic is_allocated function any more, but something quite specific to
> streaming with a base file.

I have moved the function into block/stream.c and renamed it to just
is_allocated_base().  The description is updated.

This makes it clearer that it's a special-case is_allocated-like function.

Stefan

Re: [Qemu-devel] State of KVM bits in linux-headers

[Avi Kivity]

On 01/11/2012 11:48 PM, Alexander Graf wrote:
> > 
> > Strictly from a QEMU perspective, we can't depend on APIs that aren't 
> > committed upstream yet.

We can't release any qemu that depends on something not upstream.

> The question again is: When do we consider something upstream?

This far from a qemu release, we can consider anything in in kvm.git
master (or slightly trailing that, kvm.git linux-next) as upstream. 
It's very rare that an ABI gets pulled out of that and not merged, and
if it is, we can pull out the qemu feature.  An ABI can change, but that
just means we need to echo the change in qemu.

As qemu gets closer to release, we'll need to look at Linus' tree
instead of kvm.git.


> >> 
> >> right? And then after about 3 months we'll have the feature available ;).
> > 
> > You can always just get Acked-by's from the appropriate maintainers.  
> > That's just as good as going through the tree.
>
> So every time we change headers, I just require Avi's ack and then he can't 
> complain on those patches later? Good idea! :)

Of course I can complain about my patches later.

Complained-about-by: Avi Kivity 

But yes, if your change involves multiple subsystem, get it through the
most affected subsystem and get acks from the rest.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH] vga: optimize ppm_save() divisions

[Alon Levy]

On Thu, Jan 12, 2012 at 05:16:03PM +0200, Alon Levy wrote:
> On Tue, Jan 03, 2012 at 03:32:57PM +0200, Avi Kivity wrote:
> > ppm_save() spends upwards of 50% of its time doing divisions. Replace them
> > with shifts.
> > 
> 
> Reviewed-by: Alon Levy 
> 
> rmax/bmax/gmax are all uint8_t atm, could add a compilation error if
> sizeof(bmax)!=1 ever.

meant {r,g,b}bits.

> 
> > Signed-off-by: Avi Kivity 
> > ---
> >  hw/vga.c |   10 --
> >  1 files changed, 4 insertions(+), 6 deletions(-)
> > 
> > diff --git a/hw/vga.c b/hw/vga.c
> > index ca79aa1..a228cde 100644
> > --- a/hw/vga.c
> > +++ b/hw/vga.c
> > @@ -2370,12 +2370,10 @@ int ppm_save(const char *filename, struct 
> > DisplaySurface *ds)
> >  v = *(uint32_t *)d;
> >  else
> >  v = (uint32_t) (*(uint16_t *)d);
> > -r = ((v >> ds->pf.rshift) & ds->pf.rmax) * 256 /
> > -(ds->pf.rmax + 1);
> > -g = ((v >> ds->pf.gshift) & ds->pf.gmax) * 256 /
> > -(ds->pf.gmax + 1);
> > -b = ((v >> ds->pf.bshift) & ds->pf.bmax) * 256 /
> > -(ds->pf.bmax + 1);
> > +/* Limited to 8 or fewer bits per channel: */
> > +r = ((v >> ds->pf.rshift) & ds->pf.rmax) << (8 - ds->pf.rbits);
> > +g = ((v >> ds->pf.gshift) & ds->pf.gmax) << (8 - ds->pf.gbits);
> > +b = ((v >> ds->pf.bshift) & ds->pf.bmax) << (8 - ds->pf.bbits);
> >  *pbuf++ = r;
> >  *pbuf++ = g;
> >  *pbuf++ = b;
> > -- 
> > 1.7.7.1
> > 
> > 
> 

[Qemu-devel] [PATCH 1/2] cleanup, Remove duplicated code

[Lai Jiangshan]

These two blocks of code are exactly the same, remove one.

Signed-off-by: Lai Jiangshan 
---
 cpus.c |8 
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/cpus.c b/cpus.c
index 857f96f..f45a438 100644
--- a/cpus.c
+++ b/cpus.c
@@ -565,14 +565,6 @@ static void qemu_kvm_init_cpu_signals(CPUState *env)
 fprintf(stderr, "kvm_set_signal_mask: %s\n", strerror(-r));
 exit(1);
 }
-
-sigdelset(&set, SIG_IPI);
-sigdelset(&set, SIGBUS);
-r = kvm_set_signal_mask(env, &set);
-if (r) {
-fprintf(stderr, "kvm_set_signal_mask: %s\n", strerror(-r));
-exit(1);
-}
 }
 
 static void qemu_tcg_init_cpu_signals(void)
-- 
1.7.4.4

Re: [Qemu-devel] [PATCH] vga: optimize ppm_save() divisions

[Alon Levy]

On Tue, Jan 03, 2012 at 03:32:57PM +0200, Avi Kivity wrote:
> ppm_save() spends upwards of 50% of its time doing divisions. Replace them
> with shifts.
> 

Reviewed-by: Alon Levy 

rmax/bmax/gmax are all uint8_t atm, could add a compilation error if
sizeof(bmax)!=1 ever.

> Signed-off-by: Avi Kivity 
> ---
>  hw/vga.c |   10 --
>  1 files changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/hw/vga.c b/hw/vga.c
> index ca79aa1..a228cde 100644
> --- a/hw/vga.c
> +++ b/hw/vga.c
> @@ -2370,12 +2370,10 @@ int ppm_save(const char *filename, struct 
> DisplaySurface *ds)
>  v = *(uint32_t *)d;
>  else
>  v = (uint32_t) (*(uint16_t *)d);
> -r = ((v >> ds->pf.rshift) & ds->pf.rmax) * 256 /
> -(ds->pf.rmax + 1);
> -g = ((v >> ds->pf.gshift) & ds->pf.gmax) * 256 /
> -(ds->pf.gmax + 1);
> -b = ((v >> ds->pf.bshift) & ds->pf.bmax) * 256 /
> -(ds->pf.bmax + 1);
> +/* Limited to 8 or fewer bits per channel: */
> +r = ((v >> ds->pf.rshift) & ds->pf.rmax) << (8 - ds->pf.rbits);
> +g = ((v >> ds->pf.gshift) & ds->pf.gmax) << (8 - ds->pf.gbits);
> +b = ((v >> ds->pf.bshift) & ds->pf.bmax) << (8 - ds->pf.bbits);
>  *pbuf++ = r;
>  *pbuf++ = g;
>  *pbuf++ = b;
> -- 
> 1.7.7.1
> 
> 

Re: [Qemu-devel] [PATCH 00/11] virtio-scsi device model

[Hu Tao]

Hi Paolo,

How to add a virtio-scsi device? What parameters should I specify
in qemu command line?

-- 
Thanks,
Hu Tao

Re: [Qemu-devel] [PATCH] network: Added option to disable NIC option roms

[Gerhard Wiesinger]

On Mon, 9 Jan 2012, Gerd Hoffmann wrote:


 Hi,


 if (!pci_dev->qdev.hotplugged) {
 static int loaded = 0;
-if (!loaded) {
+if (!loaded &&
pci_has_not_explicitly_disabled_option_romfile(pci_dev)) {
 rom_add_option("pxe-ne2k_pci.rom", -1);
 loaded = 1;
 }


I think you can just remove this altogether and add a .romfile = "..."
entry instead like it is done for the other nics.


I'm not sure about the consequences (hotplugging feature, etc.) when 
changing it to romfile as in other PCI devices. Also the patch is more 
generic and supports static and dynamic devices (hotplugable and possible 
future devices). Patch supports without hotplugging both options to 
disable the romfile:

,romfile=
,romfile=disabled

And the patch has already been tested ...

Therefore I suggest to commit it and maybe make a refactoring without 
hotplugging later on.


Ciao,
Gerhard

--
http://www.wiesinger.com/

[Qemu-devel] The reversion of hot adding a storage disk to Linux guest.

[Shu Ming]

Hi,
  I am testing the hot plug of scsi disk to the KVM Linux guest with 
the following command.


  [root@kvm-rhel-01 bin]# ./virsh qemu-monitor-command RHEL6.1-C 
"pci_add auto storage file=/nfs/images/storage1-qcow2.img,if=scsi"

OK domian 0, bus 0, slot 7, function 0
  [root@kvm-rhel-01 bin]# lspci
...
00:05.0 SCSI storage controller: Red Hat, Inc Virtio block device
00:06.0 RAM memory: Red Hat, Inc Virtio memory balloon
00:07.0 SCSI storage controller: LSI Logic / Symbios Logic 53c895a 
<---new deviced added


 in the KVM guest:
  [root@RHEL6 ~]#cat /proc/scsi/scsi
Attached devices:
Host: scsi1 Channel: 00 Id:  00 Lun: 00
  Vendor:  QEMUModel: QEMU DVD-ROMRev:  1.0.
   Type:CD-ROM
Host: scsi2  Channel: 00  Id:  00 Lun: 00
   Vendor:  QEMUModel: QEMU HARDDISKRev:  1.0.
Type:  Direct-AccessANSISCSI revision:  05 
<--new scsi disk attached


  The command successfully created a HBA device in the guest and also a 
scsi disk was enumerated under the HBA device.  My next request is to 
hot detach the scsi disk from the HBA device, not necessarily detach the 
HBA device.  That is to emulate the swapping  out of the scsi disk from 
a physical machine and to release the image file in the backend.  
Because the scsi disk is not PCI device,  "pci_del" command can not be 
used in this case.  Can we have a way to send some commands to notice 
the HBA device to offline the scsi disk?  By that way, HBA device can do 
some cleanup in their driver to fully offline the scsi disk.


BTW: In the linux guest, we can do "echo "scsi remove-single-device 2 0 
0 0" > /proc/scsi/scsi" to disable the disk.  But I don't think it is 
fully removed, because you can bring it back again by "echo "scsi 
add-single-device 2 0 0 0" > /proc/scsi/scsi"


--
Shu Ming
IBM China Systems and Technology Laboratory

Re: [Qemu-devel] [PATCH 21/21] postcopy: implement postcopy livemigration

[Avi Kivity]

On 01/04/2012 05:29 AM, Isaku Yamahata wrote:
> On Thu, Dec 29, 2011 at 06:06:10PM +0200, Avi Kivity wrote:
> > On 12/29/2011 03:26 AM, Isaku Yamahata wrote:
> > > This patch implements postcopy livemigration.
> > >
> > >  
> > > +/* RAM is allocated via umem for postcopy incoming mode */
> > > +#define RAM_POSTCOPY_UMEM_MASK  (1 << 1)
> > > +
> > >  typedef struct RAMBlock {
> > >  uint8_t *host;
> > >  ram_addr_t offset;
> > > @@ -485,6 +488,10 @@ typedef struct RAMBlock {
> > >  #if defined(__linux__) && !defined(TARGET_S390X)
> > >  int fd;
> > >  #endif
> > > +
> > > +#ifdef CONFIG_POSTCOPY
> > > +UMem *umem;/* for incoming postcopy mode */
> > > +#endif
> > >  } RAMBlock;
> > 
> > Is it possible to implement this via the MemoryListener API (which
> > replaces CPUPhysMemoryClient)?  This is how kvm, vhost, and xen manage
> > their memory tables.
>
> I'm afraid no. Those three you listed above are for outgoing part,
> but this case is for incoming part. The requirement is quite different
> from those three. What is needed is
> - get the corresponding RAMBlock and UMem from (id, idlen)
> - hook ram_alloc/ram_free (or RAM api corresponding)
>

Okay.  We'll need more hooks then.  Xen already hooks qemu_ram_alloc(),
so there's more than one user.

But don't spend time on this; this area is in flux due to the memory
API, so any effort will be wasted.  I'll look at adding those hooks,
either before or after postcopy is merged.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH][v8] megasas: LSI Megaraid SAS HBA emulation

[Paolo Bonzini]

On 01/12/2012 11:43 AM, Hannes Reinecke wrote:

+# hw/megasas.c
+disable megasas_init_firmware(int xfer_len, uint64_t pa) "xfer len %d pa %" PRIx64 
" "
+disable megasas_init_queue(uint64_t queue_pa, int queue_len, uint64_t head, uint64_t tail, uint32_t flags) "queue 
at %" PRIx64 " len %d head %" PRIx64 " tail %" PRIx64 " flags %x"
+megasas_initq_map_failed(int frame) "scmd %d: failed to map queue"
+megasas_initq_mismatch(int queue_len, int fw_cmds) "queue size %d max fw cmds 
%d"
+disable megasas_qf_found(unsigned int index, uint64_t pa) "found mapped frame %x pa %" 
PRIx64 ""
+disable megasas_qf_new(unsigned int index, void *cmd) "return new frame %x cmd 
%p"
+megasas_qf_failed(unsigned long pa) "all frames busy for frame %lx"
+disable megasas_qf_enqueue(unsigned int index, unsigned int count, uint64_t context, unsigned int 
tail, int busy) "enqueue frame %x count %d countext %" PRIx64 " tail %x busy %d"
+disable megasas_qf_update(unsigned int head, unsigned int busy) "update reply queue 
head %x busy %d"
+disable megasas_qf_dequeue(unsigned int index) "dequeue frame %x"
+disable megasas_qf_map_failed(int cmd, unsigned long frame) "scmd %d: frame 
%lu"
+disable megasas_qf_complete_noirq(uint64_t context) "context %" PRIx64 " "
+disable megasas_qf_complete(uint64_t context, unsigned int tail, unsigned int offset, int busy, 
unsigned int doorbell) "context %" PRIx64 " tail %x offset %d busy %d doorbell 
%x"
+disable megasas_handle_frame(const char *cmd, uint64_t addr, uint64_t context, uint32_t count) "MFI cmd 
%s addr %" PRIx64 " context %" PRIx64 " count %d"
+megasas_frame_busy(uint64_t addr) "frame %" PRIx64 " busy"
+megasas_unhandled_frame_cmd(int cmd, uint8_t frame_cmd) "scmd %d: Unhandled MFI cmd 
%x"
+disable megasas_handle_scsi(const char *frame, const char *desc, int dev, int lun, void 
*sdev, unsigned long size) "%s %s dev %x/%x sdev %p xfer %lu"
+disable megasas_scsi_target_not_present(const char *frame, const char *desc, int dev, 
int lun) "%s %s dev %x/%x target not present"
+megasas_scsi_invalid_cdb_len(const char *frame, const char *desc, int dev, int lun, int 
len) "%s %s dev %x/%x invalid cdb len %d"
+megasas_scsi_overflow(int cmd, const char *dir, int bytes, int len) "scmd %d: %s %d 
of %d bytes"
+disable megasas_scsi_underflow(int cmd, const char *dir, int bytes, int len) "scmd 
%d: %s %d of %d bytes"
+megasas_scsi_req_alloc_failed(const char *frame, int dev, int lun) "%s dev %x/%x 
req allocation failed"
+disable megasas_scsi_start(int cmd, const char *desc, int len) "scmd %d: %s %d 
bytes of data"
+disable megasas_scsi_nodata(int cmd) "scmd %d: no data to be transferred"
+disable megasas_scsi_complete(int cmd, uint32_t status, int len, int xfer) "scmd 
%d: finished with status %x, len %u/%u"
+disable megasas_command_complete(int cmd, uint32_t status) "scmd %d: command 
completed, status %x"
+disable megasas_handle_io(int cmd, const char *frame, int dev, int lun, unsigned long 
lba, unsigned long count) "scmd %d: %s dev %x/%x lba %lx count %lu"
+disable megasas_io_target_not_present(int cmd, const char *frame, int dev, int lun) 
"scmd %d: %s dev %x/%x LUN not present"
+disable megasas_io_start(int cmd, const char *dir, unsigned long lba, unsigned long 
count, unsigned long len) "scmd %d: %s start LBA %lx %lu blocks (%lu bytes)"
+disable megasas_io_complete(int cmd, uint32_t len) "scmd %d: %d bytes 
completed"
+disable megasas_io_copy(int cmd, const char *dir, int bytes, int len, unsigned long 
offset) "scmd %d: %s %d of %d bytes, iov offset %lu"
+disable megasas_io_continue(int cmd, int bytes) "scmd %d: %d bytes left"
+megasas_iovec_map_failed(int cmd, int index, unsigned long iov_size) "scmd %d: 
iovec %d size %lu"
+megasas_iovec_sgl_overflow(int cmd, int index, int limit) "scmd %d: iovec count %d 
limit %d"
+megasas_iovec_sgl_underflow(int cmd, int index) "scmd %d: iovec count %d"
+megasas_iovec_sgl_invalid(int cmd, int index, uint64_t pa, uint32_t len) "scmd %d: invalid 
sgl element %d pa %" PRIx64 " len %u"
+megasas_iovec_len(int cmd, const char *desc, int len, int limit) "scmd %d: iovec %s 
len %d limit %d"
+disable megasas_handle_dcmd(int cmd, int opcode) "scmd %d: MFI DCMD opcode %x"
+disable megasas_finish_dcmd(int cmd, int size) "scmd %d: MFI DCMD wrote %d 
bytes"
+megasas_dcmd_req_alloc_failed(int cmd, const char *desc) "scmd %d: %s alloc 
failed"
+disable megasas_dcmd_internal_submit(int cmd, const char *desc, int dev) "scmd %d: 
%s to dev %d"
+disable megasas_dcmd_internal_finish(int cmd, int opcode, int lun) "scmd %d: DCMD 
finish internal cmd %x lun %d"
+megasas_dcmd_internal_invalid(int cmd, int opcode) "scmd %d: Invalid internal DCMD 
%x"
+megasas_dcmd_unhandled(int cmd, int opcode, int len) "scmd %d: opcode %x, len 
%d"
+disable megasas_dcmd_zero_sge(int cmd) "scmd %d: zero DCMD sge count"
+megasas_dcmd_invalid_sge(int cmd, int count) "scmd %d: invalid DCMD sge count 
%d"
+megasas_dcmd_map_failed(int cmd) "scmd %d: Failed to map DCMD buffer"
+megasas_dcmd_invalid_xfer

Re: [Qemu-devel] [PATCH] vga: optimize ppm_save() divisions

[Avi Kivity]

On 01/03/2012 03:32 PM, Avi Kivity wrote:
> ppm_save() spends upwards of 50% of its time doing divisions. Replace them
> with shifts.
>
>


Pings.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] throwing away translated code on CPU reset

[Andreas Färber]

Am 12.01.2012 15:00, schrieb Peter Maydell:
> When doing TCG code translation, the target-foo translate.c
> code is allowed to bake assumptions into the generated code from
> the current values of various fields in the CPUState. This then
> imposes the requirement that if the field is changed then tb_flush
> must be called to throw away the now-incorrect generated code.
> 
> However, cpu_reset() changes (unsurprisingly) lots of fields in
> the CPUState, but it doesn't call tb_flush()...
> 
> So should cpu_reset() implementations be changed to call tb_flush()
> as well as tlb_flush(), or is this supposed to work in some other
> way?

I would rather suggest to introduce a new cpu_common_reset() that hides
these details - memset() for common parts and whatever necessary here.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH] Fix qapi code generation fix

[Avi Kivity]

On 12/28/2011 12:26 PM, Avi Kivity wrote:
> The fixes to qapi code generation had multiple bugs:
> - the Null class used to drop output was missing some methods
> - in some scripts it was never instantiated, leading to a None return,
>   which is missing even more methods
> - the --source and --header options were swapped
>
> Luckily, all those bugs were hidden by a makefile bug which caused the
> old behaviour (with the race) to be invoked.

Pings.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH 0/2][RFC] postcopy migration: Linux char device for postcopy

[Avi Kivity]

On 01/04/2012 05:03 AM, Isaku Yamahata wrote:
> Yes, it's quite doable in user space(qemu) with a kernel-enhancement.
> And it would be easy to convert a separated daemon process into a thread
> in qemu.
>
> I think it should be done out side of qemu process for some reasons.
> (I just repeat same discussion at the KVM-forum because no one remembers
> it)
>
> - ptrace (and its variant)
>   Some people want to investigate guest ram on host (qemu stopped or lively).
>   For example, enhance crash utility and it will attach qemu process and
>   debug guest kernel.

To debug the guest kernel you don't need to stop qemu itself.   I agree
it's a problem for qemu debugging though.

>
> - core dump
>   qemu process may core-dump.
>   As postmortem analysis, people want to investigate guest RAM.
>   Again enhance crash utility and it will read the core file and analyze
>   guest kernel.
>   When creating core, the qemu process is already dead.

Yes, strong point.

> It precludes the above possibilities to handle fault in qemu process.

I agree.


-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH 0/2][RFC] postcopy migration: Linux char device for postcopy

[Avi Kivity]

On 01/03/2012 04:25 PM, Andrea Arcangeli wrote:
>  
> > > So the problem is if we do it in
> > > userland with the current functionality you'll run out of VMAs and
> > > slowdown performance too much.
> > >
> > > But all you need is the ability to map single pages in the address
> > > space.
> > 
> > Would this also let you set different pgprots for different pages in the 
> > same VMA?  It would be useful for write barriers in garbage collectors 
> > (such as boehm-gc).  These do not have _that_ many VMAs, because every 
> > GC cycles could merge all of them back to a single VMA with PROT_READ 
> > permissions; however, they still put some strain on the VM subsystem.
>
> Changing permission sounds more tricky as more code may make
> assumptions on the vma before checking the pte.
>
> Adding a magic unmapped pte entry sounds fairly safe because there's
> the migration pte already used by migrate which halts page faults and
> wait, that creates a precedent. So I guess we could reuse the same
> code that already exists for the migration entry and we'd need to fire
> a signal and returns to userland instead of waiting. The signal should
> be invoked before the page fault will trigger again. 

Delivering signals is slow, and you can't use signalfd for it, because
that can be routed to a different task.  I would like an fd based
protocol with an explicit ack so the other end can be implemented by the
kernel, to use with RDMA.  Kind of like how vhost-net talks to a guest
via a kvm ioeventfd/irqfd.

> Of course if the
> signal returns and does nothing it'll loop at 100% cpu load but that's
> ok. Maybe it's possible to tweak the permissions but it will need a
> lot more thoughts. Specifically for anon pages marking them readonly
> sounds possible if they are supposed to behave like regular COWs (not
> segfaulting or anything), as you already can have a mixture of
> readonly and read-write ptes (not to tell readonly KSM pages), but for
> any other case it's non trivial. Last but not the least the API here
> would be like a vma-less-mremap, moving a page from one address to
> another without modifying the vmas, the permission tweak sounds more
> like an mprotect, so I'm unsure if it could do both or if it should be
> an optimization to consider independently.

Doesn't this stuff require tlb flushes across all threads?

>
> In theory I suspect we could also teach mremap to do a
> not-vma-mangling mremap if we move pages that aren't shared and so we
> can adjust the page->index of the pages, instead of creating new vmas
> at the dst address with an adjusted vma->vm_pgoff, but I suspect a
> syscall that only works on top of fault-unmapped areas is simpler and
> safer. mremap semantics requires nuking the dst region before the move
> starts. If we would teach mremap how to handle the fault-unmapped
> areas we could just add one syscall prepare_fault_area (or whatever
> name you choose).
>
> The locking of doing a vma-less-mremap still sounds tricky but I doubt
> you can avoid that locking complexity by using the chardevice as long
> as the chardevice backed-memory still allows THP, migration and swap,
> if you want to do it atomic-zerocopy and I think zerocopy would be
> better especially if the network card is fast and all vcpus are
> faulting into unmapped pages simultaneously so triggering heavy amount
> of copying from all physical cpus.
>
> I don't mean the current device driver doing a copy_user won't work or
> is bad idea, it's more self contained and maybe easier to merge
> upstream. I'm just presenting another option more VM integrated
> zerocopy with just 2 syscalls.

Zerocopy is really interesting here, esp. w/ RDMA.  But while adding
ptes is cheap, removing them is not.  I wonder if we can make a
write-only page?  Of course it's unmapped for cpu access, but we can
allow DMA write access from the NIC.  Probably too wierd.

>
> vmas must not be involved in the mremap for reliability, or too much
> memory could get pinned in vmas even if we temporary lift the
> /proc/sys/vm/max_map_count for the process. Plus sending another
> signal (not sigsegv or sigbus) should be more reliable in case the
> migration crashes for real.


-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] [PATCH] bt-host: add missing break statement

[Stefan Hajnoczi]

The switch statement in bt_host_read() is missing a break in one case.
Andrzej Zaborowski  confirmed that this is
not an intentional fall-through.

Signed-off-by: Stefan Hajnoczi 
---
 bt-host.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/bt-host.c b/bt-host.c
index df5b7cd..0d3ad28 100644
--- a/bt-host.c
+++ b/bt-host.c
@@ -130,6 +130,7 @@ static void bt_host_read(void *opaque)
 pktlen = MIN(pkt[2] + 3, s->len);
 s->len -= pktlen;
 pkt += pktlen;
+break;
 
 default:
 bad_pkt:
-- 
1.7.7.3

Re: [Qemu-devel] [PATCH 10/15] test: eliminate libcheck tests and have make check use gtester

[Eduardo Habkost]

On Tue, Jan 10, 2012 at 01:10:51PM -0600, Anthony Liguori wrote:
[...]
> @@ -733,10 +732,6 @@ for opt do
>;;
>--enable-fdt) fdt="yes"
>;;
> -  --disable-check-utests) check_utests="no"
> -  ;;
> -  --enable-check-utests) check_utests="yes"
> -  ;;
>--disable-nptl) nptl="no"
>;;
>--enable-nptl) nptl="yes"

You forgot to remove this:

@@ -2825,7 +2825,6 @@ fi
 echo "SDL support   $sdl"
 echo "curses support$curses"
 echo "curl support  $curl"
-echo "check support $check_utests"
 echo "mingw32 support   $mingw32"
 echo "Audio drivers $audio_drv_list"
 echo "Extra audio cards $audio_card_list"

-- 
Eduardo