Re: [Qemu-devel] [PATCH for-2.6] acpi: fix bios linker loadder COMMAND_ALLOCATE on bigendian host

[Marcel Apfelbaum]

On 04/29/2016 03:44 PM, Igor Mammedov wrote:

'make check' fails with:

ERROR:tests/bios-tables-test.c:493:load_expected_aml:
assertion failed: (g_file_test(aml_file, G_FILE_TEST_EXISTS))

since commit:
caf50c7166a6ed96c462ab5db4b495e1234e4cc6
tests: pc: acpi: drop not needed 'expected SSDT' blobs

Assert happens because qemu-system-x86_64 generates
SSDT table and test looks for a corresponding expected
table to compare with.

However there is no expected SSDT blob anymore, since
QEMU souldn't generate one. As it happens BIOS is not
able to read ACPI tables from QEMU and fallbacks to
embeded legacy ACPI codepath, which generates SSDT.
That happens due to wrongly sized endiannes conversion
which makes
  uint8_t BiosLinkerLoaderEntry.alloc.zone
end up with 0 due to truncation of 32 bit integer
which on host is 1 or 2.

Fix it by dropping invalid cpu_to_le32() as uint8_t
doesn't require any conversion.

RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1330174

Signed-off-by: Igor Mammedov 
---
  hw/acpi/bios-linker-loader.c | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/hw/acpi/bios-linker-loader.c b/hw/acpi/bios-linker-loader.c
index ace9abb..5153ab1 100644
--- a/hw/acpi/bios-linker-loader.c
+++ b/hw/acpi/bios-linker-loader.c
@@ -135,9 +135,8 @@ void bios_linker_loader_alloc(GArray *linker,
  strncpy(entry.alloc.file, file, sizeof entry.alloc.file - 1);
  entry.command = cpu_to_le32(BIOS_LINKER_LOADER_COMMAND_ALLOCATE);
  entry.alloc.align = cpu_to_le32(alloc_align);
-entry.alloc.zone = cpu_to_le32(alloc_fseg ?
-BIOS_LINKER_LOADER_ALLOC_ZONE_FSEG :
-BIOS_LINKER_LOADER_ALLOC_ZONE_HIGH);
+entry.alloc.zone = alloc_fseg ? BIOS_LINKER_LOADER_ALLOC_ZONE_FSEG :
+BIOS_LINKER_LOADER_ALLOC_ZONE_HIGH;

  /* Alloc entries must come first, so prepend them */
  g_array_prepend_vals(linker, &entry, sizeof entry);



Reviewed-by: Marcel Apfelbaum 

Thanks,
Marcel

Re: [Qemu-devel] [PATCH v2 5/5] tests: fix libqtest socket timeouts

[Marcel Apfelbaum]

On 04/29/2016 05:47 PM, Dr. David Alan Gilbert (git) wrote:

From: Andrea Arcangeli 

I kept getting timeouts and unix socket accept failures under high
load, the patch fixes it.

Signed-off-by: Andrea Arcangeli 
---
  tests/libqtest.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/libqtest.c b/tests/libqtest.c
index b12a9e4..57ce292 100644
--- a/tests/libqtest.c
+++ b/tests/libqtest.c
@@ -27,7 +27,7 @@
  #include "qapi/qmp/qjson.h"

  #define MAX_IRQ 256
-#define SOCKET_TIMEOUT 5
+#define SOCKET_TIMEOUT 50

  QTestState *global_qtest;





Reviewed-by: Marcel Apfelbaum 

Thanks,
Marcel

Re: [Qemu-devel] [PATCH v2 4/5] test: Postcopy

[Marcel Apfelbaum]

Hi David,

On 04/29/2016 05:47 PM, Dr. David Alan Gilbert (git) wrote:

From: "Dr. David Alan Gilbert" 

This is a postcopy test (x86 only) that actually runs the guest
and checks the memory contents.

The test runs from an x86 boot block with the hex embedded in the test;
the source for this is:

...

.code16
.org 0x7c00
.file   "fill.s"
.text
.globl  start
.type   start, @function
start: # at 0x7c00 ?
 cli
 lgdt gdtdesc
 mov $1,%eax
 mov %eax,%cr0  # Protected mode enable
 data32 ljmp $8,$0x7c20

.org 0x7c20
.code32
 # A20 enable - not sure I actually need this
 inb $0x92,%al
 or  $2,%al
 outb %al, $0x92

 # set up DS for the whole of RAM (needed on KVM)
 mov $16,%eax
 mov %eax,%ds

 mov $65,%ax
 mov $0x3f8,%dx
 outb %al,%dx

 # bl keeps a counter so we limit the output speed
 mov $0, %bl
mainloop:
 # Start from 1MB
 mov $(1024*1024),%eax
innerloop:
 incb (%eax)
 add $4096,%eax
 cmp $(100*1024*1024),%eax
 jl innerloop

 inc %bl
 jnz mainloop

 mov $66,%ax
 mov $0x3f8,%dx
 outb %al,%dx

jmp mainloop

 # GDT magic from old (GPLv2)  Grub startup.S
 .p2align2   /* force 4-byte alignment */
gdt:
 .word   0, 0
 .byte   0, 0, 0, 0

 /* -- code segment --
  * base = 0x, limit = 0xF (4 KiB Granularity), present
  * type = 32bit code execute/read, DPL = 0
  */
 .word   0x, 0
 .byte   0, 0x9A, 0xCF, 0

 /* -- data segment --
  * base = 0x, limit 0xF (4 KiB Granularity), present
  * type = 32 bit data read/write, DPL = 0
  */
 .word   0x, 0
 .byte   0, 0x92, 0xCF, 0

gdtdesc:
 .word   0x27/* limit */
 .long   gdt /* addr */

/* I'm a bootable disk */
.org 0x7dfe
 .byte 0x55
 .byte 0xAA

...

and that can be assembled by the following magic:
 as --32 -march=i486 fill.s -o fill.o
 objcopy -O binary fill.o fill.boot
 dd if=fill.boot of=bootsect bs=256 count=2 skip=124
 xxd -i bootsect



I suppose you can use this a source file and compile it
as part of make check, but I am not sure if is worth it.


Signed-off-by: Dr. David Alan Gilbert 
---
  tests/Makefile|   2 +
  tests/postcopy-test.c | 455 ++
  2 files changed, 457 insertions(+)
  create mode 100644 tests/postcopy-test.c

diff --git a/tests/Makefile b/tests/Makefile
index 9194f18..f356f4a 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -224,6 +224,7 @@ endif
  check-qtest-i386-y += tests/test-netfilter$(EXESUF)
  check-qtest-i386-y += tests/test-filter-mirror$(EXESUF)
  check-qtest-i386-y += tests/test-filter-redirector$(EXESUF)
+check-qtest-i386-y += tests/postcopy-test$(EXESUF)
  check-qtest-x86_64-y = $(check-qtest-i386-y)
  gcov-files-i386-y += i386-softmmu/hw/timer/mc146818rtc.c
  gcov-files-x86_64-y = $(subst 
i386-softmmu/,x86_64-softmmu/,$(gcov-files-i386-y))
@@ -579,6 +580,7 @@ tests/usb-hcd-uhci-test$(EXESUF): tests/usb-hcd-uhci-test.o 
$(libqos-usb-obj-y)
  tests/usb-hcd-ehci-test$(EXESUF): tests/usb-hcd-ehci-test.o 
$(libqos-usb-obj-y)
  tests/usb-hcd-xhci-test$(EXESUF): tests/usb-hcd-xhci-test.o 
$(libqos-usb-obj-y)
  tests/pc-cpu-test$(EXESUF): tests/pc-cpu-test.o
+tests/postcopy-test$(EXESUF): tests/postcopy-test.o
  tests/vhost-user-test$(EXESUF): tests/vhost-user-test.o qemu-char.o 
qemu-timer.o $(qtest-obj-y) $(test-io-obj-y)
  tests/qemu-iotests/socket_scm_helper$(EXESUF): 
tests/qemu-iotests/socket_scm_helper.o
  tests/test-qemu-opts$(EXESUF): tests/test-qemu-opts.o $(test-util-obj-y)
diff --git a/tests/postcopy-test.c b/tests/postcopy-test.c
new file mode 100644
index 000..3712a50
--- /dev/null
+++ b/tests/postcopy-test.c
@@ -0,0 +1,455 @@
+/*
+ * QTest testcase for postcopy
+ *
+ * Copyright (c) 2016 Red Hat, Inc. and/or its affiliates
+ *   based on the vhost-user-test.c that is:
+ *  Copyright (c) 2014 Virtual Open Systems Sarl.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include 
+
+#include "libqtest.h"
+#include "qemu/option.h"
+#include "qemu/range.h"
+#include "sysemu/char.h"
+#include "sysemu/sysemu.h"
+
+#include 
+#include 
+#include 
+
+#if defined(__linux__)
+#include 
+#endif
+
+#if defined(__linux__) && defined(__NR_userfaultfd) && defined(CONFIG_EVENTFD)
+#include 
+#include 
+#include 
+
+const unsigned start_address = 1024 * 1024;
+const unsigned end_address = 100 * 1024 * 1024;
+bool got_stop;
+
+static bool ufd_version_check(void)
+{
+struct uffdio_api api_struct;
+uint64_t ioctl

Re: [Qemu-devel] [V9 3/4] hw/core: Add AMD IOMMU to machine properties

[Marcel Apfelbaum]

On 04/30/2016 01:42 AM, David Kiarie wrote:

Added an enum, subject to review, to machine properties which
it used to override iommu emulated from Intel to AMD.

Signed-off-by: David Kiarie 
---
  hw/core/machine.c | 33 ++---
  include/hw/boards.h   |  1 +
  include/hw/i386/intel_iommu.h |  1 +
  qemu-options.hx   |  7 +--
  util/qemu-config.c|  8 ++--
  5 files changed, 43 insertions(+), 7 deletions(-)

diff --git a/hw/core/machine.c b/hw/core/machine.c
index 6dbbc85..ff830f0 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -15,6 +15,8 @@
  #include "qapi/error.h"
  #include "qapi-visit.h"
  #include "qapi/visitor.h"
+#include "hw/i386/amd_iommu.h"
+#include "hw/i386/intel_iommu.h"
  #include "hw/sysbus.h"
  #include "sysemu/sysemu.h"
  #include "qemu/error-report.h"
@@ -300,6 +302,27 @@ static void machine_set_iommu(Object *obj, bool value, 
Error **errp)
  ms->iommu = value;
  }

+static void machine_set_iommu_override(Object *obj, const char *value,
+   Error **errp)
+{
+MachineState *ms = MACHINE(obj);
+Error *err = NULL;
+
+ms->iommu_type = TYPE_INTEL;
+/* ensure a valid iommu type */
+if (g_strcmp0(value, AMD_IOMMU_STR) == 0) {
+} else if(g_strcmp0(value, INTEL_IOMMU_STR) == 0) {
+} else {
+error_setg(errp, "Invalid IOMMU type %s", value);
+error_propagate(errp, err);


You don't need 'error_propagate' and the err pointer(is not used),
error_setg does the job right.

Also you declared the IommuType as enum  (thanks for that, I really like it!) :
   typedef enum IommuType {
  TYPE_AMD,
  TYPE_INTEL,
  TYPE_NONE
  } IommuType;
What happens if the user does not set this property?
ms->iommu_type will default to AMD and -machine iommu=on
will enable AMD by default.
You can choose between swicthing the values in enum
or add  ms->iommu_type = TYPE_INTEL; to machine_init.

While at it, I would re-write it in a more standard way:

if (g_strcmp0(value, INTEL_IOMMU_STR) == 0) {
ms->iommu_type = TYPE_INTEL;
} else if(g_strcmp0(value, AMD_IOMMU_STR) == 0) {
ms->iommu_type = TYPE_AMD;
} else {
error_setg(errp, "Invalid IOMMU type %s", value);
}


Other than that the patch is ready, thank you for taking the time
to address the comments,
Marcel


+return;
+}
+
+if ((g_strcmp0(value, AMD_IOMMU_STR) == 0)) {
+ms->iommu_type = TYPE_AMD;
+}
+}
+
  static void machine_set_suppress_vmdesc(Object *obj, bool value, Error **errp)
  {
  MachineState *ms = MACHINE(obj);
@@ -473,10 +496,14 @@ static void machine_initfn(Object *obj)
  "Firmware image",
  NULL);
  object_property_add_bool(obj, "iommu",
- machine_get_iommu,
- machine_set_iommu, NULL);
+ machine_get_iommu, machine_set_iommu, NULL);
  object_property_set_description(obj, "iommu",
-"Set on/off to enable/disable Intel IOMMU 
(VT-d)",
+"Set on to enable IOMMU emulation",
+NULL);
+object_property_add_str(obj, "x-iommu-type",
+NULL, machine_set_iommu_override, NULL);
+object_property_set_description(obj, "x-iommu-type",
+"Set on to override emulated IOMMU to AMD 
IOMMU",
  NULL);
  object_property_add_bool(obj, "suppress-vmdesc",
   machine_get_suppress_vmdesc,
diff --git a/include/hw/boards.h b/include/hw/boards.h
index dbe6745..5b7eeda 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -158,6 +158,7 @@ struct MachineState {
  bool igd_gfx_passthru;
  char *firmware;
  bool iommu;
+IommuType iommu_type;
  bool suppress_vmdesc;
  bool enforce_config_section;

diff --git a/include/hw/i386/intel_iommu.h b/include/hw/i386/intel_iommu.h
index b024ffa..7e511e1 100644
--- a/include/hw/i386/intel_iommu.h
+++ b/include/hw/i386/intel_iommu.h
@@ -24,6 +24,7 @@
  #include "hw/qdev.h"
  #include "sysemu/dma.h"

+#define INTEL_IOMMU_STR "intel"
  #define TYPE_INTEL_IOMMU_DEVICE "intel-iommu"
  #define INTEL_IOMMU_DEVICE(obj) \
   OBJECT_CHECK(IntelIOMMUState, (obj), TYPE_INTEL_IOMMU_DEVICE)
diff --git a/qemu-options.hx b/qemu-options.hx
index 6106520..81217d3 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -38,7 +38,8 @@ DEF("machine", HAS_ARG, QEMU_OPTION_machine, \
  "kvm_shadow_mem=size of KVM shadow MMU\n"
  "dump-guest-core=on|off include guest memory in a core dump 
(default=on)\n"
  "mem-merge=on|off controls memory merge support (default: 
on)\n"
-"iommu=on|off controls emulated Intel IOMMU (VT-

Re: [Qemu-devel] [V9 4/4] hw/pci-host: Emulate AMD IOMMU

[Marcel Apfelbaum]

On 04/30/2016 01:42 AM, David Kiarie wrote:

Add AMD IOMMU emulation support to q35 chipset

Signed-off-by: David Kiarie 
---
  hw/pci-host/q35.c | 25 ++---
  include/hw/i386/intel_iommu.h |  2 +-
  2 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index 70f897e..b4e1bfe 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -32,6 +32,7 @@
  #include "hw/pci-host/q35.h"
  #include "qapi/error.h"
  #include "qapi/visitor.h"
+#include "hw/i386/amd_iommu.h"

  /
   * Q35 host
@@ -448,6 +449,19 @@ static void mch_init_dmar(MCHPCIState *mch)
  pci_setup_iommu(pci_bus, q35_host_dma_iommu, mch->iommu);
  }

+static void mch_init_amdvi(MCHPCIState *mch)
+{
+AMDIOMMUState *iommu_state;
+PCIBus *bus = PCI_BUS(qdev_get_parent_bus(DEVICE(mch)));
+PCIDevice *iommu;
+
+iommu = pci_create_simple(bus, 0x20, TYPE_AMD_IOMMU_DEVICE);
+
+iommu_state = AMD_IOMMU_DEVICE(iommu);
+
+pci_setup_iommu(bus, bridge_host_amd_iommu, iommu_state);
+}
+
  static void mch_realize(PCIDevice *d, Error **errp)
  {
  int i;
@@ -506,9 +520,14 @@ static void mch_realize(PCIDevice *d, Error **errp)
   mch->pci_address_space, &mch->pam_regions[i+1],
   PAM_EXPAN_BASE + i * PAM_EXPAN_SIZE, PAM_EXPAN_SIZE);
  }
-/* Intel IOMMU (VT-d) */
-if (object_property_get_bool(qdev_get_machine(), "iommu", NULL)) {
-mch_init_dmar(mch);
+
+MachineState *machine = MACHINE(qdev_get_machine());
+if (machine->iommu) {
+if (machine->iommu_type == TYPE_AMD) {
+mch_init_amdvi(mch);
+} else {
+mch_init_dmar(mch);
+}
  }
  }

diff --git a/include/hw/i386/intel_iommu.h b/include/hw/i386/intel_iommu.h
index 7e511e1..539530c 100644
--- a/include/hw/i386/intel_iommu.h
+++ b/include/hw/i386/intel_iommu.h
@@ -24,10 +24,10 @@
  #include "hw/qdev.h"
  #include "sysemu/dma.h"

-#define INTEL_IOMMU_STR "intel"
  #define TYPE_INTEL_IOMMU_DEVICE "intel-iommu"
  #define INTEL_IOMMU_DEVICE(obj) \
   OBJECT_CHECK(IntelIOMMUState, (obj), TYPE_INTEL_IOMMU_DEVICE)
+#define INTEL_IOMMU_STR "intel"


I am not sure why you needed this chunck and if Michael will
accept the hard-coded 0x20 address for the AMD IOMMU, but the realization
code looks good to me.

Reviewed-by: Marcel Apfelbaum 

Thanks,
Marcel



  /* DMAR Hardware Unit Definition address (IOMMU unit) */
  #define Q35_HOST_BRIDGE_IOMMU_ADDR  0xfed9ULL

Re: [Qemu-devel] [PATCH v3 for-2.6 3/5] virtio: Mark host notifiers as external

[Michael S. Tsirkin]

On Sun, May 01, 2016 at 11:15:10AM +0300, Michael S. Tsirkin wrote:
> On Fri, Apr 22, 2016 at 09:53:54PM +0800, Fam Zheng wrote:
> > The effect of this change is the block layer drained section can work,
> > for example when mirror job is being completed.
> > 
> > Signed-off-by: Fam Zheng 
> 
> This is indentical to v2, so why don't you include the
> Reviewed-by: Michael S. Tsirkin 
> tag I sent on v2?

Oh, I asked this before. Sorry about the noise.

> > ---
> >  hw/virtio/virtio.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> > index fffa09f..30ede3d 100644
> > --- a/hw/virtio/virtio.c
> > +++ b/hw/virtio/virtio.c
> > @@ -1829,10 +1829,10 @@ void 
> > virtio_queue_set_host_notifier_fd_handler(VirtQueue *vq, bool assign,
> > bool set_handler)
> >  {
> >  if (assign && set_handler) {
> > -event_notifier_set_handler(&vq->host_notifier, false,
> > +event_notifier_set_handler(&vq->host_notifier, true,
> > virtio_queue_host_notifier_read);
> >  } else {
> > -event_notifier_set_handler(&vq->host_notifier, false, NULL);
> > +event_notifier_set_handler(&vq->host_notifier, true, NULL);
> >  }
> >  if (!assign) {
> >  /* Test and clear notifier before after disabling event,
> > -- 
> > 2.8.0

Re: [Qemu-devel] [PATCH V2 RFC] fixup! virtio: convert to use DMA api

[Michael S. Tsirkin]

On Thu, Apr 28, 2016 at 04:48:25PM +0100, David Woodhouse wrote:
> On Thu, 2016-04-28 at 18:37 +0300, Michael S. Tsirkin wrote:
> > OK, so for intel, it seems that it's enough to set
> > pdev->dev.archdata.iommu = DUMMY_DEVICE_DOMAIN_INFO;
> > for the device.
> 
> Yes, currently. Although that's vile. In fact what we *want* to happen
> is for the intel-iommu code simply to decline to provide DMA ops for
> this device, and let it fall back to the swiotlb or no-op DMA ops, as
> appropriate.
> 
> As it is, we have the intel-iommu DMA ops *unconditionally, and they
> have a hack to manually fall back to calling swiotlb. It's all just
> horrid, which is why I want to clean it up with nice per-device DMA ops
> and discovery thereof :)
> 
> > Do I have to poke at each iommu implementation to find
> > a way to do this, or is there some way to do it
> > portably?
> 
> There *will* be Christoph has already done some of the cleanup in
> this space, and I need to take stock of what he's already done, and
> finish off the parts I want to build on top of it.
> 
> > Not exactly - I think that future versions of qemu might lie
> > about some devices but not others.
> 
> Can we keep this simple?
> 
> QEMU currently lies about some devices. Let's implement a heuristic for
> the guest OS to know about that, and react accordingly.
> 
> Then let's fix QEMU to tell the truth. All the time, unconditionally.
> Even on POWER/ARM where there's no obvious *way* for it to tell the
> truth (because you don't have the flexibility that DMAR tables do), and
> we need to devise a way to put it in the device-tree or fwcfg or
> something else.

Right.  Unfortunately all these aren't easy to implement at all.
So I'm inclined to go the "something else" route.
It has the added benefit of giving us a heuristic for free.

> And only once QEMU consistently tells the *truth*, then we can start to
> do new stuff and let it actually change its behaviour.
> 
> > DMAR is unfortunately not a good match for what people do with QEMU.
> > 
> > There is a patchset on list fixing translation of assigned
> > devices. So the fix for these will simply be to do translation for
> > all assigned devices. It's harder for virtio as it isn't always
> > processed in QEMU - there's vhost in kernel and an out of process
> > vhost-user plugin. So we can end up e.g. with modern QEMU which
> > does translate in-process virtio but not out of process one.
> 
> Right... just stop. Fix QEMU to tell the truth first, and *then* once
> we can trust it, we can start to change its behaviour. :)
> 
> > Unfortunately people got used to be able to put any device
> > in any slot, and built external tools around that ability.
> > It's rather painful to break this assumption.
> 
> Well, if you just said you have a patch set which allows translation of
> assigned devices then you are most of the way there, aren't you? We
> just need to fix the out-of-process virtio case, and everything can be
> either translated or untranslated?

Absolutely. But that "just" will take a while.  With out of process
there's always a chance that remote doesn't implement translation. E.g.
new QEMU running on an old host kernel.

> -- 
> dwmw2
> 

Re: [Qemu-devel] [PATCH 11/18] vhost-user: add shutdown support

[Michael S. Tsirkin]

On Fri, Apr 29, 2016 at 10:48:35AM -0700, Yuanhan Liu wrote:
> > But, I
> > would worry first about a backend that crashes that it may corrupt the
> > VM memory too...
> 
> Not quite sure I follow this. But, backend just touches the virtio
> related memory, so it will do no harm to the VM?

It crashed so apparently it's not behaving as designed -
how can we be sure it does not harm the VM?

-- 
MST

[Qemu-devel] TCP Segementation Offloading

[Ingo Krabbe]

Good Mayday Qemu Developers,

today I tried to find a reference to a networking problem, that seems to be of 
quite general nature: TCP Segmentation Offloading (TSO) in virtual environments.

When I setup TAP network adapter for a virtual machine and put it into a host 
bridge, the known best practice is to manually set "tso off gso off" with 
ethtool, for the guest driver if I use a hardware emulation, such as e1000 
and/or "tso off gso off" for the host driver and/or for the bridge adapter, if 
I use the virtio driver, as otherwise you experience (sometimes?) performance 
problems or even lost packages.

I haven't found a complete analysis of the background of these problems, but 
there seem to be some effects on MTU based fragmentation and UDP checksums.

There is a tso related bug on launchpad, but the context of this bug is too 
narrow, for the generality of the problem.

Also it seems that there is a problem in LXC contexts too (I found such a 
reference, without detailed description in a Post about Xen setup).

My question now is: Is there a bug in the driver code and shouldn't this be 
documented somewhere in wiki.qemu.org? Where there developments about this 
topic in the past or is there any planned/ongoing work todo on the qemu drivers?

Most problem reports found relate to deprecated Centos6 qemu-kvm packages.

In our company we have similar or even worse problems with Centos7 hosts and 
guest machines.

I'm going to analyze these problems next week anyway and I woud be happy to 
share my observation with you. (Where can I register for the wiki, or whom 
should I sent my reports about this topic?).

Regards,

Ingo Krabbe

[Qemu-devel] [Bug 1202289] Re: Windows 2008/7 Guest to Guest Very slow 10-20Mbit/s

[Ingo Krabbe]

I'm not sure yet, but I think the TSO problem affects much more setups,
not only windows guests. You might try to set GSO to off in windows
guests too, if there is such an option (GSO might be a linux kernel
feature).

I currently think that we have similar problems with centos7 hosts and
guests as well as with some windows7 guests.

I also read about similar centos6 problems. There is even a original
setup guide for centos6 from redhat, to set "tso off gso off" in the
host bridge adapter, when you use virtio.

This whole topic is disturbingly distributed through several setups. The
diagnosis of this problem is far from being trivial.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1202289

Title:
  Windows 2008/7 Guest to Guest Very slow 10-20Mbit/s

Status in QEMU:
  New

Bug description:
  I'm not sure if I'm submitting this to the proper place or not, if
  not, please direct me accordingly.

  At this point I'm starting to get desperate, I'll take any options or
  suggestions that spring to mind:

  Anyway, the problem exists on multiple hosts of various quality.
  From 4 core 8g mem machines to 12 core 64Gig mem machines with LVM and
  Raid-10.

  Using iperf as the testing utility: (windows guest can be either Windows 7 or 
2008R2)
  -Windows Guest -> Windows Guest averages 20Mbit/s (The problem)
  -Windows Guest -> Host averages 800Mbit/s
  -Host -> Windows Guest averages 1.1Gbit/s
  -Linux Guest -> Host averages 12GBit/s
  -Linux Guest -> Linux Guest averages 10.2Gbit/s

  For windows guests, switching between e1000 and virtio drivers doesn't
  make much of a difference.

  I use openvswitch to handle the bridging (makes bonding nics much
  easier)

  Disabling TSO GRO on all the host nics, and virtual nics, as well as modding 
the registry using:
  netsh int tcp set global (various params here)  can slightly improve Windows 
-> windows throughput.   up to maybe 100Mbit/sbut even that is spotty at 
best.

  The Particulars of the fastest host which benchmarks about the same as
  the slowest host.

  Ubuntu 12.04 64bit (updated to lastest as of  July 15th)
  Linux cckvm03 3.5.0-36-generic #57~precise1-Ubuntu SMP Thu Jun 20 18:21:09 
UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

  libvirt: 
  Source: libvirt
  Version: 0.9.8-2ubuntu17.10

  qemu-kvm
  Package: qemu-kvm
  Version: 1.0+noroms-0ubuntu14.8
  Replaces: kvm (<< 1:84+dfsg-0ubuntu16+0.11.0), kvm-data, qemu

  openvswitch
  Source: openvswitch
  Version: 1.4.0-1ubuntu1.5

  /proc/cpuifo

  processor   : 0
  vendor_id   : GenuineIntel
  cpu family  : 6
  model   : 45
  model name  : Intel(R) Xeon(R) CPU E5-2440 0 @ 2.40GHz
  stepping: 7
  microcode   : 0x70d
  cpu MHz : 2400.226
  cache size  : 15360 KB
  physical id : 0
  siblings: 12
  core id : 0
  cpu cores   : 6
  apicid  : 0
  initial apicid  : 0
  fpu : yes
  fpu_exception   : yes
  cpuid level : 13
  wp  : yes
  flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov
  pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdt
  scp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
ap
  erfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr 
pdc
  m pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx 
lahf_lm
  ida arat xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
  bogomips: 4800.45
  clflush size: 64
  cache_alignment : 64
  address sizes   : 46 bits physical, 48 bits virtual
  power management:

  
  -Sample KVM line
  usr/bin/kvm -S -M pc-1.0 -enable-kvm -m 4096 -smp 
2,sockets=2,cores=1,threads=1 -name gvexch01 -uuid 
d28ffb4b-d809-3b40-ae3d-2925e6995394 -nodefconfig -nodefaults -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/gvexch01.monitor,server,nowait 
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime 
-no-shutdown -boot order=dc,menu=on -drive 
file=/dev/vgroup/gvexch01,if=none,id=drive-virtio-disk0,format=raw,cache=none,aio=native
 -device 
virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 
-drive 
file=/dev/vgroup/gvexch01-d,if=none,id=drive-virtio-disk1,format=raw,cache=none 
-device 
virtio-blk-pci,bus=pci.0,addr=0x6,drive=drive-virtio-disk1,id=virtio-disk1 
-drive if=none,media=cdrom,id=drive-ide0-0-0,readonly=on,format=raw -device 
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev 
tap,fd=18,id=hostnet0,vhost=on,vhostfd=21 -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:bf:4e:1c,bus=pci.0,addr=0x3 
-chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 
-usb -device usb-tablet,id=input0 -vnc 127.0.0.1:2 -vga std -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5

To manage notifications about this bug go to:
https:

[Qemu-devel] [PULL 1/1] acpi: fix bios linker loadder COMMAND_ALLOCATE on bigendian host

[Michael S. Tsirkin]

From: Igor Mammedov 

'make check' fails with:

ERROR:tests/bios-tables-test.c:493:load_expected_aml:
   assertion failed: (g_file_test(aml_file, G_FILE_TEST_EXISTS))

since commit:
caf50c7166a6ed96c462ab5db4b495e1234e4cc6
tests: pc: acpi: drop not needed 'expected SSDT' blobs

Assert happens because qemu-system-x86_64 generates
SSDT table and test looks for a corresponding expected
table to compare with.

However there is no expected SSDT blob anymore, since
QEMU souldn't generate one. As it happens BIOS is not
able to read ACPI tables from QEMU and fallbacks to
embeded legacy ACPI codepath, which generates SSDT.
That happens due to wrongly sized endiannes conversion
which makes
 uint8_t BiosLinkerLoaderEntry.alloc.zone
end up with 0 due to truncation of 32 bit integer
which on host is 1 or 2.

Fix it by dropping invalid cpu_to_le32() as uint8_t
doesn't require any conversion.

RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1330174

Signed-off-by: Igor Mammedov 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
Tested-by: Laurent Vivier 
Reviewed-by: Marcel Apfelbaum 
---
 hw/acpi/bios-linker-loader.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/hw/acpi/bios-linker-loader.c b/hw/acpi/bios-linker-loader.c
index ace9abb..5153ab1 100644
--- a/hw/acpi/bios-linker-loader.c
+++ b/hw/acpi/bios-linker-loader.c
@@ -135,9 +135,8 @@ void bios_linker_loader_alloc(GArray *linker,
 strncpy(entry.alloc.file, file, sizeof entry.alloc.file - 1);
 entry.command = cpu_to_le32(BIOS_LINKER_LOADER_COMMAND_ALLOCATE);
 entry.alloc.align = cpu_to_le32(alloc_align);
-entry.alloc.zone = cpu_to_le32(alloc_fseg ?
-BIOS_LINKER_LOADER_ALLOC_ZONE_FSEG :
-BIOS_LINKER_LOADER_ALLOC_ZONE_HIGH);
+entry.alloc.zone = alloc_fseg ? BIOS_LINKER_LOADER_ALLOC_ZONE_FSEG :
+BIOS_LINKER_LOADER_ALLOC_ZONE_HIGH;
 
 /* Alloc entries must come first, so prepend them */
 g_array_prepend_vals(linker, &entry, sizeof entry);
-- 
MST

[Qemu-devel] [PULL 0/1] acpi: last minute fix for 2.6

[Michael S. Tsirkin]

The following changes since commit 47dac82d8b013a5c7dd044a797ae6727b553959a:

  Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging 
(2016-04-29 12:12:33 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream

for you to fetch changes up to 1dbfd7892b66c757fdf67f346be40233adbad80e:

  acpi: fix bios linker loadder COMMAND_ALLOCATE on bigendian host (2016-05-01 
15:42:13 +0300)


acpi: last minute fix for 2.6

Minor, obvious fix only affecting BE hosts.

Signed-off-by: Michael S. Tsirkin 


Igor Mammedov (1):
  acpi: fix bios linker loadder COMMAND_ALLOCATE on bigendian host

 hw/acpi/bios-linker-loader.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

Re: [Qemu-devel] [V9 2/4] hw/i386: ACPI table for AMD IOMMU

[Michael S. Tsirkin]

On Sat, Apr 30, 2016 at 01:42:41AM +0300, David Kiarie wrote:
> Add IVRS table for AMD IOMMU. Generate IVRS or DMAR
> depending on emulated IOMMU
> 
> Signed-off-by: David Kiarie 
> ---
>  hw/acpi/aml-build.c |  2 +-
>  hw/acpi/core.c  | 13 ---
>  hw/i386/acpi-build.c| 93 
> +++--
>  include/hw/acpi/acpi-defs.h | 14 +++
>  include/hw/acpi/acpi.h  | 16 
>  include/hw/acpi/aml-build.h |  1 +
>  include/hw/boards.h |  6 +++
>  7 files changed, 120 insertions(+), 25 deletions(-)
> 
> diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
> index ab89ca6..da11bf8 100644
> --- a/hw/acpi/aml-build.c
> +++ b/hw/acpi/aml-build.c
> @@ -227,7 +227,7 @@ static void build_extop_package(GArray *package, uint8_t 
> op)
>  build_prepend_byte(package, 0x5B); /* ExtOpPrefix */
>  }
>  
> -static void build_append_int_noprefix(GArray *table, uint64_t value, int 
> size)
> +void build_append_int_noprefix(GArray *table, uint64_t value, int size)
>  {
>  int i;
>  
> diff --git a/hw/acpi/core.c b/hw/acpi/core.c
> index 7925a1a..ee0e687 100644
> --- a/hw/acpi/core.c
> +++ b/hw/acpi/core.c
> @@ -29,19 +29,6 @@
>  #include "qapi-visit.h"
>  #include "qapi-event.h"
>  
> -struct acpi_table_header {
> -uint16_t _length; /* our length, not actual part of the hdr */
> -  /* allows easier parsing for fw_cfg clients */
> -char sig[4];  /* ACPI signature (4 ASCII characters) */
> -uint32_t length;  /* Length of table, in bytes, including header 
> */
> -uint8_t revision; /* ACPI Specification minor version # */
> -uint8_t checksum; /* To make sum of entire table == 0 */
> -char oem_id[6];   /* OEM identification */
> -char oem_table_id[8]; /* OEM table identification */
> -uint32_t oem_revision;/* OEM revision number */
> -char asl_compiler_id[4];  /* ASL compiler vendor ID */
> -uint32_t asl_compiler_revision; /* ASL compiler revision number */
> -} QEMU_PACKED;
>  
>  #define ACPI_TABLE_HDR_SIZE sizeof(struct acpi_table_header)
>  #define ACPI_TABLE_PFX_SIZE sizeof(uint16_t)  /* size of the extra prefix */
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index 6477003..74ae994 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -52,6 +52,7 @@
>  #include "hw/pci/pci_bus.h"
>  #include "hw/pci-host/q35.h"
>  #include "hw/i386/intel_iommu.h"
> +#include "hw/i386/amd_iommu.h"
>  #include "hw/timer/hpet.h"
>  
>  #include "hw/acpi/aml-build.h"
> @@ -59,6 +60,8 @@
>  #include "qapi/qmp/qint.h"
>  #include "qom/qom-qobject.h"
>  
> +#include "hw/boards.h"
> +
>  /* These are used to size the ACPI tables for -M pc-i440fx-1.7 and
>   * -M pc-i440fx-2.0.  Even if the actual amount of AML generated grows
>   * a little bit, there should be plenty of free space since the DSDT
> @@ -2598,6 +2601,77 @@ build_dmar_q35(GArray *table_data, GArray *linker)
>   "DMAR", table_data->len - dmar_start, 1, NULL, NULL);
>  }
>  
> +static void
> +build_amd_iommu(GArray *table_data, GArray *linker)
> +{
> +int iommu_start = table_data->len;
> +bool iommu_ambig;
> +
> +/* IVRS definition  - table header has an extra 2-byte field */
> +acpi_data_push(table_data, (sizeof(acpi_table_header) - 2));

why won't build_header overwrite the extra fields?
Even if not, that's too hacky. Pls find another way to do this.

> +/* common virtualization information */
> +build_append_int_noprefix(table_data, AMD_IOMMU_HOST_ADDRESS_WIDTH << 8, 
> 4);
> +/* reserved */
> +build_append_int_noprefix(table_data, 0, 8);
> +
> +AMDIOMMUState *s = (AMDIOMMUState *)object_resolve_path_type("",
> +TYPE_AMD_IOMMU_DEVICE, &iommu_ambig);
> +
> +/* IVDB definition - type 10h */
> +if (!iommu_ambig) {
> +/* IVHD definition - type 10h */
> +build_append_int_noprefix(table_data, 0x10, 1);
> +/* virtualization flags */
> +build_append_int_noprefix(table_data, (IVHD_HT_TUNEN |
> + IVHD_PPRSUP | IVHD_IOTLBSUP | IVHD_PREFSUP), 1);
> +/* ivhd length */
> +build_append_int_noprefix(table_data, 0x20, 2);
> +/* iommu device id */
> +build_append_int_noprefix(table_data, PCI_DEVICE_ID_RD890_IOMMU, 2);
> +/* offset of capability registers */
> +build_append_int_noprefix(table_data, s->capab_offset, 2);
> +/* mmio base register */
> +build_append_int_noprefix(table_data, s->mmio.addr, 8);
> +/* pci segment */
> +build_append_int_noprefix(table_data, 0, 2);
> +/* interrupt numbers */
> +build_append_int_noprefix(table_data, 0, 2);
> +/* feature reporting */
> +build_append_int_noprefix(table_data, (IVHD_EFR_GTSUP |
> +IVHD_EFR_HATS | IVHD_EFR_GATS), 4);
> +/* Add device flags he

Re: [Qemu-devel] [V9 0/4] AMD IOMMU

[Michael S. Tsirkin]

On Sat, Apr 30, 2016 at 01:42:39AM +0300, David Kiarie wrote:
> These series adds AMD IOMMU support to Qemu. It's currently in the 9th 
> version.
> 
> In this series I have (hopefully) addressed all the comments made in the 
> previous version.

changelog?

> I have also tested and successfully passed-through PCI device 'ac97' with 
> more devices to be tested.


A fundamental problem with AMD IOMMUs is that the VMM must write-protect
guest I/O page tables from the guest in order to intercept all guest
updates and propagate the updates to the shadow I/O page tables.

AMD manual says as much.

Until this is implemented, I think device assignment must be disabled
when AMD IOMMU is in use.


> 
> David Kiarie (4):
>   hw/i386: Introduce AMD IOMMU
>   hw/i386: ACPI table for AMD IOMMU
>   hw/core: Add AMD IOMMU to machine properties
>   hw/pci-host: Emulate AMD IOMMU
> 
>  hw/acpi/aml-build.c   |2 +-
>  hw/acpi/core.c|   13 -
>  hw/core/machine.c |   33 +-
>  hw/i386/Makefile.objs |1 +
>  hw/i386/acpi-build.c  |   93 ++-
>  hw/i386/amd_iommu.c   | 1426 
> +
>  hw/i386/amd_iommu.h   |  398 
>  hw/pci-host/q35.c |   25 +-
>  include/hw/acpi/acpi-defs.h   |   14 +
>  include/hw/acpi/acpi.h|   16 +
>  include/hw/acpi/aml-build.h   |1 +
>  include/hw/boards.h   |7 +
>  include/hw/i386/intel_iommu.h |1 +
>  include/hw/pci/pci.h  |2 +
>  qemu-options.hx   |7 +-
>  util/qemu-config.c|8 +-
>  16 files changed, 2012 insertions(+), 35 deletions(-)
>  create mode 100644 hw/i386/amd_iommu.c
>  create mode 100644 hw/i386/amd_iommu.h
> 
> -- 
> 2.1.4

Re: [Qemu-devel] [V9 0/4] AMD IOMMU

[Michael S. Tsirkin]

On Sun, May 01, 2016 at 04:47:44PM +0300, Michael S. Tsirkin wrote:
> On Sat, Apr 30, 2016 at 01:42:39AM +0300, David Kiarie wrote:
> > These series adds AMD IOMMU support to Qemu. It's currently in the 9th 
> > version.
> > 
> > In this series I have (hopefully) addressed all the comments made in the 
> > previous version.
> 
> changelog?
> 
> > I have also tested and successfully passed-through PCI device 'ac97' with 
> > more devices to be tested.
> 
> 
> A fundamental problem with AMD IOMMUs is that the VMM must write-protect
> guest I/O page tables from the guest in order to intercept all guest
> updates and propagate the updates to the shadow I/O page tables.
> 
> AMD manual says as much.

Actually while it says so, it's wrong.
There's an NPcache flag which makes guest to invalidations
for invalid to valid transitions.

> Until this is implemented, I think device assignment must be disabled
> when AMD IOMMU is in use.

So I take this back. I would, however, like to see how this
interacts with Aviv's patches enabling VFIO support for IOMMU.

> 
> > 
> > David Kiarie (4):
> >   hw/i386: Introduce AMD IOMMU
> >   hw/i386: ACPI table for AMD IOMMU
> >   hw/core: Add AMD IOMMU to machine properties
> >   hw/pci-host: Emulate AMD IOMMU
> > 
> >  hw/acpi/aml-build.c   |2 +-
> >  hw/acpi/core.c|   13 -
> >  hw/core/machine.c |   33 +-
> >  hw/i386/Makefile.objs |1 +
> >  hw/i386/acpi-build.c  |   93 ++-
> >  hw/i386/amd_iommu.c   | 1426 
> > +
> >  hw/i386/amd_iommu.h   |  398 
> >  hw/pci-host/q35.c |   25 +-
> >  include/hw/acpi/acpi-defs.h   |   14 +
> >  include/hw/acpi/acpi.h|   16 +
> >  include/hw/acpi/aml-build.h   |1 +
> >  include/hw/boards.h   |7 +
> >  include/hw/i386/intel_iommu.h |1 +
> >  include/hw/pci/pci.h  |2 +
> >  qemu-options.hx   |7 +-
> >  util/qemu-config.c|8 +-
> >  16 files changed, 2012 insertions(+), 35 deletions(-)
> >  create mode 100644 hw/i386/amd_iommu.c
> >  create mode 100644 hw/i386/amd_iommu.h
> > 
> > -- 
> > 2.1.4

Re: [Qemu-devel] [V9 1/4] hw/i386: Introduce AMD IOMMU

[Michael S. Tsirkin]

On Sat, Apr 30, 2016 at 01:42:40AM +0300, David Kiarie wrote:
> Add AMD IOMMU emulaton to Qemu in addition to Intel IOMMU
> The IOMMU does basic translation, error checking and has a
> minimal IOTLB implementation
> 
> Signed-off-by: David Kiarie 
> ---
>  hw/i386/Makefile.objs |1 +
>  hw/i386/amd_iommu.c   | 1426 
> +
>  hw/i386/amd_iommu.h   |  398 ++
>  include/hw/pci/pci.h  |2 +
>  4 files changed, 1827 insertions(+)
>  create mode 100644 hw/i386/amd_iommu.c
>  create mode 100644 hw/i386/amd_iommu.h
> 
> diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
> index b52d5b8..2f1a265 100644
> --- a/hw/i386/Makefile.objs
> +++ b/hw/i386/Makefile.objs
> @@ -3,6 +3,7 @@ obj-y += multiboot.o
>  obj-y += pc.o pc_piix.o pc_q35.o
>  obj-y += pc_sysfw.o
>  obj-y += intel_iommu.o
> +obj-y += amd_iommu.o
>  obj-$(CONFIG_XEN) += ../xenpv/ xen/
>  
>  obj-y += kvmvapic.o
> diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
> new file mode 100644
> index 000..eea4fac
> --- /dev/null
> +++ b/hw/i386/amd_iommu.c
> @@ -0,0 +1,1426 @@
> +/*
> + * QEMU emulation of AMD IOMMU (AMD-Vi)
> + *
> + * Copyright (C) 2011 Eduard - Gabriel Munteanu
> + * Copyright (C) 2015 David Kiarie, 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> +
> + * This program 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 General Public License for more details.
> +
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, see .
> + *
> + * Cache implementation inspired by hw/i386/intel_iommu.c
> + *
> + */
> +#include "qemu/osdep.h"
> +#include "hw/i386/amd_iommu.h"
> +
> +//#define DEBUG_AMD_IOMMU
> +#ifdef DEBUG_AMD_IOMMU
> +enum {
> +DEBUG_GENERAL, DEBUG_CAPAB, DEBUG_MMIO, DEBUG_ELOG,
> +DEBUG_CACHE, DEBUG_COMMAND, DEBUG_MMU, DEBUG_CUSTOM
> +};
> +
> +#define IOMMU_DBGBIT(x)   (1 << DEBUG_##x)
> +static int iommu_dbgflags = IOMMU_DBGBIT(CUSTOM) | IOMMU_DBGBIT(MMIO);
> +
> +#define IOMMU_DPRINTF(what, fmt, ...) do { \
> +if (iommu_dbgflags & IOMMU_DBGBIT(what)) { \
> +fprintf(stderr, "(amd-iommu)%s: " fmt "\n", __func__, \
> +## __VA_ARGS__); } \
> +} while (0)
> +#else
> +#define IOMMU_DPRINTF(what, fmt, ...) do {} while (0)
> +#endif
> +
> +#define ENCODE_EVENT(devid, info, addr, rshift) do { \
> +*(uint16_t *)&evt[0] = devid; \
> +*(uint8_t *)&evt[3]  = info;  \
> +*(uint64_t *)&evt[4] = rshift ? cpu_to_le64(addr) :\
> +   cpu_to_le64(addr) >> rshift; \
> +} while (0)
> +
> +typedef struct AMDIOMMUAddressSpace {
> +uint8_t bus_num;/* bus number   */
> +uint8_t devfn;  /* device function  */
> +AMDIOMMUState *iommu_state; /* IOMMU - one per machine  */
> +MemoryRegion iommu; /* Device's iommu region*/
> +AddressSpace as;/* device's corresponding address space */
> +} AMDIOMMUAddressSpace;
> +
> +/* IOMMU cache entry */
> +typedef struct IOMMUIOTLBEntry {
> +uint64_t gfn;
> +uint16_t domid;
> +uint64_t devid;
> +uint64_t perms;
> +uint64_t translated_addr;
> +} IOMMUIOTLBEntry;
> +
> +/* configure MMIO registers at startup/reset */
> +static void amd_iommu_set_quad(AMDIOMMUState *s, hwaddr addr, uint64_t val,
> +   uint64_t romask, uint64_t w1cmask)
> +{
> +stq_le_p(&s->mmior[addr], val);
> +stq_le_p(&s->romask[addr], romask);
> +stq_le_p(&s->w1cmask[addr], w1cmask);
> +}
> +
> +static uint16_t amd_iommu_readw(AMDIOMMUState *s, hwaddr addr)
> +{
> +return lduw_le_p(&s->mmior[addr]);
> +}
> +
> +static uint32_t amd_iommu_readl(AMDIOMMUState *s, hwaddr addr)
> +{
> +return ldl_le_p(&s->mmior[addr]);
> +}
> +
> +static uint64_t amd_iommu_readq(AMDIOMMUState *s, hwaddr addr)
> +{
> +return ldq_le_p(&s->mmior[addr]);
> +}
> +
> +/* internal write */
> +static void amd_iommu_writeq_raw(AMDIOMMUState *s, uint64_t val, hwaddr addr)
> +{
> +stq_le_p(&s->mmior[addr], val);
> +}
> +
> +/* external write */
> +static void amd_iommu_writew(AMDIOMMUState *s, hwaddr addr, uint16_t val)
> +{
> +uint16_t romask = lduw_le_p(&s->romask[addr]);
> +uint16_t w1cmask = lduw_le_p(&s->w1cmask[addr]);
> +uint16_t oldval = lduw_le_p(&s->mmior[addr]);
> +stw_le_p(&s->mmior[addr], (val & ~(val & w1cmask)) | (romask & oldval));
> +}
> +
> +static void amd_iommu_writel(AMDIOMMUState *s, hwaddr addr, uint32_t val)
> +{
> +uint32

Re: [Qemu-devel] [PATCH 11/18] vhost-user: add shutdown support

[Yuanhan Liu]

On Sun, May 01, 2016 at 02:37:19PM +0300, Michael S. Tsirkin wrote:
> On Fri, Apr 29, 2016 at 10:48:35AM -0700, Yuanhan Liu wrote:
> > > But, I
> > > would worry first about a backend that crashes that it may corrupt the
> > > VM memory too...
> > 
> > Not quite sure I follow this. But, backend just touches the virtio
> > related memory, so it will do no harm to the VM?
> 
> It crashed so apparently it's not behaving as designed -
> how can we be sure it does not harm the VM?

Hi Michael,

What I know so far, a crash might could corrupt the virtio memory in two
ways:

- vring_used_elem might be in stale state when we are in the middle of
  updating used vring. Say, we might have updated the "id" field, but
  leaving "len" untouched.

- vring desc buff might also be in stale state, when we are copying
  data into it.

However, the two issues will not be real issue, as used->idx is not
updated in both case. Thefore, those corrupted memory will not be
processed by guest. So, no harm I'd say. Or, am I missing anything?

BTW, Michael, what's your thoughts on the whole reconnect stuff?

--yliu

[Qemu-devel] [PATCH] fixup! tcg/mips: Make direct jump patching thread-safe

[Sergey Fedorov]

From: Sergey Fedorov 

Signed-off-by: Sergey Fedorov 
Signed-off-by: Sergey Fedorov 
---

 tcg/mips/tcg-target.inc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tcg/mips/tcg-target.inc.c b/tcg/mips/tcg-target.inc.c
index b0440b9c5a79..b514cd7114d2 100644
--- a/tcg/mips/tcg-target.inc.c
+++ b/tcg/mips/tcg-target.inc.c
@@ -1885,6 +1885,6 @@ static void tcg_target_init(TCGContext *s)
 
 void tb_set_jmp_target1(uintptr_t jmp_addr, uintptr_t addr)
 {
-atomic_set(ptr, deposit32(OPC_J, 0, 26, addr >> 2));
+atomic_set(jmp_addr, deposit32(OPC_J, 0, 26, addr >> 2));
 flush_icache_range(jmp_addr, jmp_addr + 4);
 }
-- 
1.9.1