[Qemu-devel] install windows, csm in montherboard turned off
Hello. I tried to install windows on a qemu img and got this error: Windows boot manager Windows failed to start. A recent hardware or software change might be the cause. To fix the problem: 1. Insert windows installation cd and restart you computer 2. ... Status: 0xc017 Ramdisk device creation failed due to insufficient memory. This is how I did it (and got the error from above): qemu-img create windows 15G qemu-system-x86_64 -cdrom ~/Desktop/Windows\ 7\ SP1\ Ultimate\ \(64\ Bit\)/Windows\ 7\ SP1\ Ultimate\ \(64\ Bit\).iso -boot order=d windows I'm using a UEFI dual boot and in the process of installing my OSs (arch and windows ) I swtiched off csm. Might that be the problem? So why am I getting this error? Am I making some error in the way I boot the windows image? Or maybe it has something to do with me turning off csm in the motherboard Thanks in advance.
Re: [Qemu-devel] install windows, csm in montherboard turned off
On Sun, Nov 23, 2014 at 2:57 AM, jenia.ivlev jenia.iv...@gmail.com wrote: I tried to install windows on a qemu img and got this error: ... Ramdisk device creation failed due to insufficient memory. This is how I did it (and got the error from above): qemu-img create windows 15G qemu-system-x86_64 -cdrom ~/Desktop/Windows\ 7\ SP1\ Ultimate\ \(64\ Bit\)/Windows\ 7\ SP1\ Ultimate\ \(64\ Bit\).iso -boot order=d windows ... So why am I getting this error? Maybe because the default amount of RAM is too small? Try adding -m memory size option to your qemu-system-x86_64 command line. -- Thanks. -- Max
Re: [Qemu-devel] [v5][PATCH 0/4] xen: introduce new machine for IGD passthrough
On Tue, Aug 12, 2014 at 05:49:13PM +0800, Tiejun Chen wrote: v5: * Simplify to make sure its really inherited from the standard one in patch #3 * Then drop the original patch #3 I carried i440fx: make types configurable at run-time pc_init1: pass parameters just with types xen:hw:pci-host:piix: create host bridge to passthrough qom-test: blacklist xenigd xen:hw:i386:pc_piix: introduce new machine for IGD passthrough on my branch for a while now, but I'm not sure it's all still needed. If yes simply include these patches next time you repost the patchset. -- MST
Re: [Qemu-devel] [RFA] Always consider infcall breakpoints as non-permanent.
And seen from QEMU:
qemu: fatal: Trap 0x02 while interrupts disabled, Error state
[register dump removed]
Bah. Do you know whether this happens only on SPARC QEMU, or
is this an issue for all QEMU ports?
According to Fabien, one of our QEMU experts, it's related to the
handling of that specific instruction: it does what the manual says
it should do - when interrupts are disables, the CPU resets. So
while it does not preclude from other ports from having the same
sort of issue, it looks like it's mostly target-specific.
gdb/ChangeLog:
* breakpoint.c (bp_loc_is_permanent): Return 0 if LOC corresponds
to a bp_call_dummy breakpoint type.
Patch is OK. Thanks Joel.
Thank you. Attached is the patch I checked in with the corrections
you pointed out.
Thanks, Pedro.
--
Joel
From e8af5d7a5cd4c58136a4733e87612f49061bf28b Mon Sep 17 00:00:00 2001
From: Joel Brobecker brobec...@adacore.com
Date: Thu, 20 Nov 2014 20:41:25 +0400
Subject: [PATCH] Always consider infcall breakpoints as non-permanent.
A recent change...
commit 1a853c5224e2b8fedfac6d029365522b83080b40
Date: Wed Nov 12 10:10:49 2014 +
Subject: make permanent breakpoints per location and disableable
... broke function calls on sparc-elf when running over QEMU. Any
function call should demonstrate the problem.
For instance, seen from the debugger:
(gdb) call pn(1234)
[Inferior 1 (Remote target) exited normally]
The program being debugged exited while in a function called from GDB.
Evaluation of the expression containing the function
And seen from QEMU:
qemu: fatal: Trap 0x02 while interrupts disabled, Error state
[register dump removed]
What happens in this case is that GDB sets the inferior function call
by not only creating the dummy frame, but also writing a breakpoint
instruction at the return address for our function call. See infcall.c:
/* Write a legitimate instruction at the point where the infcall
breakpoint is going to be inserted. While this instruction
is never going to be executed, a user investigating the
memory from GDB would see this instruction instead of random
uninitialized bytes. We chose the breakpoint instruction
as it may look as the most logical one to the user and also
valgrind 3.7.0 needs it for proper vgdb inferior calls.
If software breakpoints are unsupported for this target we
leave the user visible memory content uninitialized. */
bp_addr_as_address = bp_addr;
bp_bytes = gdbarch_breakpoint_from_pc (gdbarch, bp_addr_as_address,
bp_size);
if (bp_bytes != NULL)
write_memory (bp_addr_as_address, bp_bytes, bp_size);
This instruction triggers a change introduced by the commit above,
where we consider bp locations as being permanent breakpoints
if there is already a breakpoint instruction at that address:
+ if (bp_loc_is_permanent (loc))
+{
+ loc-inserted = 1;
+ loc-permanent = 1;
+}
As a result, when resuming the program's execution for the inferior
function call, GDB decides that it does not need to insert a breakpoint
at this address, expecting the target to just report a SIGTRAP when
trying to execute that instruction.
But unfortunately for us, at least some versions of QEMU for SPARC
just terminate the execution entirely instead of reporting a breakpoint,
thus producing the behavior reported here.
Although it appears like QEMU might be misbehaving and should therefore
be fixed (to be verified) from the user's point of view, the recent
change does introduce a regression. So this patch tries to mitigate
a bit the damage by handling such infcall breakpoints as special and
making sure that they are never considered permanent, thus restoring
the previous behavior specifically for those breakpoints.
The option of not writing the breakpoint instructions in the first
place was considered, and would probably work also. But the comment
associated to it seems to indicate that there is still reason to
keep it.
gdb/ChangeLog:
* breakpoint.c (bp_loc_is_permanent): Return 0 if LOC corresponds
to a bp_call_dummy breakpoint type.
Tested on x86_64-linux. Also testing on sparc-elf/QEMU using
AdaCore's testsuite.
---
gdb/ChangeLog| 5 +
gdb/breakpoint.c | 14 ++
2 files changed, 19 insertions(+)
diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 45435fc..4e8284e 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,8 @@
+2014-11-23 Joel Brobecker brobec...@adacore.com
+
+ * breakpoint.c (bp_loc_is_permanent): Return 0 if LOC corresponds
+ to a bp_call_dummy breakpoint type.
+
2014-11-23 Patrick Palka patr...@parcs.ath.cx
* tui/tui-win.c (tui_initialize_win): Specify SA_RESTART when
diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c
index 7b56260..574d06c
[Qemu-devel] [PULL 01/15] qemu-char: fix tcp_get_fds
tcp_get_fds API discards fds if there's more than 1 of these.
It's tricky to fix this without API changes in the generic case.
However, this API is only used by tests ATM, and tests know how
many fds they expect.
So let's not waste cycles trying to fix this properly:
simply assume at most 16 fds (tests use at most 8 now).
assert if some test tries to get more.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
qemu-char.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/qemu-char.c b/qemu-char.c
index 4a76f0f..a8b01da 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -88,6 +88,7 @@
#define READ_BUF_LEN 4096
#define READ_RETRIES 10
#define CHR_MAX_FILENAME_SIZE 256
+#define TCP_MAX_FDS 16
/***/
/* Socket address helpers */
@@ -2668,6 +2669,8 @@ static int tcp_get_msgfds(CharDriverState *chr, int *fds,
int num)
TCPCharDriver *s = chr-opaque;
int to_copy = (s-read_msgfds_num num) ? s-read_msgfds_num : num;
+assert(num = TCP_MAX_FDS);
+
if (to_copy) {
int i;
@@ -2762,7 +2765,7 @@ static ssize_t tcp_chr_recv(CharDriverState *chr, char
*buf, size_t len)
struct iovec iov[1];
union {
struct cmsghdr cmsg;
-char control[CMSG_SPACE(sizeof(int))];
+char control[CMSG_SPACE(sizeof(int) * TCP_MAX_FDS)];
} msg_control;
int flags = 0;
ssize_t ret;
--
MST
[Qemu-devel] [PULL 00/15] pc, pci, misc bugfixes
The following changes since commit 0e88f478508b566152c6681f4889ed9830a2c0a5: Merge remote-tracking branch 'remotes/stefanha/tags/net-pull-request' into staging (2014-11-21 14:15:37 +) 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 71edf5afdb320c17b28d88d848b571e2701c79b8: pc: acpi: mark all possible CPUs as enabled in SRAT (2014-11-23 12:12:47 +0200) pc, pci, misc bugfixes A bunch of bugfixes for 2.2. Signed-off-by: Michael S. Tsirkin m...@redhat.com Gonglei (2): pcie: fix typo in pcie_cap_deverr_init() pcie: fix improper use of negative value Igor Mammedov (9): pc: kvm: check if KVM has free memory slots to avoid abort() pc: make pc_dimm_plug() more readble pc: limit DIMM address and size to page aligned values memory: expose alignment used for allocating RAM as MemoryRegion API pc: align DIMM's address/size by backend's alignment value pc: pc-dimm: use backend alignment during address auto allocation pc: explicitly check maxmem limit when adding DIMM pc: count in 1Gb hugepage alignment when sizing hotplug-memory container pc: acpi: mark all possible CPUs as enabled in SRAT Marcel Apfelbaum (1): hw/pci: fix crash on shpc error flow Michael S. Tsirkin (2): qemu-char: fix tcp_get_fds acpi-build: mark RAM dirty on table update Paolo Bonzini (1): target-i386: move generic memory hotplug methods to DSDTs include/exec/exec-all.h | 2 +- include/exec/memory.h | 2 + include/hw/i386/pc.h| 4 + include/hw/loader.h | 2 +- include/hw/mem/pc-dimm.h| 2 +- include/qemu/osdep.h| 3 +- include/sysemu/kvm.h| 1 + exec.c | 9 +- hw/core/loader.c| 8 +- hw/i386/acpi-build.c| 22 +- hw/i386/pc.c| 80 +++- hw/i386/pc_piix.c | 2 + hw/i386/pc_q35.c| 3 + hw/mem/pc-dimm.c| 19 +- hw/pci/pcie.c | 4 +- hw/pci/shpc.c | 1 + kvm-all.c | 18 +- kvm-stub.c | 5 + memory.c| 5 + qemu-char.c | 5 +- target-s390x/kvm.c | 2 +- util/oslib-posix.c | 5 +- util/oslib-win32.c | 2 +- hw/i386/acpi-dsdt-mem-hotplug.dsl | 176 hw/i386/acpi-dsdt.dsl | 3 +- hw/i386/acpi-dsdt.hex.generated | 795 +- hw/i386/q35-acpi-dsdt.dsl | 3 +- hw/i386/q35-acpi-dsdt.hex.generated | 797 +- hw/i386/ssdt-mem.hex.generated | 8 +- hw/i386/ssdt-misc.dsl | 165 +-- hw/i386/ssdt-misc.hex.generated | 834 ++-- tests/acpi-test-data/pc/DSDT| Bin 2807 - 3592 bytes tests/acpi-test-data/pc/SSDT| Bin 3065 - 2279 bytes tests/acpi-test-data/q35/DSDT | Bin 7397 - 8182 bytes tests/acpi-test-data/q35/SSDT | Bin 1346 - 560 bytes 35 files changed, 1962 insertions(+), 1025 deletions(-) create mode 100644 hw/i386/acpi-dsdt-mem-hotplug.dsl
[Qemu-devel] [PULL 06/15] pc: align DIMM's address/size by backend's alignment value
From: Igor Mammedov imamm...@redhat.com
Performance wise it's better to align GVA by the backend's
page size.
Also do not allow to create DIMM device with suboptimal
size (i.e. not aligned to backends page size) to aviod
memory loss.
Do above only for 2.2 and newer machine types to avoid
breaking working configs with 2.1 machine type.
Signed-off-by: Igor Mammedov imamm...@redhat.com
Reviewed-by: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
include/hw/i386/pc.h | 4
hw/i386/pc.c | 17 +
hw/i386/pc_piix.c| 2 ++
hw/i386/pc_q35.c | 3 +++
4 files changed, 26 insertions(+)
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 7c3731f..9d85b89 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -24,6 +24,8 @@
* address space begins.
* @hotplug_memory: hotplug memory addess space container
* @acpi_dev: link to ACPI PM device that performs ACPI hotplug handling
+ * @enforce_aligned_dimm: check that DIMM's address/size is aligned by
+ *backend's alignment value if provided
*/
struct PCMachineState {
/* private */
@@ -38,12 +40,14 @@ struct PCMachineState {
uint64_t max_ram_below_4g;
bool vmport;
+bool enforce_aligned_dimm;
};
#define PC_MACHINE_ACPI_DEVICE_PROP acpi-device
#define PC_MACHINE_MEMHP_REGION_SIZE hotplug-memory-region-size
#define PC_MACHINE_MAX_RAM_BELOW_4G max-ram-below-4g
#define PC_MACHINE_VMPORT vmport
+#define PC_MACHINE_ENFORCE_ALIGNED_DIMM enforce-aligned-dimm
/**
* PCMachineClass:
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 33928b9..021ec44 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1564,6 +1564,10 @@ static void pc_dimm_plug(HotplugHandler *hotplug_dev,
goto out;
}
+if (memory_region_get_alignment(mr) pcms-enforce_aligned_dimm) {
+align = memory_region_get_alignment(mr);
+}
+
addr = pc_dimm_get_free_addr(pcms-hotplug_memory_base,
memory_region_size(pcms-hotplug_memory),
!addr ? NULL : addr, align,
@@ -1732,6 +1736,13 @@ static void pc_machine_set_vmport(Object *obj, bool
value, Error **errp)
pcms-vmport = value;
}
+static bool pc_machine_get_aligned_dimm(Object *obj, Error **errp)
+{
+PCMachineState *pcms = PC_MACHINE(obj);
+
+return pcms-enforce_aligned_dimm;
+}
+
static void pc_machine_initfn(Object *obj)
{
PCMachineState *pcms = PC_MACHINE(obj);
@@ -1744,11 +1755,17 @@ static void pc_machine_initfn(Object *obj)
pc_machine_get_max_ram_below_4g,
pc_machine_set_max_ram_below_4g,
NULL, NULL, NULL);
+
pcms-vmport = !xen_enabled();
object_property_add_bool(obj, PC_MACHINE_VMPORT,
pc_machine_get_vmport,
pc_machine_set_vmport,
NULL);
+
+pcms-enforce_aligned_dimm = true;
+object_property_add_bool(obj, PC_MACHINE_ENFORCE_ALIGNED_DIMM,
+ pc_machine_get_aligned_dimm,
+ NULL, NULL);
}
static void pc_machine_class_init(ObjectClass *oc, void *data)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 7bb97a4..741dffd 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -305,10 +305,12 @@ static void pc_init_pci(MachineState *machine)
static void pc_compat_2_1(MachineState *machine)
{
+PCMachineState *pcms = PC_MACHINE(machine);
smbios_uuid_encoded = false;
x86_cpu_compat_set_features(coreduo, FEAT_1_ECX, CPUID_EXT_VMX, 0);
x86_cpu_compat_set_features(core2duo, FEAT_1_ECX, CPUID_EXT_VMX, 0);
x86_cpu_compat_kvm_no_autodisable(FEAT_8000_0001_ECX, CPUID_EXT3_SVM);
+pcms-enforce_aligned_dimm = false;
}
static void pc_compat_2_0(MachineState *machine)
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 598e679..e9ba1a2 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -284,6 +284,9 @@ static void pc_q35_init(MachineState *machine)
static void pc_compat_2_1(MachineState *machine)
{
+PCMachineState *pcms = PC_MACHINE(machine);
+
+pcms-enforce_aligned_dimm = false;
smbios_uuid_encoded = false;
x86_cpu_compat_set_features(coreduo, FEAT_1_ECX, CPUID_EXT_VMX, 0);
x86_cpu_compat_set_features(core2duo, FEAT_1_ECX, CPUID_EXT_VMX, 0);
--
MST
[Qemu-devel] [PULL 03/15] pc: make pc_dimm_plug() more readble
From: Igor Mammedov imamm...@redhat.com
split addr initialization from declaration so that
later when new local vars are added property getter
wouldn't drift off of error check.
Signed-off-by: Igor Mammedov imamm...@redhat.com
Reviewed-by: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
hw/i386/pc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index ce7b752..70ae3cf 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1556,8 +1556,9 @@ static void pc_dimm_plug(HotplugHandler *hotplug_dev,
PCDIMMDevice *dimm = PC_DIMM(dev);
PCDIMMDeviceClass *ddc = PC_DIMM_GET_CLASS(dimm);
MemoryRegion *mr = ddc-get_memory_region(dimm);
-uint64_t addr = object_property_get_int(OBJECT(dimm), PC_DIMM_ADDR_PROP,
-local_err);
+uint64_t addr;
+
+addr = object_property_get_int(OBJECT(dimm), PC_DIMM_ADDR_PROP,
local_err);
if (local_err) {
goto out;
}
--
MST
[Qemu-devel] [PULL 02/15] pc: kvm: check if KVM has free memory slots to avoid abort()
From: Igor Mammedov imamm...@redhat.com
When more memory devices are used than available
KVM memory slots, QEMU crashes with:
kvm_alloc_slot: no free slot available
Aborted (core dumped)
Fix this by checking that KVM has a free slot before
attempting to map memory in guest address space.
Signed-off-by: Igor Mammedov imamm...@redhat.com
Acked-by: Paolo Bonzini pbonz...@redhat.com
Reviewed-by: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
include/sysemu/kvm.h | 1 +
hw/i386/pc.c | 5 +
kvm-all.c| 18 +-
kvm-stub.c | 5 +
4 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index b0cd657..22e42ef 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -163,6 +163,7 @@ extern KVMState *kvm_state;
/* external API */
+bool kvm_has_free_slot(MachineState *ms);
int kvm_has_sync_mmu(void);
int kvm_has_vcpu_events(void);
int kvm_has_robust_singlestep(void);
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 1205db8..ce7b752 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1598,6 +1598,11 @@ static void pc_dimm_plug(HotplugHandler *hotplug_dev,
goto out;
}
+if (kvm_enabled() !kvm_has_free_slot(machine)) {
+error_setg(local_err, hypervisor has no free memory slots left);
+goto out;
+}
+
memory_region_add_subregion(pcms-hotplug_memory,
addr - pcms-hotplug_memory_base, mr);
vmstate_register_ram(mr, dev);
diff --git a/kvm-all.c b/kvm-all.c
index 596e7ce..937bc9d 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -132,7 +132,7 @@ static const KVMCapabilityInfo kvm_required_capabilites[] =
{
KVM_CAP_LAST_INFO
};
-static KVMSlot *kvm_alloc_slot(KVMState *s)
+static KVMSlot *kvm_get_free_slot(KVMState *s)
{
int i;
@@ -142,6 +142,22 @@ static KVMSlot *kvm_alloc_slot(KVMState *s)
}
}
+return NULL;
+}
+
+bool kvm_has_free_slot(MachineState *ms)
+{
+return kvm_get_free_slot(KVM_STATE(ms-accelerator));
+}
+
+static KVMSlot *kvm_alloc_slot(KVMState *s)
+{
+KVMSlot *slot = kvm_get_free_slot(s);
+
+if (slot) {
+return slot;
+}
+
fprintf(stderr, %s: no free slot available\n, __func__);
abort();
}
diff --git a/kvm-stub.c b/kvm-stub.c
index 43fc0dd..7ba90c5 100644
--- a/kvm-stub.c
+++ b/kvm-stub.c
@@ -147,4 +147,9 @@ int kvm_irqchip_remove_irqfd_notifier(KVMState *s,
EventNotifier *n, int virq)
{
return -ENOSYS;
}
+
+bool kvm_has_free_slot(MachineState *ms)
+{
+return false;
+}
#endif
--
MST
[Qemu-devel] [PULL 09/15] pc: count in 1Gb hugepage alignment when sizing hotplug-memory container
From: Igor Mammedov imamm...@redhat.com
if DIMMs with different size/alignment are interleaved
in creation order, it could lead to hotplug-memory
container fragmentation and following inability to use
all RAM upto maxmem.
For example:
-m 4G,slots=3,maxmem=7G
-object memory-backend-file,id=mem-1,size=256M,mem-path=/pagesize-2MB
-device pc-dimm,id=mem1,memdev=mem-1
-object memory-backend-file,id=mem-2,size=1G,mem-path=/pagesize-1GB
-device pc-dimm,id=mem2,memdev=mem-2
-object memory-backend-file,id=mem-3,size=256M,mem-path=/pagesize-2MB
-device pc-dimm,id=mem3,memdev=mem-3
fragments hotplug-memory container and doesn't allow
to use 1GB hugepage backend to consume remainig 1Gb.
To ease managment factor count in max 1Gb alignment for
each memory slot when sizing hotplug-memory region so
that regadless of fragmentaion it would be possible to
add max aligned DIMM.
Signed-off-by: Igor Mammedov imamm...@redhat.com
Reviewed-by: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
hw/i386/pc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index d448d0d..e656658 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1247,6 +1247,11 @@ FWCfgState *pc_memory_init(MachineState *machine,
pcms-hotplug_memory_base =
ROUND_UP(0x1ULL + above_4g_mem_size, 1ULL 30);
+if (pcms-enforce_aligned_dimm) {
+/* size hotplug region assuming 1G page max alignment per slot */
+hotplug_mem_size += (1ULL 30) * machine-ram_slots;
+}
+
if ((pcms-hotplug_memory_base + hotplug_mem_size)
hotplug_mem_size) {
error_report(unsupported amount of maximum memory: RAM_ADDR_FMT,
--
MST
[Qemu-devel] [PULL 05/15] memory: expose alignment used for allocating RAM as MemoryRegion API
From: Igor Mammedov imamm...@redhat.com
introduce memory_region_get_alignment() that returns
underlying memory block alignment or 0 if it's not
relevant/implemented for backend.
Signed-off-by: Igor Mammedov imamm...@redhat.com
Reviewed-by: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
include/exec/exec-all.h | 2 +-
include/exec/memory.h | 2 ++
include/qemu/osdep.h| 3 ++-
exec.c | 9 ++---
memory.c| 5 +
target-s390x/kvm.c | 2 +-
util/oslib-posix.c | 5 -
util/oslib-win32.c | 2 +-
8 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h
index 421a142..0844885 100644
--- a/include/exec/exec-all.h
+++ b/include/exec/exec-all.h
@@ -333,7 +333,7 @@ extern uintptr_t tci_tb_ptr;
#if !defined(CONFIG_USER_ONLY)
-void phys_mem_set_alloc(void *(*alloc)(size_t));
+void phys_mem_set_alloc(void *(*alloc)(size_t, uint64_t *align));
struct MemoryRegion *iotlb_to_region(AddressSpace *as, hwaddr index);
bool io_mem_read(struct MemoryRegion *mr, hwaddr addr,
diff --git a/include/exec/memory.h b/include/exec/memory.h
index 74a58b4..f64ab5e 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -146,6 +146,7 @@ struct MemoryRegion {
hwaddr addr;
void (*destructor)(MemoryRegion *mr);
ram_addr_t ram_addr;
+uint64_t align;
bool subpage;
bool terminates;
bool romd_mode;
@@ -838,6 +839,7 @@ void memory_region_add_subregion_overlap(MemoryRegion *mr,
*/
ram_addr_t memory_region_get_ram_addr(MemoryRegion *mr);
+uint64_t memory_region_get_alignment(const MemoryRegion *mr);
/**
* memory_region_del_subregion: Remove a subregion.
*
diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
index c032434..b3300cc 100644
--- a/include/qemu/osdep.h
+++ b/include/qemu/osdep.h
@@ -5,6 +5,7 @@
#include stdarg.h
#include stddef.h
#include stdbool.h
+#include stdint.h
#include sys/types.h
#ifdef __OpenBSD__
#include sys/signal.h
@@ -103,7 +104,7 @@ typedef signed int int_fast16_t;
int qemu_daemon(int nochdir, int noclose);
void *qemu_try_memalign(size_t alignment, size_t size);
void *qemu_memalign(size_t alignment, size_t size);
-void *qemu_anon_ram_alloc(size_t size);
+void *qemu_anon_ram_alloc(size_t size, uint64_t *align);
void qemu_vfree(void *ptr);
void qemu_anon_ram_free(void *ptr, size_t size);
diff --git a/exec.c b/exec.c
index f0e2bd3..71ac104 100644
--- a/exec.c
+++ b/exec.c
@@ -909,14 +909,15 @@ static int subpage_register (subpage_t *mmio, uint32_t
start, uint32_t end,
uint16_t section);
static subpage_t *subpage_init(AddressSpace *as, hwaddr base);
-static void *(*phys_mem_alloc)(size_t size) = qemu_anon_ram_alloc;
+static void *(*phys_mem_alloc)(size_t size, uint64_t *align) =
+ qemu_anon_ram_alloc;
/*
* Set a custom physical guest memory alloator.
* Accelerators with unusual needs may need this. Hopefully, we can
* get rid of it eventually.
*/
-void phys_mem_set_alloc(void *(*alloc)(size_t))
+void phys_mem_set_alloc(void *(*alloc)(size_t, uint64_t *align))
{
phys_mem_alloc = alloc;
}
@@ -1098,6 +1099,7 @@ static void *file_ram_alloc(RAMBlock *block,
error_propagate(errp, local_err);
goto error;
}
+block-mr-align = hpagesize;
if (memory hpagesize) {
error_setg(errp, memory size 0x RAM_ADDR_FMT must be equal to
@@ -1309,7 +1311,8 @@ static ram_addr_t ram_block_add(RAMBlock *new_block,
Error **errp)
if (xen_enabled()) {
xen_ram_alloc(new_block-offset, new_block-length, new_block-mr);
} else {
-new_block-host = phys_mem_alloc(new_block-length);
+new_block-host = phys_mem_alloc(new_block-length,
+ new_block-mr-align);
if (!new_block-host) {
error_setg_errno(errp, errno,
cannot set up guest memory '%s',
diff --git a/memory.c b/memory.c
index 0f4fdc7..15cf9eb 100644
--- a/memory.c
+++ b/memory.c
@@ -1749,6 +1749,11 @@ ram_addr_t memory_region_get_ram_addr(MemoryRegion *mr)
return mr-ram_addr;
}
+uint64_t memory_region_get_alignment(const MemoryRegion *mr)
+{
+return mr-align;
+}
+
static int cmp_flatrange_addr(const void *addr_, const void *fr_)
{
const AddrRange *addr = addr_;
diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index d247471..50709ba 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -404,7 +404,7 @@ int kvm_arch_get_registers(CPUState *cs)
* to grow. We also have to use MAP parameters that avoid
* read-only mapping of guest pages.
*/
-static void *legacy_s390_alloc(size_t size)
+static void *legacy_s390_alloc(size_t size, , uint64_t *align)
{
void *mem;
diff --git a/util/oslib-posix.c b/util/oslib-posix.c
index 8c9d80e..16fcec2
[Qemu-devel] [PULL 04/15] pc: limit DIMM address and size to page aligned values
From: Igor Mammedov imamm...@redhat.com
When running in KVM mode, kvm_set_phys_mem() will silently
fail if registered MemoryRegion address/size is not page
aligned. Causing memory hotplug failure in guest.
Mapping non aligned MemoryRegion in TCG mode 'works', but
sane guest OS still expects page aligned memory module
and fails to initialize it if it's not aligned.
So do not allow non aligned (i.e. valid) address/size
values for DIMM to avoid either KVM failure or guest
issues caused by it.
Signed-off-by: Igor Mammedov imamm...@redhat.com
Reviewed-by: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
include/hw/mem/pc-dimm.h | 2 +-
hw/i386/pc.c | 3 ++-
hw/mem/pc-dimm.c | 14 +-
3 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/include/hw/mem/pc-dimm.h b/include/hw/mem/pc-dimm.h
index 761eeef..e1dcbbc 100644
--- a/include/hw/mem/pc-dimm.h
+++ b/include/hw/mem/pc-dimm.h
@@ -72,7 +72,7 @@ typedef struct PCDIMMDeviceClass {
uint64_t pc_dimm_get_free_addr(uint64_t address_space_start,
uint64_t address_space_size,
- uint64_t *hint, uint64_t size,
+ uint64_t *hint, uint64_t align, uint64_t size,
Error **errp);
int pc_dimm_get_free_slot(const int *hint, int max_slots, Error **errp);
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 70ae3cf..33928b9 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1556,6 +1556,7 @@ static void pc_dimm_plug(HotplugHandler *hotplug_dev,
PCDIMMDevice *dimm = PC_DIMM(dev);
PCDIMMDeviceClass *ddc = PC_DIMM_GET_CLASS(dimm);
MemoryRegion *mr = ddc-get_memory_region(dimm);
+uint64_t align = TARGET_PAGE_SIZE;
uint64_t addr;
addr = object_property_get_int(OBJECT(dimm), PC_DIMM_ADDR_PROP,
local_err);
@@ -1565,7 +1566,7 @@ static void pc_dimm_plug(HotplugHandler *hotplug_dev,
addr = pc_dimm_get_free_addr(pcms-hotplug_memory_base,
memory_region_size(pcms-hotplug_memory),
- !addr ? NULL : addr,
+ !addr ? NULL : addr, align,
memory_region_size(mr), local_err);
if (local_err) {
goto out;
diff --git a/hw/mem/pc-dimm.c b/hw/mem/pc-dimm.c
index a800ea7..4944f0f 100644
--- a/hw/mem/pc-dimm.c
+++ b/hw/mem/pc-dimm.c
@@ -139,7 +139,7 @@ static int pc_dimm_built_list(Object *obj, void *opaque)
uint64_t pc_dimm_get_free_addr(uint64_t address_space_start,
uint64_t address_space_size,
- uint64_t *hint, uint64_t size,
+ uint64_t *hint, uint64_t align, uint64_t size,
Error **errp)
{
GSList *list = NULL, *item;
@@ -152,6 +152,18 @@ uint64_t pc_dimm_get_free_addr(uint64_t
address_space_start,
goto out;
}
+if (hint QEMU_ALIGN_UP(*hint, align) != *hint) {
+error_setg(errp, address must be aligned to 0x% PRIx64 bytes,
+ align);
+goto out;
+}
+
+if (QEMU_ALIGN_UP(size, align) != size) {
+error_setg(errp, backend memory size must be multiple of 0x%
+ PRIx64, align);
+goto out;
+}
+
assert(address_space_end address_space_start);
object_child_foreach(qdev_get_machine(), pc_dimm_built_list, list);
--
MST
[Qemu-devel] [PULL 08/15] pc: explicitly check maxmem limit when adding DIMM
From: Igor Mammedov imamm...@redhat.com
Currently maxmem limit is not checked and depends on
hotplug region container not being able to fit more RAM
than maxmem. Do check explicitly so that it would
be possible to change hotplug container size later
to deal with fragmentation.
Signed-off-by: Igor Mammedov imamm...@redhat.com
Reviewed-by: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
hw/i386/pc.c | 45 +
1 file changed, 45 insertions(+)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 021ec44..d448d0d 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1545,6 +1545,37 @@ void qemu_register_pc_machine(QEMUMachine *m)
g_free(name);
}
+static int pc_dimm_count(Object *obj, void *opaque)
+{
+int *count = opaque;
+
+if (object_dynamic_cast(obj, TYPE_PC_DIMM)) {
+(*count)++;
+}
+
+object_child_foreach(obj, pc_dimm_count, opaque);
+return 0;
+}
+
+static int pc_existing_dimms_capacity(Object *obj, void *opaque)
+{
+Error *local_err = NULL;
+uint64_t *size = opaque;
+
+if (object_dynamic_cast(obj, TYPE_PC_DIMM)) {
+(*size) += object_property_get_int(obj, PC_DIMM_SIZE_PROP, local_err);
+
+if (local_err) {
+qerror_report_err(local_err);
+error_free(local_err);
+return 1;
+}
+}
+
+object_child_foreach(obj, pc_dimm_count, opaque);
+return 0;
+}
+
static void pc_dimm_plug(HotplugHandler *hotplug_dev,
DeviceState *dev, Error **errp)
{
@@ -1556,6 +1587,7 @@ static void pc_dimm_plug(HotplugHandler *hotplug_dev,
PCDIMMDevice *dimm = PC_DIMM(dev);
PCDIMMDeviceClass *ddc = PC_DIMM_GET_CLASS(dimm);
MemoryRegion *mr = ddc-get_memory_region(dimm);
+uint64_t existing_dimms_capacity = 0;
uint64_t align = TARGET_PAGE_SIZE;
uint64_t addr;
@@ -1576,6 +1608,19 @@ static void pc_dimm_plug(HotplugHandler *hotplug_dev,
goto out;
}
+if (pc_existing_dimms_capacity(OBJECT(machine), existing_dimms_capacity))
{
+error_setg(local_err, failed to get total size of existing DIMMs);
+goto out;
+}
+
+if (existing_dimms_capacity + memory_region_size(mr)
+machine-maxram_size - machine-ram_size) {
+error_setg(local_err, not enough space, currently 0x% PRIx64
+in use of total 0x% PRIx64,
+ existing_dimms_capacity, machine-maxram_size);
+goto out;
+}
+
object_property_set_int(OBJECT(dev), addr, PC_DIMM_ADDR_PROP, local_err);
if (local_err) {
goto out;
--
MST
[Qemu-devel] [PULL 07/15] pc: pc-dimm: use backend alignment during address auto allocation
From: Igor Mammedov imamm...@redhat.com
Signed-off-by: Igor Mammedov imamm...@redhat.com
Reviewed-by: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
hw/mem/pc-dimm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/hw/mem/pc-dimm.c b/hw/mem/pc-dimm.c
index 4944f0f..d431834 100644
--- a/hw/mem/pc-dimm.c
+++ b/hw/mem/pc-dimm.c
@@ -146,6 +146,9 @@ uint64_t pc_dimm_get_free_addr(uint64_t address_space_start,
uint64_t new_addr, ret = 0;
uint64_t address_space_end = address_space_start + address_space_size;
+g_assert(QEMU_ALIGN_UP(address_space_start, align) == address_space_start);
+g_assert(QEMU_ALIGN_UP(address_space_size, align) == address_space_size);
+
if (!address_space_size) {
error_setg(errp, memory hotplug is not enabled,
please add maxmem option);
@@ -189,7 +192,7 @@ uint64_t pc_dimm_get_free_addr(uint64_t address_space_start,
error_setg(errp, address range conflicts with '%s', d-id);
goto out;
}
-new_addr = dimm-addr + dimm_size;
+new_addr = QEMU_ALIGN_UP(dimm-addr + dimm_size, align);
}
}
ret = new_addr;
--
MST
[Qemu-devel] [PULL 10/15] hw/pci: fix crash on shpc error flow
From: Marcel Apfelbaum marce...@redhat.com
If the pci bridge enters in error flow as part
of init process it will only delete the shpc mmio
subregion but not remove it from the properties list,
resulting in segmentation fault when the bridge runs
the exit function.
Example: add a pci bridge without specifing the chassis number:
qemu-bin ... -device pci-bridge,id=p1
Result:
(qemu) qemu-system-x86_64: -device pci-bridge,id=p1: Bridge chassis not
specified. Each bridge is required to be assigned a unique chassis id 0.
qemu-system-x86_64: -device pci-bridge,id=p1: Device
initialization failed.
Segmentation fault (core dumped)
if (child-class-unparent) {
#0 0x558d629b in object_finalize_child_property
(obj=0x56d2e830, name=0x56d30630 shpc-mmio[0], opaque=0x56a42fc8)
at qom/object.c:1078
#1 0x558d4b1f in object_property_del_all (obj=0x56d2e830) at
qom/object.c:367
#2 0x558d4ca1 in object_finalize (data=0x56d2e830) at
qom/object.c:412
#3 0x558d55a1 in object_unref (obj=0x56d2e830) at
qom/object.c:720
#4 0x5572c907 in qdev_device_add (opts=0x563544f0) at
qdev-monitor.c:566
#5 0x55744f16 in device_init_func (opts=0x563544f0,
opaque=0x0) at vl.c:2213
#6 0x559cf5f0 in qemu_opts_foreach (list=0x55e0f8e0
qemu_device_opts, func=0x55744efa device_init_func, opaque=0x0,
abort_on_failure=1) at util/qemu-option.c:1057
#7 0x5574a11b in main (argc=16, argv=0x7fffdde8,
envp=0x7fffde70) at vl.c:423
Unparent the shpc mmio region as part of shpc cleanup.
Signed-off-by: Marcel Apfelbaum marce...@redhat.com
Reviewed-by: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Reviewed-by: Amos Kong ak...@redhat.com
---
hw/pci/shpc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/pci/shpc.c b/hw/pci/shpc.c
index 9a39060..27c496e 100644
--- a/hw/pci/shpc.c
+++ b/hw/pci/shpc.c
@@ -663,6 +663,7 @@ void shpc_cleanup(PCIDevice *d, MemoryRegion *bar)
SHPCDevice *shpc = d-shpc;
d-cap_present = ~QEMU_PCI_CAP_SHPC;
memory_region_del_subregion(bar, shpc-mmio);
+object_unparent(OBJECT(shpc-mmio));
/* TODO: cleanup config space changes? */
g_free(shpc-config);
g_free(shpc-cmask);
--
MST
[Qemu-devel] [PULL 11/15] acpi-build: mark RAM dirty on table update
acpi build modifies internal FW CFG RAM on first access
but we forgot to mark it dirty.
If this RAM has been migrated already, it won't be
migrated again, returning corrupted tables to guest.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
include/hw/loader.h | 2 +-
hw/core/loader.c | 8 +---
hw/i386/acpi-build.c | 11 ---
3 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/include/hw/loader.h b/include/hw/loader.h
index 054c6a2..6481639 100644
--- a/include/hw/loader.h
+++ b/include/hw/loader.h
@@ -59,7 +59,7 @@ extern bool rom_file_has_mr;
int rom_add_file(const char *file, const char *fw_dir,
hwaddr addr, int32_t bootindex,
bool option_rom);
-void *rom_add_blob(const char *name, const void *blob, size_t len,
+ram_addr_t rom_add_blob(const char *name, const void *blob, size_t len,
hwaddr addr, const char *fw_file_name,
FWCfgReadCallback fw_callback, void *callback_opaque);
int rom_add_elf_program(const char *name, void *data, size_t datasize,
diff --git a/hw/core/loader.c b/hw/core/loader.c
index fc15535..7527fd3 100644
--- a/hw/core/loader.c
+++ b/hw/core/loader.c
@@ -811,12 +811,12 @@ err:
return -1;
}
-void *rom_add_blob(const char *name, const void *blob, size_t len,
+ram_addr_t rom_add_blob(const char *name, const void *blob, size_t len,
hwaddr addr, const char *fw_file_name,
FWCfgReadCallback fw_callback, void *callback_opaque)
{
Rom *rom;
-void *data = NULL;
+ram_addr_t ret = RAM_ADDR_MAX;
rom = g_malloc0(sizeof(*rom));
rom-name = g_strdup(name);
@@ -828,11 +828,13 @@ void *rom_add_blob(const char *name, const void *blob,
size_t len,
rom_insert(rom);
if (fw_file_name fw_cfg) {
char devpath[100];
+void *data;
snprintf(devpath, sizeof(devpath), /rom@%s, fw_file_name);
if (rom_file_has_mr) {
data = rom_set_mr(rom, OBJECT(fw_cfg), devpath);
+ret = memory_region_get_ram_addr(rom-mr);
} else {
data = rom-data;
}
@@ -841,7 +843,7 @@ void *rom_add_blob(const char *name, const void *blob,
size_t len,
fw_callback, callback_opaque,
data, rom-romsize);
}
-return data;
+return ret;
}
/* This function is specific for elf program because we don't need to allocate
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 4003b6b..92a36e3 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -56,6 +56,7 @@
#include qapi/qmp/qint.h
#include qom/qom-qobject.h
+#include exec/ram_addr.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
@@ -1511,7 +1512,7 @@ static inline void
acpi_build_tables_cleanup(AcpiBuildTables *tables, bool mfre)
typedef
struct AcpiBuildState {
/* Copy of table in RAM (for patching). */
-uint8_t *table_ram;
+ram_addr_t table_ram;
uint32_t table_size;
/* Is table patched? */
uint8_t patched;
@@ -1716,9 +1717,12 @@ static void acpi_build_update(void *build_opaque,
uint32_t offset)
acpi_build(build_state-guest_info, tables);
assert(acpi_data_len(tables.table_data) == build_state-table_size);
-memcpy(build_state-table_ram, tables.table_data-data,
+memcpy(qemu_get_ram_ptr(build_state-table_ram), tables.table_data-data,
build_state-table_size);
+cpu_physical_memory_set_dirty_range_nocode(build_state-table_ram,
+ build_state-table_size);
+
acpi_build_tables_cleanup(tables, true);
}
@@ -1728,7 +1732,7 @@ static void acpi_build_reset(void *build_opaque)
build_state-patched = 0;
}
-static void *acpi_add_rom_blob(AcpiBuildState *build_state, GArray *blob,
+static ram_addr_t acpi_add_rom_blob(AcpiBuildState *build_state, GArray *blob,
const char *name)
{
return rom_add_blob(name, blob-data, acpi_data_len(blob), -1, name,
@@ -1777,6 +1781,7 @@ void acpi_setup(PcGuestInfo *guest_info)
/* Now expose it all to Guest */
build_state-table_ram = acpi_add_rom_blob(build_state, tables.table_data,
ACPI_BUILD_TABLE_FILE);
+assert(build_state-table_ram != RAM_ADDR_MAX);
build_state-table_size = acpi_data_len(tables.table_data);
acpi_add_rom_blob(NULL, tables.linker, etc/table-loader);
--
MST
[Qemu-devel] [PULL 13/15] pcie: fix typo in pcie_cap_deverr_init()
From: Gonglei arei.gong...@huawei.com Reported-by: https://bugs.launchpad.net/qemu/+bug/1393440 Signed-off-by: Gonglei arei.gong...@huawei.com Reviewed-by: Michael S. Tsirkin m...@redhat.com Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/pci/pcie.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c index 58455bd..fbba589 100644 --- a/hw/pci/pcie.c +++ b/hw/pci/pcie.c @@ -145,7 +145,7 @@ void pcie_cap_deverr_init(PCIDevice *dev) PCI_EXP_DEVCTL_FERE | PCI_EXP_DEVCTL_URRE); pci_long_test_and_set_mask(dev-w1cmask + pos + PCI_EXP_DEVSTA, PCI_EXP_DEVSTA_CED | PCI_EXP_DEVSTA_NFED | - PCI_EXP_DEVSTA_URD | PCI_EXP_DEVSTA_URD); + PCI_EXP_DEVSTA_FED | PCI_EXP_DEVSTA_URD); } void pcie_cap_deverr_reset(PCIDevice *dev) -- MST
[Qemu-devel] [PULL 12/15] target-i386: move generic memory hotplug methods to DSDTs
From: Paolo Bonzini pbonz...@redhat.com
This makes it simpler to keep the SSDT byte-for-byte identical for a
given machine type, which is a goal we want to have for 2.2 and newer
types.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Reviewed-by: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
hw/i386/acpi-dsdt-mem-hotplug.dsl | 176
hw/i386/acpi-dsdt.dsl | 3 +-
hw/i386/acpi-dsdt.hex.generated | 795 +-
hw/i386/q35-acpi-dsdt.dsl | 3 +-
hw/i386/q35-acpi-dsdt.hex.generated | 797 +-
hw/i386/ssdt-mem.hex.generated | 8 +-
hw/i386/ssdt-misc.dsl | 165 +--
hw/i386/ssdt-misc.hex.generated | 834 ++--
tests/acpi-test-data/pc/DSDT| Bin 2807 - 3592 bytes
tests/acpi-test-data/pc/SSDT| Bin 3065 - 2279 bytes
tests/acpi-test-data/q35/DSDT | Bin 7397 - 8182 bytes
tests/acpi-test-data/q35/SSDT | Bin 1346 - 560 bytes
12 files changed, 1789 insertions(+), 992 deletions(-)
create mode 100644 hw/i386/acpi-dsdt-mem-hotplug.dsl
diff --git a/hw/i386/acpi-dsdt-mem-hotplug.dsl
b/hw/i386/acpi-dsdt-mem-hotplug.dsl
new file mode 100644
index 000..2a36c47
--- /dev/null
+++ b/hw/i386/acpi-dsdt-mem-hotplug.dsl
@@ -0,0 +1,176 @@
+/*
+ * 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 http://www.gnu.org/licenses/.
+ */
+
+External(MEMORY_SLOT_NOTIFY_METHOD, MethodObj)
+
+Scope(\_SB.PCI0) {
+Device(MEMORY_HOTPLUG_DEVICE) {
+Name(_HID, PNP0A06)
+Name(_UID, Memory hotplug resources)
+External(MEMORY_SLOTS_NUMBER, IntObj)
+
+/* Memory hotplug IO registers */
+OperationRegion(MEMORY_HOTPLUG_IO_REGION, SystemIO,
+ACPI_MEMORY_HOTPLUG_BASE,
+ACPI_MEMORY_HOTPLUG_IO_LEN)
+
+Name(_CRS, ResourceTemplate() {
+IO(Decode16, ACPI_MEMORY_HOTPLUG_BASE,
ACPI_MEMORY_HOTPLUG_BASE,
+ 0, ACPI_MEMORY_HOTPLUG_IO_LEN, IO)
+})
+
+Method(_STA, 0) {
+If (LEqual(MEMORY_SLOTS_NUMBER, Zero)) {
+Return(0x0)
+}
+/* present, functioning, decoding, not shown in UI */
+Return(0xB)
+}
+
+Field(MEMORY_HOTPLUG_IO_REGION, DWordAcc, NoLock, Preserve) {
+MEMORY_SLOT_ADDR_LOW, 32, // read only
+MEMORY_SLOT_ADDR_HIGH, 32, // read only
+MEMORY_SLOT_SIZE_LOW, 32, // read only
+MEMORY_SLOT_SIZE_HIGH, 32, // read only
+MEMORY_SLOT_PROXIMITY, 32, // read only
+}
+Field(MEMORY_HOTPLUG_IO_REGION, ByteAcc, NoLock, Preserve) {
+Offset(20),
+MEMORY_SLOT_ENABLED, 1, // 1 if enabled, read only
+MEMORY_SLOT_INSERT_EVENT, 1, // (read) 1 if has a insert
event. (write) 1 to clear event
+}
+
+Mutex (MEMORY_SLOT_LOCK, 0)
+Field (MEMORY_HOTPLUG_IO_REGION, DWordAcc, NoLock, Preserve) {
+MEMORY_SLOT_SLECTOR, 32, // DIMM selector, write only
+MEMORY_SLOT_OST_EVENT, 32, // _OST event code, write only
+MEMORY_SLOT_OST_STATUS, 32, // _OST status code, write only
+}
+
+Method(MEMORY_SLOT_SCAN_METHOD, 0) {
+If (LEqual(MEMORY_SLOTS_NUMBER, Zero)) {
+ Return(Zero)
+}
+
+Store(Zero, Local0) // Mem devs iterrator
+Acquire(MEMORY_SLOT_LOCK, 0x)
+while (LLess(Local0, MEMORY_SLOTS_NUMBER)) {
+Store(Local0, MEMORY_SLOT_SLECTOR) // select Local0 DIMM
+If (LEqual(MEMORY_SLOT_INSERT_EVENT, One)) { // Memory
device needs check
+MEMORY_SLOT_NOTIFY_METHOD(Local0, 1)
+Store(1, MEMORY_SLOT_INSERT_EVENT)
+}
+// TODO: handle memory eject request
+Add(Local0, One, Local0) // goto next DIMM
+}
+Release(MEMORY_SLOT_LOCK)
+Return(One)
+}
+
+Method(MEMORY_SLOT_STATUS_METHOD, 1) {
+Store(Zero, Local0)
+
+
[Qemu-devel] [PULL 14/15] pcie: fix improper use of negative value
From: Gonglei arei.gong...@huawei.com Signed-off-by: Gonglei arei.gong...@huawei.com Reviewed-by: Michael S. Tsirkin m...@redhat.com Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/pci/pcie.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c index fbba589..1a1 100644 --- a/hw/pci/pcie.c +++ b/hw/pci/pcie.c @@ -229,7 +229,7 @@ static void pcie_cap_slot_hotplug_common(PCIDevice *hotplug_dev, /* the slot is electromechanically locked. * This error is propagated up to qdev and then to HMP/QMP. */ -error_setg_errno(errp, -EBUSY, slot is electromechanically locked); +error_setg_errno(errp, EBUSY, slot is electromechanically locked); } } -- MST
[Qemu-devel] [PULL 15/15] pc: acpi: mark all possible CPUs as enabled in SRAT
From: Igor Mammedov imamm...@redhat.com
If QEMU is started with -numa ... Windows only notices that
CPU has been hot-added but it will not online such CPUs.
It's caused by the fact that possible CPUs are flagged as
not enabled in SRAT and Windows honoring that information
doesn't use corresponding CPU.
ACPI 5.0 Spec regarding to flag says:
Table 5-47 Local APIC Flags
...
Enabled: if zero, this processor is unusable, and the operating system
support will not attempt to use it.
Fix QEMU to adhere to spec and mark possible CPUs as enabled
in SRAT.
With that Windows onlines hot-added CPUs as expected.
Signed-off-by: Igor Mammedov imamm...@redhat.com
Reviewed-by: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
hw/i386/acpi-build.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 92a36e3..b37a397 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -1270,8 +1270,7 @@ acpi_build_srat_memory(AcpiSratMemoryAffinity *numamem,
uint64_t base,
}
static void
-build_srat(GArray *table_data, GArray *linker,
- AcpiCpuInfo *cpu, PcGuestInfo *guest_info)
+build_srat(GArray *table_data, GArray *linker, PcGuestInfo *guest_info)
{
AcpiSystemResourceAffinityTable *srat;
AcpiSratProcessorAffinity *core;
@@ -1301,11 +1300,7 @@ build_srat(GArray *table_data, GArray *linker,
core-proximity_lo = curnode;
memset(core-proximity_hi, 0, 3);
core-local_sapic_eid = 0;
-if (test_bit(i, cpu-found_cpus)) {
-core-flags = cpu_to_le32(1);
-} else {
-core-flags = cpu_to_le32(0);
-}
+core-flags = cpu_to_le32(1);
}
@@ -1623,7 +1618,7 @@ void acpi_build(PcGuestInfo *guest_info, AcpiBuildTables
*tables)
}
if (guest_info-numa_nodes) {
acpi_add_table(table_offsets, tables-table_data);
-build_srat(tables-table_data, tables-linker, cpu, guest_info);
+build_srat(tables-table_data, tables-linker, guest_info);
}
if (acpi_get_mcfg(mcfg)) {
acpi_add_table(table_offsets, tables-table_data);
--
MST
Re: [Qemu-devel] [PATCH v2 5/5] libqos: Add virtio MMIO support
El Mon, 17 Nov 2014 15:48:09 +
Stefan Hajnoczi stefa...@gmail.com escribió:
On Sat, Nov 01, 2014 at 06:02:30PM +0100, Marc Marí wrote:
+static void mmio_basic(void)
+{
+QVirtioMMIODevice *dev;
+QVirtQueue *vq;
+QGuestAllocator *alloc;
+QVirtioBlkReq req;
+int n_size = TEST_IMAGE_SIZE / 2;
+uint64_t req_addr;
+uint64_t capacity;
+uint32_t features;
+uint32_t free_head;
+uint8_t status;
+char *data;
+
+arm_test_start();
+
+dev = qvirtio_mmio_init_device(MMIO_DEV_BASE_ADDR,
MMIO_PAGE_SIZE);
+g_assert(dev != NULL);
+g_assert_cmphex(dev-vdev.device_type, ==,
QVIRTIO_BLK_DEVICE_ID); +
+qvirtio_reset(qvirtio_mmio, dev-vdev);
+qvirtio_set_acknowledge(qvirtio_mmio, dev-vdev);
+qvirtio_set_driver(qvirtio_mmio, dev-vdev);
+
+capacity = qvirtio_config_readq(qvirtio_mmio, dev-vdev,
+
QVIRTIO_MMIO_DEVICE_SPECIFIC);
+g_assert_cmpint(capacity, ==, TEST_IMAGE_SIZE / 512);
+
+features = qvirtio_get_features(qvirtio_mmio, dev-vdev);
+features = features ~(QVIRTIO_F_RING_INDIRECT_DESC |
+QVIRTIO_F_RING_EVENT_IDX |
QVIRTIO_BLK_F_SCSI);
+qvirtio_set_features(qvirtio_mmio, dev-vdev, features);
+
+alloc = generic_alloc_init(MMIO_RAM_ADDR, MMIO_RAM_SIZE,
MMIO_PAGE_SIZE);
+vq = qvirtqueue_setup(qvirtio_mmio, dev-vdev, alloc, 0);
+
+qvirtio_set_driver_ok(qvirtio_mmio, dev-vdev);
+
+qmp({ 'execute': 'block_resize', 'arguments': { 'device':
'drive0',
+ 'size':
%d } }, n_size); +
+qvirtio_wait_queue_isr(qvirtio_mmio, dev-vdev, vq,
+ QVIRTIO_BLK_TIMEOUT_US);
+
+capacity = qvirtio_config_readq(qvirtio_mmio, dev-vdev,
+
QVIRTIO_MMIO_DEVICE_SPECIFIC);
+g_assert_cmpint(capacity, ==, n_size / 512);
+
+/* Write request */
+req.type = QVIRTIO_BLK_T_OUT;
+req.ioprio = 1;
+req.sector = 0;
+req.data = g_malloc0(512);
+strcpy(req.data, TEST);
+
+req_addr = virtio_blk_request(alloc, req, 512);
+
+g_free(req.data);
+
+free_head = qvirtqueue_add(vq, req_addr, 528, false, true);
+qvirtqueue_add(vq, req_addr + 528, 1, true, false);
+qvirtqueue_kick(qvirtio_mmio, dev-vdev, vq, free_head);
+
+qvirtio_wait_queue_isr(qvirtio_mmio, dev-vdev, vq,
+ QVIRTIO_BLK_TIMEOUT_US);
+status = readb(req_addr + 528);
+g_assert_cmpint(status, ==, 0);
+
+guest_free(alloc, req_addr);
+
+/* Read request */
+req.type = QVIRTIO_BLK_T_IN;
+req.ioprio = 1;
+req.sector = 0;
+req.data = g_malloc0(512);
+
+req_addr = virtio_blk_request(alloc, req, 512);
+
+g_free(req.data);
+
+free_head = qvirtqueue_add(vq, req_addr, 16, false, true);
+qvirtqueue_add(vq, req_addr + 16, 513, true, false);
+
+qvirtqueue_kick(qvirtio_mmio, dev-vdev, vq, free_head);
+
+qvirtio_wait_queue_isr(qvirtio_mmio, dev-vdev, vq,
+ QVIRTIO_BLK_TIMEOUT_US);
+status = readb(req_addr + 528);
+g_assert_cmpint(status, ==, 0);
+
+data = g_malloc0(512);
+memread(req_addr + 16, data, 512);
+g_assert_cmpstr(data, ==, TEST);
+g_free(data);
There is a lot of code duplication here. Can the test logic but
shared between PCI and MMIO?
The code duplication that can be easily extracted and shared is
performing a simple write - read operation on the block device (which
is used in various test cases). Other places (for example, checking the
image size) use arch specific offsets. This could be abstracted, but I
think is a bit too complicated for a test case.
By now, I will extract just write - read operation. If you think that
adding abstraction for arch specific offsets is worth the effort, then
I'll add them.
Marc
Re: [Qemu-devel] [PATCH 2/2] vga: flip qemu 2.2 pc machine types from cirrus to stdvga
On Tue, Oct 28, 2014 at 10:09:12AM +0100, Gerd Hoffmann wrote:
This patch switches the default display from cirrus to vga
for the new (qemu 2.2+) machine types. Old machines types
stay as-is for compatibility reasons.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
Gerd, I noticed that this caused a regression:
suspend no longer works with windows, the option
to suspend is greyed out.
This is not new - it was disabled with -vga std previously -
but poses a bigger problem now it's the default?
Thoughts? Something we can fix for 2.2?
---
hw/i386/pc_piix.c | 7 +--
hw/i386/pc_q35.c | 7 +--
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 91a20cb..8637246 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -456,7 +456,8 @@ static void pc_xen_hvm_init(MachineState *machine)
#define PC_I440FX_2_2_MACHINE_OPTIONS \
PC_I440FX_MACHINE_OPTIONS, \
-.default_machine_opts = firmware=bios-256k.bin
+.default_machine_opts = firmware=bios-256k.bin, \
+.default_display = std
static QEMUMachine pc_i440fx_machine_v2_2 = {
PC_I440FX_2_2_MACHINE_OPTIONS,
@@ -466,7 +467,9 @@ static QEMUMachine pc_i440fx_machine_v2_2 = {
.is_default = 1,
};
-#define PC_I440FX_2_1_MACHINE_OPTIONS PC_I440FX_2_2_MACHINE_OPTIONS
+#define PC_I440FX_2_1_MACHINE_OPTIONS \
+PC_I440FX_MACHINE_OPTIONS, \
+.default_machine_opts = firmware=bios-256k.bin
static QEMUMachine pc_i440fx_machine_v2_1 = {
PC_I440FX_2_1_MACHINE_OPTIONS,
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index e225c6d..9fdb3fa 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -353,7 +353,8 @@ static void pc_q35_init_1_4(MachineState *machine)
#define PC_Q35_2_2_MACHINE_OPTIONS \
PC_Q35_MACHINE_OPTIONS, \
-.default_machine_opts = firmware=bios-256k.bin
+.default_machine_opts = firmware=bios-256k.bin, \
+.default_display = std
static QEMUMachine pc_q35_machine_v2_2 = {
PC_Q35_2_2_MACHINE_OPTIONS,
@@ -362,7 +363,9 @@ static QEMUMachine pc_q35_machine_v2_2 = {
.init = pc_q35_init,
};
-#define PC_Q35_2_1_MACHINE_OPTIONS PC_Q35_2_2_MACHINE_OPTIONS
+#define PC_Q35_2_1_MACHINE_OPTIONS \
+PC_Q35_MACHINE_OPTIONS, \
+.default_machine_opts = firmware=bios-256k.bin
static QEMUMachine pc_q35_machine_v2_1 = {
PC_Q35_2_1_MACHINE_OPTIONS,
--
1.8.3.1
Re: [Qemu-devel] How to access guest memory from qemu device internal
-Origin email- From: Peter Maydell peter.mayd...@linaro.org Sent Time: Friday, November 21, 2014 To: Kaiyuan kaiyu...@tju.edu.cn Cc: Greg Kurz gk...@linux.vnet.ibm.com, qemu-devel qemu-devel@nongnu.org Subject: Re: [Qemu-devel] Fw:Re:Re: How to access guest memory from qemu device internal On 21 November 2014 09:17, Kaiyuan kaiyu...@tju.edu.cn wrote: Thanks, Greg. It's useful to me. cpu_physical_memory_read() looks like a wrapper of translating guest addr to host addr Is there a function that translates guest address to host physical address? No, QEMU never deals with host physical addresses at all. In general there are three address types that might be in use: * guest virtual address * guest physical address * host virtual address (only relevant if talking to RAM, rather than an emulated device) For devices, the guest within the VM should deal with converting a virtual address to a guest physical address, and should write guest physical addresses to the device. [If you think about real hardware, where the device is separate from the CPU, there's no way the device can know about guest virtual addresses, which are handled by the CPU's built in MMU.] So the function Greg suggests is the one you want. -- PMM Thanks for your explanation about guest physical/virtual address and host physical/virtual address, and I think I asked a wrong question. Is there a function that translates guest Physical address to host Virtual address so that I can access guest space by a host pointer?
[Qemu-devel] [PATCH] gdbstub: Support AUXV packet for debugging PIE executables.
Hi,
This patch adds support for sending AUXV packet.
This is required for debugging Linux position independent executables.
Otherwise, gdb client cannot find out where the executable is loaded.
Signed-off-by: Wei-cheng, Wang cole...@gmail.com
---
gdbstub.c | 41 +
1 file changed, 41 insertions(+)
diff --git a/gdbstub.c b/gdbstub.c
index d1b5afd..30f3bbc 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -1127,6 +1127,7 @@ static int gdb_handle_packet(GDBState *s, const char
*line_buf)
if (cc-gdb_core_xml_file != NULL) {
pstrcat(buf, sizeof(buf), ;qXfer:features:read+);
}
+pstrcat(buf, sizeof(buf), ;qXfer:auxv:read+);
put_packet(s, buf);
break;
}
@@ -1173,6 +1174,46 @@ static int gdb_handle_packet(GDBState *s, const char
*line_buf)
put_packet_binary(s, buf, len + 1);
break;
}
+#ifdef CONFIG_USER_ONLY
+if (strncmp(p, Xfer:auxv:read:, 15) == 0) {
+TaskState *ts = s-c_cpu-opaque;
+target_ulong auxv = ts-info-saved_auxv;
+target_ulong auxv_len = ts-info-auxv_len;
+char *ptr;
+
+p += 15;
+while (*p *p != ':')
+p++;
+p++;
+
+addr = strtoul(p, (char **)p, 16);
+if (*p == ',')
+p++;
+len = strtoul(p, (char **)p, 16);
+
+ptr = lock_user(VERIFY_READ, auxv, auxv_len, 0);
+if (ptr == NULL) {
+break;
+}
+
+if (addr len) {
+snprintf(buf, sizeof(buf), E00);
+put_packet(s, buf);
+break;
+}
+if (len (MAX_PACKET_LENGTH - 5) / 2)
+len = (MAX_PACKET_LENGTH - 5) / 2;
+if (len auxv_len - addr) {
+buf[0] = 'm';
+len = memtox(buf + 1, ptr + addr, len);
+} else {
+buf[0] = 'l';
+len = memtox(buf + 1, ptr + addr, auxv_len - addr);
+}
+put_packet_binary(s, buf, len + 1);
+unlock_user(ptr, auxv, len);
+}
+#endif /* !CONFIG_USER_ONLY */
/* Unrecognised 'q' command. */
goto unknown_command;
--
1.9.1
Re: [Qemu-devel] [PATCH] gdbstub: Convert gdb-signal to target signal when continuing.
Ping?
On 10/27/2014 12:58 AM, Wei-cheng Wang wrote:
QEMU should convert signal number reciving from GDB cilent
from gdb-signal number to target sginal number - using gdb_signal_to_target().
In this case, GDB_SIG_BUS is 10. However, 10 is SIGUSR1 for target.
So QEMU continues with the wrong signal number.
#include stdio.h
#include signal.h
void handle_signal (int sig)
{
puts (Hello);
}
int main ()
{
signal (SIGBUS, handle_signal);
kill (0, SIGBUS);
return 0;
}
(gdb) target remote :25566
Remote debugging using :25566
0x8b98 in _start ()
(gdb) c
Continuing.
Program received signal SIGBUS, Bus error.
0xe18c in kill ()
(gdb) c
Continuing.
Program terminated with signal SIGUSR1, User defined signal 1.
^^^
The program no longer exists.
(gdb)
Thansk,
Wei-cheng Wang
From: Cole Wang cole...@gmail.com
Date: Mon, 27 Oct 2014 00:33:18 +0800
Subject: [PATCH] gdbstub: Convert gdb-signal to target signal when continuing.
Signed-off-by: Wei-cheng Wang cole...@gmail.com
---
gdbstub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gdbstub.c b/gdbstub.c
index d1b5afd..cce5c69 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -851,7 +851,7 @@ static int gdb_handle_packet(GDBState *s, const
char *line_buf)
if (res == 's') {
cpu_single_step(s-c_cpu, sstep_flags);
}
-s-signal = res_signal;
+s-signal = gdb_signal_to_target(res_signal);
gdb_continue(s);
return RS_IDLE;
}
--
1.9.1
Re: [Qemu-devel] [PATCH] gdbstub: Convert gdb-signal to target signal when continuing.
Never mind. I just found Martin Simmons fixed the same issue.
On Sun, Nov 23, 2014 at 9:30 PM, Wei-cheng, Wang cole...@gmail.com wrote:
Ping?
On 10/27/2014 12:58 AM, Wei-cheng Wang wrote:
QEMU should convert signal number reciving from GDB cilent
from gdb-signal number to target sginal number - using
gdb_signal_to_target().
In this case, GDB_SIG_BUS is 10. However, 10 is SIGUSR1 for target.
So QEMU continues with the wrong signal number.
#include stdio.h
#include signal.h
void handle_signal (int sig)
{
puts (Hello);
}
int main ()
{
signal (SIGBUS, handle_signal);
kill (0, SIGBUS);
return 0;
}
(gdb) target remote :25566
Remote debugging using :25566
0x8b98 in _start ()
(gdb) c
Continuing.
Program received signal SIGBUS, Bus error.
0xe18c in kill ()
(gdb) c
Continuing.
Program terminated with signal SIGUSR1, User defined signal 1.
^^^
The program no longer exists.
(gdb)
Thansk,
Wei-cheng Wang
From: Cole Wang cole...@gmail.com
Date: Mon, 27 Oct 2014 00:33:18 +0800
Subject: [PATCH] gdbstub: Convert gdb-signal to target signal when
continuing.
Signed-off-by: Wei-cheng Wang cole...@gmail.com
---
gdbstub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gdbstub.c b/gdbstub.c
index d1b5afd..cce5c69 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -851,7 +851,7 @@ static int gdb_handle_packet(GDBState *s, const
char *line_buf)
if (res == 's') {
cpu_single_step(s-c_cpu, sstep_flags);
}
-s-signal = res_signal;
+s-signal = gdb_signal_to_target(res_signal);
gdb_continue(s);
return RS_IDLE;
}
--
1.9.1
Re: [Qemu-devel] install windows, csm in montherboard turned off
Thats exactly it. thanks very much ;)
[Qemu-devel] [Bug 156085] Re: Could not open /proc/bus/usb/devices
Hardy has seen the end of its life and is no longer receiving any updates. Marking the Hardy task for this ticket as Won't Fix. ** Changed in: kvm (Ubuntu Hardy) Status: Confirmed = Won't Fix -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/156085 Title: Could not open /proc/bus/usb/devices Status in QEMU: Fix Released Status in Virtualbox: Fix Released Status in “apcupsd” package in Ubuntu: Invalid Status in “fxload” package in Ubuntu: Fix Released Status in “kvm” package in Ubuntu: Fix Released Status in “madfuload” package in Ubuntu: Fix Released Status in “midisport-firmware” package in Ubuntu: Fix Released Status in “qemu” package in Ubuntu: Fix Released Status in “sysvinit” package in Ubuntu: Won't Fix Status in “usbview” package in Ubuntu: Triaged Status in “vmware-server” package in Ubuntu: Invalid Status in “apcupsd” source package in Gutsy: Invalid Status in “fxload” source package in Gutsy: Won't Fix Status in “kvm” source package in Gutsy: Won't Fix Status in “madfuload” source package in Gutsy: Won't Fix Status in “midisport-firmware” source package in Gutsy: Won't Fix Status in “qemu” source package in Gutsy: Won't Fix Status in “sysvinit” source package in Gutsy: Invalid Status in “usbview” source package in Gutsy: Won't Fix Status in “vmware-server” source package in Gutsy: Won't Fix Status in “apcupsd” source package in Hardy: Invalid Status in “fxload” source package in Hardy: Won't Fix Status in “kvm” source package in Hardy: Won't Fix Status in “madfuload” source package in Hardy: Won't Fix Status in “midisport-firmware” source package in Hardy: Won't Fix Status in “qemu” source package in Hardy: Won't Fix Status in “sysvinit” source package in Hardy: Won't Fix Status in “usbview” source package in Hardy: Won't Fix Status in “vmware-server” source package in Hardy: Won't Fix Status in “apcupsd” source package in Jaunty: Invalid Status in “fxload” source package in Jaunty: Fix Released Status in “kvm” source package in Jaunty: Fix Released Status in “madfuload” source package in Jaunty: Fix Released Status in “midisport-firmware” source package in Jaunty: Fix Released Status in “qemu” source package in Jaunty: Fix Released Status in “sysvinit” source package in Jaunty: Won't Fix Status in “usbview” source package in Jaunty: Won't Fix Status in “vmware-server” source package in Jaunty: Invalid Status in “usbview” package in Debian: Fix Released Status in “qemu” package in openSUSE: Fix Released Bug description: On Gutsy 64-bit using qemu/kvm (also VirtualBox and, I believe, VMWare) and the -usb switch no USB devices are available since qemu/kvm looks for the description of them in the 'devices' file of a usbfs mount at /proc/bus/usb/ but the code previously providing the usbfs mount that is created at start-up via /etc/rcS/S11mountdevsubfs.sh -- /etc/init.d/mountdevsubfs.sh was commented out. The USB devices are now reported at /dev/bus/usb/ but currently there is no usbfs file-system mounted/linked there to provide the 'devices' text-file. qemu/kvm reports: qemuctl -qemu vdeq kvm -boot c -m 512 -hda /home/all/VirtualMachines /WindowsXP-SP2.ovl -net nic,vlan=0 -soundhw es1370 -usb -net vde info usbhost Could not open /proc/bus/usb/devices $ ls -l /proc/bus/usb total 0 WORKAROUND: To re-enable it edit the file '/etc/init.d/mountdevsubfs.sh' and uncomment the code after line 40 so it reads: # Magic to make /proc/bus/usb work # mkdir -p /dev/bus/usb/.usbfs domount usbfs /dev/bus/usb/.usbfs -obusmode=0700,devmode=0600,listmode=0644 ln -s .usbfs/devices /dev/bus/usb/devices mount --rbind /dev/bus/usb /proc/bus/usb Execute the script manually to enable the change before a system reboot: $ sudo /etc/init.d/mountdevsubfs.sh start To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/156085/+subscriptions
[Qemu-devel] [Bug 156085] Re: Could not open /proc/bus/usb/devices
Hardy has seen the end of its life and is no longer receiving any updates. Marking the Hardy task for this ticket as Won't Fix. ** Changed in: qemu (Ubuntu Hardy) Status: Confirmed = Won't Fix -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/156085 Title: Could not open /proc/bus/usb/devices Status in QEMU: Fix Released Status in Virtualbox: Fix Released Status in “apcupsd” package in Ubuntu: Invalid Status in “fxload” package in Ubuntu: Fix Released Status in “kvm” package in Ubuntu: Fix Released Status in “madfuload” package in Ubuntu: Fix Released Status in “midisport-firmware” package in Ubuntu: Fix Released Status in “qemu” package in Ubuntu: Fix Released Status in “sysvinit” package in Ubuntu: Won't Fix Status in “usbview” package in Ubuntu: Triaged Status in “vmware-server” package in Ubuntu: Invalid Status in “apcupsd” source package in Gutsy: Invalid Status in “fxload” source package in Gutsy: Won't Fix Status in “kvm” source package in Gutsy: Won't Fix Status in “madfuload” source package in Gutsy: Won't Fix Status in “midisport-firmware” source package in Gutsy: Won't Fix Status in “qemu” source package in Gutsy: Won't Fix Status in “sysvinit” source package in Gutsy: Invalid Status in “usbview” source package in Gutsy: Won't Fix Status in “vmware-server” source package in Gutsy: Won't Fix Status in “apcupsd” source package in Hardy: Invalid Status in “fxload” source package in Hardy: Won't Fix Status in “kvm” source package in Hardy: Won't Fix Status in “madfuload” source package in Hardy: Won't Fix Status in “midisport-firmware” source package in Hardy: Won't Fix Status in “qemu” source package in Hardy: Won't Fix Status in “sysvinit” source package in Hardy: Won't Fix Status in “usbview” source package in Hardy: Won't Fix Status in “vmware-server” source package in Hardy: Won't Fix Status in “apcupsd” source package in Jaunty: Invalid Status in “fxload” source package in Jaunty: Fix Released Status in “kvm” source package in Jaunty: Fix Released Status in “madfuload” source package in Jaunty: Fix Released Status in “midisport-firmware” source package in Jaunty: Fix Released Status in “qemu” source package in Jaunty: Fix Released Status in “sysvinit” source package in Jaunty: Won't Fix Status in “usbview” source package in Jaunty: Won't Fix Status in “vmware-server” source package in Jaunty: Invalid Status in “usbview” package in Debian: Fix Released Status in “qemu” package in openSUSE: Fix Released Bug description: On Gutsy 64-bit using qemu/kvm (also VirtualBox and, I believe, VMWare) and the -usb switch no USB devices are available since qemu/kvm looks for the description of them in the 'devices' file of a usbfs mount at /proc/bus/usb/ but the code previously providing the usbfs mount that is created at start-up via /etc/rcS/S11mountdevsubfs.sh -- /etc/init.d/mountdevsubfs.sh was commented out. The USB devices are now reported at /dev/bus/usb/ but currently there is no usbfs file-system mounted/linked there to provide the 'devices' text-file. qemu/kvm reports: qemuctl -qemu vdeq kvm -boot c -m 512 -hda /home/all/VirtualMachines /WindowsXP-SP2.ovl -net nic,vlan=0 -soundhw es1370 -usb -net vde info usbhost Could not open /proc/bus/usb/devices $ ls -l /proc/bus/usb total 0 WORKAROUND: To re-enable it edit the file '/etc/init.d/mountdevsubfs.sh' and uncomment the code after line 40 so it reads: # Magic to make /proc/bus/usb work # mkdir -p /dev/bus/usb/.usbfs domount usbfs /dev/bus/usb/.usbfs -obusmode=0700,devmode=0600,listmode=0644 ln -s .usbfs/devices /dev/bus/usb/devices mount --rbind /dev/bus/usb /proc/bus/usb Execute the script manually to enable the change before a system reboot: $ sudo /etc/init.d/mountdevsubfs.sh start To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/156085/+subscriptions
[Qemu-devel] [Bug 156085] Re: Could not open /proc/bus/usb/devices
Hardy has seen the end of its life and is no longer receiving any updates. Marking the Hardy task for this ticket as Won't Fix. ** Changed in: usbview (Ubuntu Hardy) Status: Confirmed = Won't Fix -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/156085 Title: Could not open /proc/bus/usb/devices Status in QEMU: Fix Released Status in Virtualbox: Fix Released Status in “apcupsd” package in Ubuntu: Invalid Status in “fxload” package in Ubuntu: Fix Released Status in “kvm” package in Ubuntu: Fix Released Status in “madfuload” package in Ubuntu: Fix Released Status in “midisport-firmware” package in Ubuntu: Fix Released Status in “qemu” package in Ubuntu: Fix Released Status in “sysvinit” package in Ubuntu: Won't Fix Status in “usbview” package in Ubuntu: Triaged Status in “vmware-server” package in Ubuntu: Invalid Status in “apcupsd” source package in Gutsy: Invalid Status in “fxload” source package in Gutsy: Won't Fix Status in “kvm” source package in Gutsy: Won't Fix Status in “madfuload” source package in Gutsy: Won't Fix Status in “midisport-firmware” source package in Gutsy: Won't Fix Status in “qemu” source package in Gutsy: Won't Fix Status in “sysvinit” source package in Gutsy: Invalid Status in “usbview” source package in Gutsy: Won't Fix Status in “vmware-server” source package in Gutsy: Won't Fix Status in “apcupsd” source package in Hardy: Invalid Status in “fxload” source package in Hardy: Won't Fix Status in “kvm” source package in Hardy: Won't Fix Status in “madfuload” source package in Hardy: Won't Fix Status in “midisport-firmware” source package in Hardy: Won't Fix Status in “qemu” source package in Hardy: Won't Fix Status in “sysvinit” source package in Hardy: Won't Fix Status in “usbview” source package in Hardy: Won't Fix Status in “vmware-server” source package in Hardy: Won't Fix Status in “apcupsd” source package in Jaunty: Invalid Status in “fxload” source package in Jaunty: Fix Released Status in “kvm” source package in Jaunty: Fix Released Status in “madfuload” source package in Jaunty: Fix Released Status in “midisport-firmware” source package in Jaunty: Fix Released Status in “qemu” source package in Jaunty: Fix Released Status in “sysvinit” source package in Jaunty: Won't Fix Status in “usbview” source package in Jaunty: Won't Fix Status in “vmware-server” source package in Jaunty: Invalid Status in “usbview” package in Debian: Fix Released Status in “qemu” package in openSUSE: Fix Released Bug description: On Gutsy 64-bit using qemu/kvm (also VirtualBox and, I believe, VMWare) and the -usb switch no USB devices are available since qemu/kvm looks for the description of them in the 'devices' file of a usbfs mount at /proc/bus/usb/ but the code previously providing the usbfs mount that is created at start-up via /etc/rcS/S11mountdevsubfs.sh -- /etc/init.d/mountdevsubfs.sh was commented out. The USB devices are now reported at /dev/bus/usb/ but currently there is no usbfs file-system mounted/linked there to provide the 'devices' text-file. qemu/kvm reports: qemuctl -qemu vdeq kvm -boot c -m 512 -hda /home/all/VirtualMachines /WindowsXP-SP2.ovl -net nic,vlan=0 -soundhw es1370 -usb -net vde info usbhost Could not open /proc/bus/usb/devices $ ls -l /proc/bus/usb total 0 WORKAROUND: To re-enable it edit the file '/etc/init.d/mountdevsubfs.sh' and uncomment the code after line 40 so it reads: # Magic to make /proc/bus/usb work # mkdir -p /dev/bus/usb/.usbfs domount usbfs /dev/bus/usb/.usbfs -obusmode=0700,devmode=0600,listmode=0644 ln -s .usbfs/devices /dev/bus/usb/devices mount --rbind /dev/bus/usb /proc/bus/usb Execute the script manually to enable the change before a system reboot: $ sudo /etc/init.d/mountdevsubfs.sh start To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/156085/+subscriptions
Re: [Qemu-devel] How to access guest memory from qemu device internal
On 23 November 2014 at 13:18, Kaiyuan kaiyu...@tju.edu.cn wrote: Thanks for your explanation about guest physical/virtual address and host physical/virtual address, and I think I asked a wrong question. Is there a function that translates guest Physical address to host Virtual address so that I can access guest space by a host pointer? You can use cpu_physical_memory_map() and _unmap() for this kind of thing. (Make sure you unmap afterwards.) -- PMM
[Qemu-devel] QEMU Threading Model
Greetings, Could you kindly elaborate QEMU threading model under the following condition. I started virtual machine with 2 virtual cpus (KVM assisted). It generated a number of threads in qemu, though I was not doing any CPU intense or IO intense operations. I understand from http://bit.ly/1Fgw3iV article that qemu creates one thread per vcpu(vcpu1, vcpu2) and an IO thread.(io) It sums up three permanent threads. 1. Are all other threads worker threads, how they are created? 2. Can I schedule the threads that are doing the task of vcpu1 in a different scheduling policy? Thanks in advance. Reagrds, Tamilselvan Shanmugam
[Qemu-devel] [Bug 1392504] Re: USB Passthrough is not working anymore
I think it is related to Apparmor, I see the following lines in /etc/syslog: Nov 22 14:36:23 uvir kernel: [18882.602278] audit: type=1400 audit(1416663383.171:69): apparmor=DENIED operation=open profile=libvirt-30619811-d285-944a-026a-cdd4a753b77a name=/sys/devices/pci:00/:00:1c.3/:03:00.0/usb3/uevent pid=14279 comm=qemu-system-x86 requested_mask=r denied_mask=r fsuid=106 ouid=0 Nov 22 14:36:23 uvir kernel: [18882.602295] audit: type=1400 audit(1416663383.171:70): apparmor=DENIED operation=open profile=libvirt-30619811-d285-944a-026a-cdd4a753b77a name=/sys/devices/pci:00/:00:1c.3/:03:00.0/usb3/3-0:1.0/uevent pid=14279 comm=qemu-system-x86 requested_mask=r denied_mask=r fsuid=106 ouid=0 Nov 22 14:36:23 uvir kernel: [18882.602306] audit: type=1400 audit(1416663383.171:71): apparmor=DENIED operation=open profile=libvirt-30619811-d285-944a-026a-cdd4a753b77a name=/sys/devices/pci:00/:00:1c.3/:03:00.0/usb4/uevent pid=14279 comm=qemu-system-x86 requested_mask=r denied_mask=r fsuid=106 ouid=0 Nov 22 14:36:23 uvir kernel: [18882.602318] audit: type=1400 audit(1416663383.171:72): apparmor=DENIED operation=open profile=libvirt-30619811-d285-944a-026a-cdd4a753b77a name=/sys/devices/pci:00/:00:1c.3/:03:00.0/usb4/4-0:1.0/uevent pid=14279 comm=qemu-system-x86 requested_mask=r denied_mask=r fsuid=106 ouid=0 Nov 22 14:36:23 uvir kernel: [18882.602330] audit: type=1400 audit(1416663383.171:73): apparmor=DENIED operation=open profile=libvirt-30619811-d285-944a-026a-cdd4a753b77a name=/sys/devices/pci:00/:00:1c.3/:03:00.0/usb4/4-2/uevent pid=14279 comm=qemu-system-x86 requested_mask=r denied_mask=r fsuid=106 ouid=0 Nov 23 00:28:39 uvir kernel: [35109.848778] audit: type=1400 audit(1416698919.255:181): apparmor=DENIED operation=open profile=libvirt-30619811-d285-944a-026a-cdd4a753b77a name=/sys/devices/pci:00/:00:1c.3/:03:00.0/usb3/uevent pid=25427 comm=qemu-system-x86 requested_mask=r denied_mask=r fsuid=106 ouid=0 Nov 23 00:28:39 uvir kernel: [35109.848799] audit: type=1400 audit(1416698919.255:182): apparmor=DENIED operation=open profile=libvirt-30619811-d285-944a-026a-cdd4a753b77a name=/sys/devices/pci:00/:00:1c.3/:03:00.0/usb3/3-0:1.0/uevent pid=25427 comm=qemu-system-x86 requested_mask=r denied_mask=r fsuid=106 ouid=0 Nov 23 00:28:39 uvir kernel: [35109.848815] audit: type=1400 audit(1416698919.255:183): apparmor=DENIED operation=open profile=libvirt-30619811-d285-944a-026a-cdd4a753b77a name=/sys/devices/pci:00/:00:1c.3/:03:00.0/usb4/uevent pid=25427 comm=qemu-system-x86 requested_mask=r denied_mask=r fsuid=106 ouid=0 Nov 23 00:28:39 uvir kernel: [35109.848831] audit: type=1400 audit(1416698919.255:184): apparmor=DENIED operation=open profile=libvirt-30619811-d285-944a-026a-cdd4a753b77a name=/sys/devices/pci:00/:00:1c.3/:03:00.0/usb4/4-0:1.0/uevent pid=25427 comm=qemu-system-x86 requested_mask=r denied_mask=r fsuid=106 ouid=0 Nov 23 00:28:39 uvir kernel: [35109.848847] audit: type=1400 audit(1416698919.255:185): apparmor=DENIED operation=open profile=libvirt-30619811-d285-944a-026a-cdd4a753b77a name=/sys/devices/pci:00/:00:1c.3/:03:00.0/usb4/4-2/uevent pid=25427 comm=qemu-system-x86 requested_mask=r denied_mask=r fsuid=106 ouid=0 Nov 23 09:07:11 uvir kernel: [ 33.270565] audit: type=1400 audit(1416730031.240:59): apparmor=DENIED operation=open profile=libvirt-717d41d2-cfc9-5d70-e2f5-817c2ed1a90a name=/sys/devices/pci:00/:00:1c.3/:03:00.0/usb3/uevent pid=3599 comm=qemu-system-x86 requested_mask=r denied_mask=r fsuid=106 ouid=0 Nov 23 09:07:11 uvir kernel: [ 33.270588] audit: type=1400 audit(1416730031.240:60): apparmor=DENIED operation=open profile=libvirt-717d41d2-cfc9-5d70-e2f5-817c2ed1a90a name=/sys/devices/pci:00/:00:1c.3/:03:00.0/usb3/3-0:1.0/uevent pid=3599 comm=qemu-system-x86 requested_mask=r denied_mask=r fsuid=106 ouid=0 Nov 23 09:07:11 uvir kernel: [ 33.270606] audit: type=1400 audit(1416730031.240:61): apparmor=DENIED operation=open profile=libvirt-717d41d2-cfc9-5d70-e2f5-817c2ed1a90a name=/sys/devices/pci:00/:00:1c.3/:03:00.0/usb4/uevent pid=3599 comm=qemu-system-x86 requested_mask=r denied_mask=r fsuid=106 ouid=0 Nov 23 09:07:11 uvir kernel: [ 33.270625] audit: type=1400 audit(1416730031.240:62): apparmor=DENIED operation=open profile=libvirt-717d41d2-cfc9-5d70-e2f5-817c2ed1a90a name=/sys/devices/pci:00/:00:1c.3/:03:00.0/usb4/4-0:1.0/uevent pid=3599 comm=qemu-system-x86 requested_mask=r denied_mask=r fsuid=106 ouid=0 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1392504 Title: USB Passthrough is not working anymore Status in QEMU: New Status in “qemu” package in Ubuntu: Incomplete Bug description: After upgrading from Ubuntu 14.04 to Ubuntu 14.10 USB passthrough
[Qemu-devel] [Bug 1395217] Re: Networking in qemu 2.0.0 and beyond is not compatible with Open Solaris (Illumos) 5.11
Paolo - I should have some time to do that this week, as well as bone up on git (it's been a bit . . .) And thanks for the quick reply! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1395217 Title: Networking in qemu 2.0.0 and beyond is not compatible with Open Solaris (Illumos) 5.11 Status in QEMU: New Bug description: The networking code in qemu in versions 2.0.0 and beyond is non- functional with Solaris/Illumos 5.11 images. Building 1.7.1, 2.0.0, 2.0.2, 2.1.2,and 2.2.0rc1with the following standard Slackware config: # From Slackware build tree . . . ./configure \ --prefix=/usr \ --libdir=/usr/lib64 \ --sysconfdir=/etc \ --localstatedir=/var \ --enable-gtk \ --enable-system \ --enable-kvm \ --disable-debug-info \ --enable-virtfs \ --enable-sdl \ --audio-drv-list=alsa,oss,sdl,esd \ --enable-libusb \ --disable-vnc \ --target-list=x86_64-linux-user,i386-linux-user,x86_64-softmmu,i386-softmmu \ --enable-spice \ --enable-usb-redir And attempting to run the same VM image with the following command (or via virt-manager): macaddress=DE:AD:BE:EF:3F:A4 qemu-system-x86_64 nex4x -cdrom /dev/cdrom -name Nex41 -cpu Westmere -machine accel=kvm -smp 2 -m 4000 -net nic,macaddr=$macaddress -net bridge,br=b r0 -net dump,file=/usr1/tmp/FILENAME -drive file=nex4x_d1 -drive file=nex4x_d2 -enable-kvm Gives success on 1.7.1, and a deaf VM on all subsequent versions. Notable in validating my config, is that a Windows 7 image runs cleanly with networking on *all* builds, so my configuration appears to be good - qemu just hates Solaris at this point. Watching with wireshark (as well as pulling network traces from qemu as noted above) it appears that the notable difference in the two configs is that for some reason, Solaris gets stuck arping for it's own interface on startup, and never really comes on line on the network. If other hosts attempt to ping the Solaris instance, they can successfully arp the bad VM, but not the other way around. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1395217/+subscriptions
Re: [Qemu-devel] [v5][PATCH 0/4] xen: introduce new machine for IGD passthrough
On 2014/11/23 18:10, Michael S. Tsirkin wrote: On Tue, Aug 12, 2014 at 05:49:13PM +0800, Tiejun Chen wrote: v5: * Simplify to make sure its really inherited from the standard one in patch #3 * Then drop the original patch #3 I carried i440fx: make types configurable at run-time pc_init1: pass parameters just with types xen:hw:pci-host:piix: create host bridge to passthrough qom-test: blacklist xenigd xen:hw:i386:pc_piix: introduce new machine for IGD passthrough on my branch for a while now, but I'm not sure it's all still needed. They may not be necessary since you and Paolo already are fine to live without that separate machine specific to IGD passthrough. If yes simply include these patches next time you repost the patchset. Anyway, I will comment this point once I can issue next revision. Thanks for your reminder. Tiejun
Re: [Qemu-devel] [v2 2/2] migration: Implement multiple compression threads
# @auto-converge: If enabled, QEMU will automatically throttle down the
guest
# to speed up convergence of RAM migration. (since 1.6)
#
# Since: 1.2
##
{ 'enum': 'MigrationCapability',
- 'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks']
}
+ 'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks',
+ 'compress'] }
I'll repeat what I said on v1 (but this time, with some links to back it up :)
We really need to avoid a proliferation of new commands, two per tunable does
not scale well. I think now is the time to implement my earlier suggestion
at making MigrationCapability become THE resource for tunables:
https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg02274.html
Hi, Eric
I have read your proposal, and I just want to verify if I got it
exactly. Take the 'compresss-level' parameter for example, according to you
suggestion, should I implement a command 'set-migrate-capability compress-level
1', or 'set-migrate-parameter compress-level 1' ? if it's the former, how to
keep the HMP back compatibility, as you know, the current HMP framework will
check the parameter type, the 'int' will be processed differently from 'bool',
; if it's the latter, it seems like a ' query-migrate-paramer ' command
should be provided to keep consistency, not query-migrate-capability.
Liang
[Qemu-devel] [PATCH] target-s390x: fix possible out of bounds read
Array index starts at 0, so the valid index of ext_queue array,
io_queue array, mchk_queue array should be MAX_EXT_QUEUE - 1,
MAX_IO_QUEUE - 1, MAX_MCHK_QUEUE - 1.
The original checks missed the invalid bound value, which will lead
possible out of bounds read in the follow codes.
Signed-off-by: zhanghailiang zhang.zhanghaili...@huawei.com
---
target-s390x/helper.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/target-s390x/helper.c b/target-s390x/helper.c
index 09aec7b..96a4f22 100644
--- a/target-s390x/helper.c
+++ b/target-s390x/helper.c
@@ -648,7 +648,7 @@ static void do_ext_interrupt(CPUS390XState *env)
cpu_abort(CPU(cpu), Ext int w/o ext mask\n);
}
-if (env-ext_index 0 || env-ext_index MAX_EXT_QUEUE) {
+if (env-ext_index 0 || env-ext_index = MAX_EXT_QUEUE) {
cpu_abort(CPU(cpu), Ext queue overrun: %d\n, env-ext_index);
}
@@ -696,7 +696,7 @@ static void do_io_interrupt(CPUS390XState *env)
if (env-io_index[isc] 0) {
continue;
}
-if (env-io_index[isc] MAX_IO_QUEUE) {
+if (env-io_index[isc] = MAX_IO_QUEUE) {
cpu_abort(CPU(cpu), I/O queue overrun for isc %d: %d\n,
isc, env-io_index[isc]);
}
@@ -754,7 +754,7 @@ static void do_mchk_interrupt(CPUS390XState *env)
cpu_abort(CPU(cpu), Machine check w/o mchk mask\n);
}
-if (env-mchk_index 0 || env-mchk_index MAX_MCHK_QUEUE) {
+if (env-mchk_index 0 || env-mchk_index = MAX_MCHK_QUEUE) {
cpu_abort(CPU(cpu), Mchk queue overrun: %d\n, env-mchk_index);
}
--
1.7.12.4
[Qemu-devel] configure options of qemu
Hi all, Thank you for your time to read this email, is there anyone can tell me the options qemu was configured when it was released? I configured it by myself and found that there was a audio latency problem, but the qemu in the repository doesn't have this problem, so i want to kown about its configuration options. the options i using is as below: ./configure --enable-spice --enable-usb-redir --enable-kvm --disable-werror --prefix=/home/stone/qemu --target-list=x86_64-softmmu --audio-card-list=ac97,es1370,sb16,cs4231a,adlib,gus,hda,ich6 --audio-drv-list=pa,alsa,sdl,oss Best Regards stone
Re: [Qemu-devel] configure options of qemu
the qemu command is as below: qemu-system-x86_64 -machine accel=kvm:tcg -m 4096 -smp 4 -M pc-i440fx-1.4 -spi ce port=5906,addr=0.0.0.0,disable-ticketing,jpeg-wan-compression=always -vga qxl -global qxl-vga.vram_size=268435456 /opt/instances/win7_sh_2.1.1_driver.qcow2 -net nic,macaddr=00:16:3e:00:00:04,model=virtio -net tap,ifname=tap04 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 At 2014-11-24 10:49:30, li lijiamin...@163.com wrote: Hi all, Thank you for your time to read this email, is there anyone can tell me the options qemu was configured when it was released? I configured it by myself and found that there was a audio latency problem, but the qemu in the repository doesn't have this problem, so i want to kown about its configuration options. the options i using is as below: ./configure --enable-spice --enable-usb-redir --enable-kvm --disable-werror --prefix=/home/stone/qemu --target-list=x86_64-softmmu --audio-card-list=ac97,es1370,sb16,cs4231a,adlib,gus,hda,ich6 --audio-drv-list=pa,alsa,sdl,oss Best Regards stone
Re: [Qemu-devel] [RESEND PATCH V3] qemu-img info: show nocow info
On 11/22/2014 at 12:25 AM, in message
20141121162505.gf3...@noname.redhat.com, Kevin Wolf kw...@redhat.com wrote:
Am 30.07.2014 um 04:55 hat Chunyan Liu geschrieben:
Add nocow info in 'qemu-img info' output to show whether the file
currently has NOCOW flag set or not.
Signed-off-by: Chunyan Liu cy...@suse.com
Reviewed-by: Eric Blake ebl...@redhat.com
---
Resend for QEMU 2.2. Change json version comment. Add Reviewed-by.
block/qapi.c | 25 +
qapi/block-core.json | 5 -
2 files changed, 29 insertions(+), 1 deletion(-)
Unfortunately, I have never been CCed on this patch and I saw the code
it added only now. I think it doesn't work correctly and has the wrong
design, so I would prefer to revert it for 2.2 rather than making a bad
API stable.
diff --git a/block/qapi.c b/block/qapi.c
index f44f6b4..aa53f19 100644
--- a/block/qapi.c
+++ b/block/qapi.c
@@ -28,6 +28,13 @@
#include qapi-visit.h
#include qapi/qmp-output-visitor.h
#include qapi/qmp/types.h
+#ifdef __linux__
+#include linux/fs.h
+#include sys/ioctl.h
+#ifndef FS_NOCOW_FL
+#define FS_NOCOW_FL 0x0080 /* Do not cow file */
+#endif
+#endif
BlockDeviceInfo *bdrv_block_device_info(BlockDriverState *bs)
{
@@ -173,6 +180,20 @@ void bdrv_query_image_info(BlockDriverState *bs,
Error *err = NULL;
ImageInfo *info = g_new0(ImageInfo, 1);
+#ifdef __linux__
+int fd, attr;
+
+/* get NOCOW info */
+fd = qemu_open(bs-filename, O_RDONLY | O_NONBLOCK);
+if (fd = 0) {
+if (ioctl(fd, FS_IOC_GETFLAGS, attr) == 0 (attr
FS_NOCOW_FL)) {
+info-has_nocow = true;
+info-nocow = true;
+}
+qemu_close(fd);
+}
+#endif
Code like this has no business in the general block layer. This belongs
in raw-posix, which already has an open fd, and nowhere else. There you
wouldn't have to rely on bs-filename, which may be empty or contain
something different from a local filename, e.g. a URL. The approach of
this patch also doesn't work if the file has been renamed or deleted
since qemu opened it (e.g. because of -snapshot).
In short: This code may happen to work in some special cases, but
generally speaking, it is wrong.
bdrv_get_geometry(bs, total_sectors);
info-filename= g_strdup(bs-filename);
@@ -625,4 +646,8 @@ void bdrv_image_info_dump(fprintf_function
func_fprintf,
void *f,
func_fprintf(f, Format specific information:\n);
bdrv_image_info_specific_dump(func_fprintf, f,
info-format_specific);
}
+
+if (info-has_nocow info-nocow) {
+func_fprintf(f, NOCOW flag: set\n);
+}
}
diff --git a/qapi/block-core.json b/qapi/block-core.json
index e378653..72b4015 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -115,6 +115,8 @@
# @format-specific: #optional structure supplying additional
format-specific
# information (since 1.7)
#
+# @nocow: #optional info of whether NOCOW flag is set or not. (since 2.2)
+#
# Since: 1.3
#
##
@@ -126,7 +128,8 @@
'*backing-filename': 'str', '*full-backing-filename': 'str',
'*backing-filename-format': 'str', '*snapshots':
['SnapshotInfo'],
'*backing-image': 'ImageInfo',
- '*format-specific': 'ImageInfoSpecific' } }
+ '*format-specific': 'ImageInfoSpecific',
+ '*nocow': 'bool' } }
As this field makes only sense for raw-posix, it should be moved to
ImageInfoSpecific. (format-specific is also an unfortunate misnomer,
it should be driver-specific, but it's too late to fix that.
I'm not disagreeing revert this patch if there is mistake. But here I need
to add some explanation to seek a correct future solution:
'Nocow' is not a specific attribute to raw-posix. This option is valid
to general disk images types, like 'raw', 'qcow2', 'qcow', 'vhdx', 'vpc',
'vmdk', etc. The reason why we only add 'nocow' in .createoptions in
raw-posix.c is: when creating all those file types, the creating point
is always in raw-posix.c, and since the NOCOW attr must be handled
in creating point, so we can only handle it in raw-posix.c file.
That's why we only add 'nocow' to raw-posix.c, but not other file types.
In creating, it will append two createoptions (like creating qcow2 file,
it will append qcow2 createoptions and also raw_posix createoptions),
so add 'nocow' to raw-posix is enough. Add 'nocow' to each file types
will touch many files.
- Chunyan
Kevin
[Qemu-devel] [PATCH] hw/arm/boot: fix uninitialized scalar variable warning reported by coverity
Coverity reports the 'size' may be used uninitialized, but that can't happen,
because the caller has checked if (binfo-dtb_filename || binfo-get_dtb)
before call 'load_dtb'.
Here we simply remove the 'if (binfo-get_dtb)' to satisfy coverity.
Signed-off-by: zhanghailiang zhang.zhanghaili...@huawei.com
---
hw/arm/boot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/arm/boot.c b/hw/arm/boot.c
index 0014c34..4f515b5 100644
--- a/hw/arm/boot.c
+++ b/hw/arm/boot.c
@@ -352,7 +352,7 @@ static int load_dtb(hwaddr addr, const struct arm_boot_info
*binfo,
goto fail;
}
g_free(filename);
-} else if (binfo-get_dtb) {
+} else {
fdt = binfo-get_dtb(binfo, size);
if (!fdt) {
fprintf(stderr, Board was unable to create a dtb blob\n);
--
1.7.12.4
Re: [Qemu-devel] How to access guest memory from qemu device internal
-Origin email- From: Peter Maydell peter.mayd...@linaro.org Sent Time: Monday, November 24, 2014 To: Kaiyuan kaiyu...@tju.edu.cn Cc: Greg Kurz gk...@linux.vnet.ibm.com, qemu-devel qemu-devel@nongnu.org Subject: Re: [Qemu-devel] How to access guest memory from qemu device internal On 23 November 2014 at 13:18, Kaiyuan kaiyu...@tju.edu.cn wrote: Thanks for your explanation about guest physical/virtual address and host physical/virtual address, and I think I asked a wrong question. Is there a function that translates guest Physical address to host Virtual address so that I can access guest space by a host pointer? You can use cpu_physical_memory_map() and _unmap() for this kind of thing. (Make sure you unmap afterwards.) -- PMM Thank you very much for your help!Kaiyuan Liang
Re: [Qemu-devel] [Qemu-ppc] [PATCH V2 0/3] spapr: Fix stale HTAB during live migration
On 11/17/2014 11:26 PM, Alexander Graf wrote: Am 17.11.2014 um 05:12 schrieb Samuel Mendoza-Jonas sam...@au1.ibm.com: If a spapr guest reboots during a live migration, the guest HTAB on the destination is not updated properly, usually resulting in a kernel panic. This is a (delayed!) follow up to my previous patch including a fix for TCG guests as well as KVM. Changes from V1: - Split out overflow fix into separate patch - Removed unnecessary locks (relevant operations occur under BQL) - TCG: Set HTAB dirty instead of resetting migration state - Minor style fixes Looks great to me, but I would like to get a reviewed-by from Alexey as well ;) Looks good to me too. Reviewed-by: Alexey Kardashevskiy a...@ozlabs.ru Alex Samuel Mendoza-Jonas (3): spapr: Fix stale HTAB during live migration (KVM) spapr: Fix integer overflow during migration (TCG) spapr: Fix stale HTAB during live migration (TCG) hw/ppc/spapr.c | 60 +++--- include/hw/ppc/spapr.h | 1 + 2 files changed, 53 insertions(+), 8 deletions(-) -- 1.9.3 -- Alexey
