Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code
On Mon, May 27, 2013 at 11:14:47AM -0500, Anthony Liguori wrote: Well specifically if_ether.h says GPLv2+ so it's OK for QEMU. Do you mean for some other non GPL app? Ignore QEMU for the moment. The headers say they are BSD licensed... but they include a GPLv2+ header. Above is a bit misleading. To be precise, they don't include a GPLv2+ header. One header merely includes this line: #include linux/if_ether.h -- MST
Re: [Qemu-devel] [PATCH] rtl8139: flush queued packets when RxBufPtr is written
On 27.05.2013 17:29, Stefan Hajnoczi wrote: On Mon, May 27, 2013 at 04:24:59PM +0200, Peter Lieven wrote: On 27.05.2013 16:07, Oliver Francke wrote: Well, Am 27.05.2013 um 08:15 schrieb Peter Lieven lieven-li...@dlhnet.de: Hi all, I ocassionally have seen a probably related problem in the past. It mainly happend with rtl8139 under WinXP where we most likely use rtl8139 due to lack of shipped e1000 drivers. My question is if you see increasing dropped packets on the tap device if this problem occurs? tap36 Link encap:Ethernet HWaddr b2:84:23:c0:e2:c0 inet6 addr: fe80::b084:23ff:fec0:e2c0/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:5816096 errors:0 dropped:0 overruns:0 frame:0 TX packets:3878744 errors:0 dropped:13775 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:5161769434 (5.1 GB) TX bytes:380415916 (380.4 MB) In my case as well the only option to recover without shutting down the whole vServer is Live Migration to another Node. ACK, tried it and every network-devices might have been re-created into a defined state qemu-wise. However, I also see this problem under qemu-kvm-1.2.0 while Oliver reported it does not happen there. Neither me nor any affected customers have ever seen such failures in qemu-1.2.0, so this was my last-known-good ;) I cherry-picked net: add receive_disabled logic to iov delivery path This one exposes the bug that Oliver reported: commit a9d8f7b1c41a8a346f4cf5a0c6963a79fbd1249e Author: Stefan Hajnoczi stefa...@linux.vnet.ibm.com Date: Mon Aug 20 13:35:23 2012 +0100 net: do not report queued packets as sent This was also in the series I cherry-picked for my 1.2.0 build. So its likely I hit the same bug. Thank you, Peter
Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
On Tue, May 28, 2013 at 08:21:24AM +0800, li guang wrote: 在 2013-05-27一的 23:23 +0300，Michael S. Tsirkin写道： On Mon, May 27, 2013 at 09:22:59AM +0800, li guang wrote: 在 2013-05-26日的 19:51 -0500，Anthony Liguori写道： li guang lig.f...@cn.fujitsu.com writes: 在 2013-05-24五的 14:45 +0300，Michael S. Tsirkin写道： On Wed, May 22, 2013 at 11:46:33AM +0800, liguang wrote: These patches try to add ACPI Embedded Controller (EC), refer-to: ACPI SPEC v5 chapter 5 ACPI Embedded Controller Interface Specification EC is a standard ACPI device, it plays flexible roles, e.g. power controller, it can control power sequence for platform to enter or leave system state(0,1,3,4,5), it can controller CPU fan by the temperature of sensor. event carrier, it can pass events between platform and OS, so OS can execute _Qxx method which defined by yourself. So, I want to deliver CPU online/offline event between OS and QEMU for CPU hotplug feature, then we will don't need to echo 1 /sys/devices/system/cpu/cpu1/online again after 'cpu-add'. patches for online/offline event handler of QEUM and linux kernel are writing, and will send once finished. since EC is a common device, so I send pathes separately. Do any non-linux guests support this device? In fact, any OSes support ACPI will support this device. so, windows will. When you say any OSes supporting ACPI I think what you really mean is that we can provide bytecode that interacts with the embedded controller. There is not explicit driver in Linux or Windows AFAIK. Hmm, yep, mostly there's no special driver for EC, because it is directly embedded in code for ACPI for linux kernel, it's drivers/acpi/ec.c I still don't get the point of this. We can make ACPI hotplug work without introducing a new device like this. when you 'cpu-add' a cpu, acpi driver for cpu will not trigger 'cpu_up' for linux kernel AFAIK, unless you add a user space program to listen it's uevent and tigger 'cpu_up'. and EC is not only for ACPI hotplug for example, the 'pvpanic', if there's a EC, we can pass pvpanic event by EC's ACPI space or Q-event, then we will not need this kind of special devices anymore. So just to clarify: this patchset doesn't do anything useful itself, the first patch is pure EC implementation which is useful. Sorry, I didn't mean to imply that this is not useful, merely that it is not yet directly useful for users. it's some infrastructure that you want to build on top of? Yes, I'd like to use EC as infrastructure for my further development. I (and apparently others in this thread) would like to know some more about planned use for this code before deciding on inclusion. -- MST
[Qemu-devel] [PATCH 2/2] chardev: fix info chardev output
Fill unset CharDriverState-filename with the backend name, so
'info chardev' will return at least the chardev type. Don't
touch it in case the chardev init function filled it already,
like the socket+pty chardevs do for example.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
qemu-char.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/qemu-char.c b/qemu-char.c
index f825294..d04b429 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -3801,6 +3801,9 @@ ChardevReturn *qmp_chardev_add(const char *id,
ChardevBackend *backend,
chr-label = g_strdup(id);
chr-avail_connections =
(backend-kind == CHARDEV_BACKEND_KIND_MUX) ? MAX_MUX : 1;
+if (!chr-filename) {
+chr-filename = g_strdup(ChardevBackendKind_lookup[backend-kind]);
+}
QTAILQ_INSERT_TAIL(chardevs, chr, next);
return ret;
} else {
--
1.7.9.7
[Qemu-devel] [PULL 0/2] chardev: fix info chardev output
Hi, Tiny series, first reverting the broken patch from Lei Li, then fixing it for real. please pull, Gerd The following changes since commit 6a4e17711442849bf2cc731ccddef5a2a2d92d29: Remove Sun4c, Sun4d and a few CPUs (2013-05-26 11:37:58 +) are available in the git repository at: git://git.kraxel.org/qemu chardev.6 for you to fetch changes up to 60d95386abf1f5f37ded6a812d12ac458df2491b: chardev: fix info chardev output (2013-05-27 12:47:28 +0200) Gerd Hoffmann (2): Revert chardev: Get filename for new qapi backend chardev: fix info chardev output qemu-char.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
[Qemu-devel] [PATCH 1/2] Revert chardev: Get filename for new qapi backend
Does not handle chardevs created via chardev-add monitor command.
This reverts commit 2b220025993e76d4116781ca91a4fabc5ad9c722.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
qemu-char.c |2 --
1 file changed, 2 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index 4f8382e..f825294 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -3276,7 +3276,6 @@ CharDriverState *qemu_chr_new_from_opts(QemuOpts *opts,
ChardevReturn *ret = NULL;
const char *id = qemu_opts_id(opts);
const char *bid = NULL;
-char *filename = g_strdup(qemu_opt_get(opts, backend));
if (qemu_opt_get_bool(opts, mux, 0)) {
bid = g_strdup_printf(%s-base, id);
@@ -3309,7 +3308,6 @@ CharDriverState *qemu_chr_new_from_opts(QemuOpts *opts,
}
chr = qemu_chr_find(id);
-chr-filename = filename;
qapi_out:
qapi_free_ChardevBackend(backend);
--
1.7.9.7
Re: [Qemu-devel] [PATCH 1/3] qemu_chr_new_from_opts: do not overwrite existing chr-filename
On 05/27/13 20:13, Stefano Stabellini wrote: Set the new filename only if it hasn't been already set (for example by qemu_chr_open_pty). This fixes a regression that prevents Xen HVM domains from booting. It was introduced by: commit 2b220025993e76d4116781ca91a4fabc5ad9c722 Author: Lei Li li...@linux.vnet.ibm.com Date: Tue May 21 18:27:59 2013 +0800 FYI: just posted a pull req which reverts this one (you are cc'ed). cheers, Gerd
Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
Hi, Michael 在 2013-05-28二的 09:31 +0300，Michael S. Tsirkin写道： On Tue, May 28, 2013 at 08:21:24AM +0800, li guang wrote: 在 2013-05-27一的 23:23 +0300，Michael S. Tsirkin写道： On Mon, May 27, 2013 at 09:22:59AM +0800, li guang wrote: 在 2013-05-26日的 19:51 -0500，Anthony Liguori写道： li guang lig.f...@cn.fujitsu.com writes: 在 2013-05-24五的 14:45 +0300，Michael S. Tsirkin写道： On Wed, May 22, 2013 at 11:46:33AM +0800, liguang wrote: These patches try to add ACPI Embedded Controller (EC), refer-to: ACPI SPEC v5 chapter 5 ACPI Embedded Controller Interface Specification EC is a standard ACPI device, it plays flexible roles, e.g. power controller, it can control power sequence for platform to enter or leave system state(0,1,3,4,5), it can controller CPU fan by the temperature of sensor. event carrier, it can pass events between platform and OS, so OS can execute _Qxx method which defined by yourself. So, I want to deliver CPU online/offline event between OS and QEMU for CPU hotplug feature, then we will don't need to echo 1 /sys/devices/system/cpu/cpu1/online again after 'cpu-add'. patches for online/offline event handler of QEUM and linux kernel are writing, and will send once finished. since EC is a common device, so I send pathes separately. Do any non-linux guests support this device? In fact, any OSes support ACPI will support this device. so, windows will. When you say any OSes supporting ACPI I think what you really mean is that we can provide bytecode that interacts with the embedded controller. There is not explicit driver in Linux or Windows AFAIK. Hmm, yep, mostly there's no special driver for EC, because it is directly embedded in code for ACPI for linux kernel, it's drivers/acpi/ec.c I still don't get the point of this. We can make ACPI hotplug work without introducing a new device like this. when you 'cpu-add' a cpu, acpi driver for cpu will not trigger 'cpu_up' for linux kernel AFAIK, unless you add a user space program to listen it's uevent and tigger 'cpu_up'. and EC is not only for ACPI hotplug for example, the 'pvpanic', if there's a EC, we can pass pvpanic event by EC's ACPI space or Q-event, then we will not need this kind of special devices anymore. So just to clarify: this patchset doesn't do anything useful itself, the first patch is pure EC implementation which is useful. Sorry, I didn't mean to imply that this is not useful, merely that it is not yet directly useful for users. Yep, by now, of course, only 1 user, that's me. :-) it's some infrastructure that you want to build on top of? Yes, I'd like to use EC as infrastructure for my further development. I (and apparently others in this thread) would like to know some more about planned use for this code before deciding on inclusion. OK, currently, I am using EC to pass cpu hotplug event between QEMU and linux kernel, and I'll post these patches later. then, I'll query usages like this in QEMU, and convert them to use EC's acpi approach if possible. Thanks!
Re: [Qemu-devel] [PATCH 3/4] ich9: add notifer for ec to generate sci
On Wed, May 22, 2013 at 11:46:36AM +0800, liguang wrote:
Signed-off-by: liguang lig.f...@cn.fujitsu.com
---
hw/acpi/ich9.c | 15 +++
include/hw/acpi/ich9.h |1 +
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index 582dbec..2ecde32 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -33,6 +33,7 @@
#include exec/address-spaces.h
#include hw/i386/ich9.h
+#include hw/acpi/ec.h
//#define DEBUG
@@ -43,6 +44,8 @@ do { printf(%s fmt, __func__, ## __VA_ARGS__); } while (0)
#define ICH9_DEBUG(fmt, ...)do { } while (0)
#endif
+#define GPE_EC_SCI_STATUS (0x1 (16 + 1))
+
static void pm_update_sci(ICH9LPCPMRegs *pm)
{
int sci_level, pm1a_sts;
@@ -202,6 +205,15 @@ static void pm_powerdown_req(Notifier *n, void *opaque)
acpi_pm1_evt_power_down(pm-acpi_regs);
}
+static void pm_ec_sci_req(Notifier *n, void *opaque)
+{
+ICH9LPCPMRegs *pm = container_of(n, ICH9LPCPMRegs, ec_sci_notifier);
+ACPIGPE *gpe = pm-acpi_regs.gpe;
+
+*gpe-sts |= GPE_EC_SCI_STATUS;
+pm_update_sci(pm);
+}
+
void ich9_pm_init(PCIDevice *lpc_pci, ICH9LPCPMRegs *pm,
qemu_irq sci_irq)
{
@@ -227,4 +239,7 @@ void ich9_pm_init(PCIDevice *lpc_pci, ICH9LPCPMRegs *pm,
qemu_register_reset(pm_reset, pm);
pm-powerdown_notifier.notify = pm_powerdown_req;
qemu_register_powerdown_notifier(pm-powerdown_notifier);
+
+pm-ec_sci_notifier.notify = pm_ec_sci_req;
+qemu_register_ec_sci_notifier(pm-ec_sci_notifier);
}
So an EC is using ICH9 to send SCI to guest,
but ICH9 should not worry about EC that's connected to it.
So it should be something like
qemu_register_sci_notifier
and not make ich9 depend on ec.
diff --git a/include/hw/acpi/ich9.h b/include/hw/acpi/ich9.h
index b1fe71f..f358deb 100644
--- a/include/hw/acpi/ich9.h
+++ b/include/hw/acpi/ich9.h
@@ -42,6 +42,7 @@ typedef struct ICH9LPCPMRegs {
uint32_t pm_io_base;
Notifier powerdown_notifier;
+Notifier ec_sci_notifier;
} ICH9LPCPMRegs;
void ich9_pm_init(PCIDevice *lpc_pci, ICH9LPCPMRegs *pm,
--
1.7.2.5
[Qemu-devel] [PATCH] block: add read only to whitelist
We may want to include a driver in the whitelist for read only tasks
such as diagnosing or exporting guest data (with libguestfs as a good
example). This patch introduces the magic prefix ^ to include a driver
to the whitelist, but only enables qemu to open specific image
format readonly, and returns -ENOTSUP for RW opening.
Example: To include vmdk readonly, and others read+write:
./configure --block-drv-whitelist=qcow2,raw,file,qed,^vmdk
Signed-off-by: Fam Zheng f...@redhat.com
---
block.c | 43 +++
blockdev.c| 4 ++--
configure | 2 ++
include/block/block.h | 3 ++-
scripts/create_config | 9 -
5 files changed, 41 insertions(+), 20 deletions(-)
diff --git a/block.c b/block.c
index 3f87489..e6a7270 100644
--- a/block.c
+++ b/block.c
@@ -328,28 +328,40 @@ BlockDriver *bdrv_find_format(const char *format_name)
return NULL;
}
-static int bdrv_is_whitelisted(BlockDriver *drv)
+static int bdrv_is_whitelisted(BlockDriver *drv, bool read_only)
{
-static const char *whitelist[] = {
-CONFIG_BDRV_WHITELIST
+static const char *whitelist_rw[] = {
+CONFIG_BDRV_WHITELIST_RW
+};
+static const char *whitelist_ro[] = {
+CONFIG_BDRV_WHITELIST_RO
};
const char **p;
-if (!whitelist[0])
+if (!whitelist_rw[0] !whitelist_ro[0]) {
return 1; /* no whitelist, anything goes */
+}
-for (p = whitelist; *p; p++) {
+for (p = whitelist_rw; *p; p++) {
if (!strcmp(drv-format_name, *p)) {
return 1;
}
}
+if (read_only) {
+for (p = whitelist_ro; *p; p++) {
+if (!strcmp(drv-format_name, *p)) {
+return 1;
+}
+}
+}
return 0;
}
-BlockDriver *bdrv_find_whitelisted_format(const char *format_name)
+BlockDriver *bdrv_find_whitelisted_format(const char *format_name,
+ bool read_only)
{
BlockDriver *drv = bdrv_find_format(format_name);
-return drv bdrv_is_whitelisted(drv) ? drv : NULL;
+return drv bdrv_is_whitelisted(drv, read_only) ? drv : NULL;
}
typedef struct CreateCo {
@@ -684,10 +696,6 @@ static int bdrv_open_common(BlockDriverState *bs,
BlockDriverState *file,
trace_bdrv_open_common(bs, filename ?: , flags, drv-format_name);
-if (use_bdrv_whitelist !bdrv_is_whitelisted(drv)) {
-return -ENOTSUP;
-}
-
/* bdrv_open() with directly using a protocol as drv. This layer is already
* opened, so assign it to bs (while file becomes a closed
BlockDriverState)
* and return immediately. */
@@ -698,9 +706,15 @@ static int bdrv_open_common(BlockDriverState *bs,
BlockDriverState *file,
bs-open_flags = flags;
bs-buffer_alignment = 512;
+open_flags = bdrv_open_flags(bs, flags);
+bs-read_only = !(open_flags BDRV_O_RDWR);
+
+if (use_bdrv_whitelist !bdrv_is_whitelisted(drv, bs-read_only)) {
+return -ENOTSUP;
+}
assert(bs-copy_on_read == 0); /* bdrv_new() and bdrv_close() make it so */
-if ((flags BDRV_O_RDWR) (flags BDRV_O_COPY_ON_READ)) {
+if (!bs-read_only (flags BDRV_O_COPY_ON_READ)) {
bdrv_enable_copy_on_read(bs);
}
@@ -714,9 +728,6 @@ static int bdrv_open_common(BlockDriverState *bs,
BlockDriverState *file,
bs-opaque = g_malloc0(drv-instance_size);
bs-enable_write_cache = !!(flags BDRV_O_CACHE_WB);
-open_flags = bdrv_open_flags(bs, flags);
-
-bs-read_only = !(open_flags BDRV_O_RDWR);
/* Open the image, either directly or using a protocol */
if (drv-bdrv_file_open) {
@@ -801,7 +812,7 @@ int bdrv_file_open(BlockDriverState **pbs, const char
*filename,
/* Find the right block driver */
drvname = qdict_get_try_str(options, driver);
if (drvname) {
-drv = bdrv_find_whitelisted_format(drvname);
+drv = bdrv_find_whitelisted_format(drvname, !(flags BDRV_O_RDWR));
qdict_del(options, driver);
} else if (filename) {
drv = bdrv_find_protocol(filename);
diff --git a/blockdev.c b/blockdev.c
index d1ec99a..b9b2d10 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -477,7 +477,7 @@ DriveInfo *drive_init(QemuOpts *all_opts,
BlockInterfaceType block_default_type)
error_printf(\n);
return NULL;
}
-drv = bdrv_find_whitelisted_format(buf);
+drv = bdrv_find_whitelisted_format(buf, ro);
if (!drv) {
error_report('%s' invalid format, buf);
return NULL;
@@ -1096,7 +1096,7 @@ void qmp_change_blockdev(const char *device, const char
*filename,
}
if (format) {
-drv = bdrv_find_whitelisted_format(format);
+drv = bdrv_find_whitelisted_format(format, bs-read_only);
if (!drv) {
error_set(errp, QERR_INVALID_BLOCK_FORMAT, format);
return;
diff --git a/configure b/configure
index
Re: [Qemu-devel] [PATCH 3/4] ich9: add notifer for ec to generate sci
在 2013-05-28二的 09:40 +0300，Michael S. Tsirkin写道：
On Wed, May 22, 2013 at 11:46:36AM +0800, liguang wrote:
Signed-off-by: liguang lig.f...@cn.fujitsu.com
---
hw/acpi/ich9.c | 15 +++
include/hw/acpi/ich9.h |1 +
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index 582dbec..2ecde32 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -33,6 +33,7 @@
#include exec/address-spaces.h
#include hw/i386/ich9.h
+#include hw/acpi/ec.h
//#define DEBUG
@@ -43,6 +44,8 @@ do { printf(%s fmt, __func__, ## __VA_ARGS__); } while
(0)
#define ICH9_DEBUG(fmt, ...)do { } while (0)
#endif
+#define GPE_EC_SCI_STATUS (0x1 (16 + 1))
+
static void pm_update_sci(ICH9LPCPMRegs *pm)
{
int sci_level, pm1a_sts;
@@ -202,6 +205,15 @@ static void pm_powerdown_req(Notifier *n, void *opaque)
acpi_pm1_evt_power_down(pm-acpi_regs);
}
+static void pm_ec_sci_req(Notifier *n, void *opaque)
+{
+ICH9LPCPMRegs *pm = container_of(n, ICH9LPCPMRegs, ec_sci_notifier);
+ACPIGPE *gpe = pm-acpi_regs.gpe;
+
+*gpe-sts |= GPE_EC_SCI_STATUS;
+pm_update_sci(pm);
+}
+
void ich9_pm_init(PCIDevice *lpc_pci, ICH9LPCPMRegs *pm,
qemu_irq sci_irq)
{
@@ -227,4 +239,7 @@ void ich9_pm_init(PCIDevice *lpc_pci, ICH9LPCPMRegs *pm,
qemu_register_reset(pm_reset, pm);
pm-powerdown_notifier.notify = pm_powerdown_req;
qemu_register_powerdown_notifier(pm-powerdown_notifier);
+
+pm-ec_sci_notifier.notify = pm_ec_sci_req;
+qemu_register_ec_sci_notifier(pm-ec_sci_notifier);
}
So an EC is using ICH9 to send SCI to guest,
but ICH9 should not worry about EC that's connected to it.
So it should be something like
qemu_register_sci_notifier
and not make ich9 depend on ec.
OK, let me think about it.
Thanks!
diff --git a/include/hw/acpi/ich9.h b/include/hw/acpi/ich9.h
index b1fe71f..f358deb 100644
--- a/include/hw/acpi/ich9.h
+++ b/include/hw/acpi/ich9.h
@@ -42,6 +42,7 @@ typedef struct ICH9LPCPMRegs {
uint32_t pm_io_base;
Notifier powerdown_notifier;
+Notifier ec_sci_notifier;
} ICH9LPCPMRegs;
void ich9_pm_init(PCIDevice *lpc_pci, ICH9LPCPMRegs *pm,
--
1.7.2.5
Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
On Tue, May 28, 2013 at 02:40:30PM +0800, li guang wrote: Hi, Michael 在 2013-05-28二的 09:31 +0300，Michael S. Tsirkin写道： On Tue, May 28, 2013 at 08:21:24AM +0800, li guang wrote: 在 2013-05-27一的 23:23 +0300，Michael S. Tsirkin写道： On Mon, May 27, 2013 at 09:22:59AM +0800, li guang wrote: 在 2013-05-26日的 19:51 -0500，Anthony Liguori写道： li guang lig.f...@cn.fujitsu.com writes: 在 2013-05-24五的 14:45 +0300，Michael S. Tsirkin写道： On Wed, May 22, 2013 at 11:46:33AM +0800, liguang wrote: These patches try to add ACPI Embedded Controller (EC), refer-to: ACPI SPEC v5 chapter 5 ACPI Embedded Controller Interface Specification EC is a standard ACPI device, it plays flexible roles, e.g. power controller, it can control power sequence for platform to enter or leave system state(0,1,3,4,5), it can controller CPU fan by the temperature of sensor. event carrier, it can pass events between platform and OS, so OS can execute _Qxx method which defined by yourself. So, I want to deliver CPU online/offline event between OS and QEMU for CPU hotplug feature, then we will don't need to echo 1 /sys/devices/system/cpu/cpu1/online again after 'cpu-add'. patches for online/offline event handler of QEUM and linux kernel are writing, and will send once finished. since EC is a common device, so I send pathes separately. Do any non-linux guests support this device? In fact, any OSes support ACPI will support this device. so, windows will. When you say any OSes supporting ACPI I think what you really mean is that we can provide bytecode that interacts with the embedded controller. There is not explicit driver in Linux or Windows AFAIK. Hmm, yep, mostly there's no special driver for EC, because it is directly embedded in code for ACPI for linux kernel, it's drivers/acpi/ec.c I still don't get the point of this. We can make ACPI hotplug work without introducing a new device like this. when you 'cpu-add' a cpu, acpi driver for cpu will not trigger 'cpu_up' for linux kernel AFAIK, unless you add a user space program to listen it's uevent and tigger 'cpu_up'. and EC is not only for ACPI hotplug for example, the 'pvpanic', if there's a EC, we can pass pvpanic event by EC's ACPI space or Q-event, then we will not need this kind of special devices anymore. So just to clarify: this patchset doesn't do anything useful itself, the first patch is pure EC implementation which is useful. Sorry, I didn't mean to imply that this is not useful, merely that it is not yet directly useful for users. Yep, by now, of course, only 1 user, that's me. :-) it's some infrastructure that you want to build on top of? Yes, I'd like to use EC as infrastructure for my further development. I (and apparently others in this thread) would like to know some more about planned use for this code before deciding on inclusion. OK, currently, I am using EC to pass cpu hotplug event between QEMU and linux kernel, and I'll post these patches later. then, I'll query usages like this in QEMU, and convert them to use EC's acpi approach if possible. Thanks! Okay, that needs an ack from Igor then I think :) -- MST
Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
于 2013-4-19 22:24, Paolo Bonzini 写道:
From: Nicholas Bellinger n...@linux-iscsi.org
The WWPN specified in configfs is passed to -device vhost-scsi-pci.
The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is not
available from the QEMU command-line. Instead, I hardcode it to zero.
Hi, Paolo
Any document about how to config it correctly in configfs, before
invoking qemu with the WWPN number?
Changes in Patch-v2:
- Add vhost_scsi_get_features() in order to determine feature bits
supports by host kernel (mst + nab)
- Re-enable usage of DEFINE_VIRTIO_COMMON_FEATURES, and allow
EVENT_IDX to be disabled by host in vhost_scsi_get_features()
- Drop unused hotplug bit in DEFINE_VHOST_SCSI_PROPERTIES
Changes in Patch-v1:
- Set event_idx=off by default (nab, thanks asias)
- Disable hotplug feature bit for v3.9 tcm_vhost kernel code, need to
re-enable in v3.10 (nab)
- Update to latest qemu.git/master HEAD
Changes in WIP-V3:
- Drop ioeventfd vhost_scsi_properties (asias, thanks stefanha)
- Add CONFIG_VHOST_SCSI (asias, thanks stefanha)
- Add hotplug feature bit
Changes in WIP-V2:
- Add backend guest masking support (nab)
- Bump ABI_VERSION to 1 (nab)
- Set up set_guest_notifiers (asias)
- Set up vs-dev.vq_index (asias)
- Drop vs-vs.vdev.{set,clear}_vhost_endpoint (asias)
- Drop VIRTIO_CONFIG_S_DRIVER check in vhost_scsi_set_status (asias)
Howto:
Use the latest seabios, at least commit b44a7be17b
git clone git://git.seabios.org/seabios.git
make
cp out/bios.bin /usr/share/qemu/bios.bin
qemu -device vhost-scsi-pci,wwpn=naa.6001405bd4e8476d
...
Cc: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org
Signed-off-by: Asias He as...@redhat.com
[ Rebase on top of VirtIOSCSICommon patch, fix bugs in feature
negotiation and irqfd masking - Paolo ]
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
configure | 10 ++
hw/scsi/Makefile.objs | 6 +-
hw/scsi/vhost-scsi.c| 288
include/hw/virtio/vhost-scsi.h | 73 ++
include/hw/virtio/virtio-scsi.h | 2 +
5 files changed, 378 insertions(+), 1 deletion(-)
create mode 100644 hw/scsi/vhost-scsi.c
create mode 100644 include/hw/virtio/vhost-scsi.h
diff --git a/configure b/configure
index ed49f91..51a6c56 100755
--- a/configure
+++ b/configure
@@ -179,6 +179,7 @@ libattr=
xfs=
vhost_net=no
+vhost_scsi=no
kvm=no
gprof=no
debug_tcg=no
@@ -543,6 +544,7 @@ Haiku)
usb=linux
kvm=yes
vhost_net=yes
+ vhost_scsi=yes
if [ $cpu = i386 -o $cpu = x86_64 ] ; then
audio_possible_drivers=$audio_possible_drivers fmod
fi
@@ -870,6 +872,10 @@ for opt do
;;
--enable-vhost-net) vhost_net=yes
;;
+ --disable-vhost-scsi) vhost_scsi=no
+ ;;
+ --enable-vhost-scsi) vhost_scsi=yes
+ ;;
--disable-glx) glx=no
;;
--enable-glx) glx=yes
@@ -3553,6 +3559,7 @@ echo sigev_thread_id $sigev_thread_id
echo uuid support $uuid
echo libcap-ng support $cap_ng
echo vhost-net support $vhost_net
+echo vhost-scsi support $vhost_scsi
echo Trace backend $trace_backend
echo Trace output file $trace_file-pid
echo spice support $spice
($spice_protocol_version/$spice_server_version)
@@ -3836,6 +3843,9 @@ fi
if test $virtfs = yes ; then
echo CONFIG_VIRTFS=y $config_host_mak
fi
+if test $vhost_scsi = yes ; then
+ echo CONFIG_VHOST_SCSI=y $config_host_mak
+fi
if test $blobs = yes ; then
echo INSTALL_BLOBS=yes $config_host_mak
fi
diff --git a/hw/scsi/Makefile.objs b/hw/scsi/Makefile.objs
index eaec6c8..121ddc5 100644
--- a/hw/scsi/Makefile.objs
+++ b/hw/scsi/Makefile.objs
@@ -6,4 +6,8 @@ common-obj-$(CONFIG_VMW_PVSCSI_SCSI_PCI) += vmw_pvscsi.o
common-obj-$(CONFIG_ESP) += esp.o
common-obj-$(CONFIG_ESP_PCI) += esp-pci.o
obj-$(CONFIG_PSERIES) += spapr_vscsi.o
-obj-$(CONFIG_VIRTIO) += virtio-scsi.o
+
+ifeq ($(CONFIG_VIRTIO),y)
+obj-y += virtio-scsi.o
+obj-$(CONFIG_VHOST_SCSI) += vhost-scsi.o
+endif
diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c
new file mode 100644
index 000..3dd1a0f
--- /dev/null
+++ b/hw/scsi/vhost-scsi.c
@@ -0,0 +1,288 @@
+/*
+ * vhost_scsi host device
+ *
+ * Copyright IBM, Corp. 2011
+ *
+ * Authors:
+ * Stefan Hajnoczi stefa...@linux.vnet.ibm.com
+ *
+ * Changes for QEMU mainline + tcm_vhost kernel upstream:
+ * Nicholas Bellinger n...@risingtidesystems.com
+ *
+ * This work is licensed under the terms of the GNU LGPL, version 2 or later.
+ * See the COPYING.LIB file in the top-level directory.
+ *
+ */
+
+#include sys/ioctl.h
+#include config.h
+#include qemu/queue.h
+#include monitor/monitor.h
+#include migration/migration.h
+#include hw/virtio/vhost-scsi.h
+#include
Re: [Qemu-devel] [PATCH 2/4] tcg/aarch64: implement new TCG target for aarch64
On 27.05.2013 20:47, Richard Henderson wrote:
On 2013-05-27 04:43, Claudio Fontana wrote:
Hmm, true. Although I'd been thinking more along the lines of
arranging the code such that we'd use movz to set the zero.
I think we need to keep treating zero specially if we want to keep the
optimization where we don't emit needless MOVK instructions for half-words
of value h.
I can however make one single function out of movi32 and movi64, it could
look like this:
if (!value) {
tcg_out_movr(s, 0, rd, TCG_REG_ZXR);
return;
}
base = (value 0x) ? 0xd280 : 0x5280;
while (value) {
/* etc etc */
}
if (type == TCG_TYPE_I32) {
value = (uint32_t)value;
ext = 0;
} else if (value = 0x) {
ext = 0;
} else {
ext = 0x8000;
}
The check for type is probably unnecessary, since we don't gain anything (we
still have to check something once), so I'd rather use a uint64_t parameter and
then just check for value 0x.
base = 0x5280; /* MOVZ */
do {
int shift = ctz64(value) (63 -16);
int half = (value shift) 0x;
tcg_out32(s, base | ext | half 5 | rd);
value = ~(0xUL shift);
base = 0x7280; /* MOVK */
} while (value != 0);
Since we go through the loop at least once, we emit the movz for zero input.
No need for any extra tests. And using ctz we can iterate fewer times.
Of course, doh. I'll make use of do..while.
Thanks,
Claudio
Re: [Qemu-devel] [PATCH v6 00/12] curl: fix curl read
Sure, I'm using the attached test script. I used your script to test, but I don't see errors as you posted, attached the output. The only difference is that I put libguestfs in different directory with you and I'm using a linux guest image instead of windows xp. Do I need to get a windows image to reproduce? -- Fam libguestfs: trace: set_verbose true libguestfs: trace: set_verbose = 0 libguestfs: trace: set_tmpdir /home/fam/3rd/libguestfs/tmp libguestfs: trace: set_tmpdir = 0 libguestfs: trace: set_cachedir /home/fam/3rd/libguestfs/tmp libguestfs: trace: set_cachedir = 0 libguestfs: trace: set_path /home/fam/3rd/libguestfs/appliance libguestfs: trace: set_path = 0 libguestfs: trace: set_qemu /home/fam/bin/qemu.wrapper libguestfs: trace: set_qemu = 0 libguestfs: trace: set_backend direct libguestfs: trace: set_backend = 0 libguestfs: create: flags = 0, handle = 0x1154ca0, program = guestfish libguestfs: trace: add_drive /vm/arch.raw readonly:true format:raw protocol:http server:tcp:localhost libguestfs: trace: add_drive = 0 libguestfs: trace: is_config libguestfs: trace: is_config = 1 libguestfs: trace: launch libguestfs: trace: get_tmpdir libguestfs: trace: get_tmpdir = /home/fam/3rd/libguestfs/tmp libguestfs: launch: backend=direct libguestfs: launch: tmpdir=/home/fam/3rd/libguestfs/tmp/libguestfsryyxc3 libguestfs: launch: umask=0022 libguestfs: launch: euid=1000 libguestfs: command: run: supermin-helper libguestfs: command: run: \ --verbose libguestfs: command: run: \ -f checksum libguestfs: command: run: \ /home/fam/3rd/libguestfs/appliance/supermin.d libguestfs: command: run: \ x86_64 supermin helper [0ms] whitelist = (not specified), host_cpu = x86_64, kernel = (null), initrd = (null), appliance = (null) supermin helper [0ms] inputs[0] = /home/fam/3rd/libguestfs/appliance/supermin.d checking modpath /lib/modules/3.9.2-1-ARCH is a directory picked vmlinuz-linux because modpath /lib/modules/3.9.2-1-ARCH exists supermin helper [0ms] finished creating kernel supermin helper [0ms] visiting /home/fam/3rd/libguestfs/appliance/supermin.d supermin helper [0ms] visiting /home/fam/3rd/libguestfs/appliance/supermin.d/base.img supermin helper [0ms] visiting /home/fam/3rd/libguestfs/appliance/supermin.d/daemon.img supermin helper [0ms] visiting /home/fam/3rd/libguestfs/appliance/supermin.d/hostfiles supermin helper [00060ms] visiting /home/fam/3rd/libguestfs/appliance/supermin.d/init.img supermin helper [00060ms] visiting /home/fam/3rd/libguestfs/appliance/supermin.d/udev-rules.img supermin helper [00060ms] adding kernel modules supermin helper [00105ms] finished creating appliance libguestfs: checksum of existing appliance: 7b304f39af320c53e919d598226561b4cfd1b96cc5dedb04a5eecd72191c246c libguestfs: trace: get_cachedir libguestfs: trace: get_cachedir = /home/fam/3rd/libguestfs/tmp libguestfs: [00107ms] begin testing qemu features libguestfs: command: run: /home/fam/bin/qemu.wrapper libguestfs: command: run: \ -nographic libguestfs: command: run: \ -help /home/fam/qemu/x86_64-softmmu/qemu-system-x86_64: /home/fam/3rd/curl/lib/.libs/libcurl.so.4: no version information available (required by /home/fam/qemu/x86_64-softmmu/qemu-system-x86_64) libguestfs: command: run: /home/fam/bin/qemu.wrapper libguestfs: command: run: \ -nographic libguestfs: command: run: \ -version /home/fam/qemu/x86_64-softmmu/qemu-system-x86_64: /home/fam/3rd/curl/lib/.libs/libcurl.so.4: no version information available (required by /home/fam/qemu/x86_64-softmmu/qemu-system-x86_64) libguestfs: qemu version 1.4 libguestfs: command: run: /home/fam/bin/qemu.wrapper libguestfs: command: run: \ -nographic libguestfs: command: run: \ -machine accel=kvm:tcg libguestfs: command: run: \ -device ? libguestfs: [00147ms] finished testing qemu features [00147ms] /home/fam/bin/qemu.wrapper \ -global virtio-blk-pci.scsi=off \ -nodefconfig \ -nodefaults \ -nographic \ -device virtio-scsi-pci,id=scsi \ -drive file=http://localhost/vm/arch.raw,snapshot=on,format=raw,id=hd0,if=none \ -device scsi-hd,drive=hd0 \ -drive file=/home/fam/3rd/libguestfs/tmp/.guestfs-1000/root.10296,snapshot=on,id=appliance,if=none,cache=unsafe \ -device scsi-hd,drive=appliance \ -machine accel=kvm:tcg \ -m 500 \ -no-reboot \ -no-hpet \ -device virtio-serial \ -serial stdio \ -device sga \ -chardev socket,path=/home/fam/3rd/libguestfs/tmp/libguestfsryyxc3/guestfsd.sock,id=channel0 \ -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \ -kernel /home/fam/3rd/libguestfs/tmp/.guestfs-1000/kernel.10296 \ -initrd /home/fam/3rd/libguestfs/tmp/.guestfs-1000/initrd.10296 \ -append 'panic=1 console=ttyS0 udevtimeout=600 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color'/home/fam/qemu/x86_64-softmmu/qemu-system-x86_64: /home/fam/3rd/curl/lib/.libs/libcurl.so.4: no version
[Qemu-devel] [PATCH] boot: fix path pattern of scsi device
bootindex parameter of scsi device doesn't work, it causes by wrong pattern in seabios. qemu passes the following firmware dev_path to seabios: /pci@i0cf8/scsi@4/virtio-scsi-device/channel@0/disk@0,0 Signed-off-by: Amos Kong ak...@redhat.com --- src/boot.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/boot.c b/src/boot.c index c308602..cd9d784 100644 --- a/src/boot.c +++ b/src/boot.c @@ -138,10 +138,11 @@ int bootprio_find_scsi_device(struct pci_device *pci, int target, int lun) if (!pci) // support only pci machine for now return -1; -// Find scsi drive - for example: /pci@i0cf8/scsi@5/channel@0/disk@1,0 +/* Find scsi drive - for example: + /pci@i0cf8/scsi@5/virtio-scsi-device/channel@0/disk@1,0 */ char desc[256], *p; p = build_pci_path(desc, sizeof(desc), *, pci); -snprintf(p, desc+sizeof(desc)-p, /*@0/*@%d,%d, target, lun); +snprintf(p, desc+sizeof(desc)-p, /*/*@0/*@%d,%d, target, lun); return find_prio(desc); } -- 1.8.1.4
Re: [Qemu-devel] [update][PATCH 00/12] target-i386: remove some macros
Am 28.05.2013 04:11, schrieb li guang: 在 2013-05-26日的 17:55 +0200，Andreas Färber写道： Am 24.05.2013 13:37, schrieb Andreas Färber: Am 23.04.2013 10:16, schrieb liguang: remove macros EAX, EBX, ECX, EDX, EBP, ESP, ESI, EDI, EIP, DF as suggested by Richard Henderson r...@twiddle.net Li Guang (12) target-i386/helper: remove EAX macro target-i386/helper: remove EBX macro target-i386/helper: remove ECX macro target-i386/helper: remove EDX macro target-i386/helper: remove EBP macro target-i386/helper: remove ESP macro target-i386/helper: remove ESI macro target-i386/helper: remove EDI macro target-i386/helper: remove EIP macro target-i386/helper: remove DF macro target-i386/helper: remove redundant env-eip assignment target-i386: fix over 80 chars warnings Hard Freeze is over, so more time to look into refactorings: There's one thing to be aware of here, macros would make it easier to transition from CPUX86State to X86CPU fields. However I am guessing that all these registers are accessed by TCG code via offsets from cpu_env - please verify that. Confirmed, I just stumbled over it myself in translate.c: * all but EIP and DF are assigned to cpu_regs[] * EIP is manually stored with offsetof() twice * DF is manually loaded/stored with offsetof() thrice Hi, Andreas do you mean I should not remove macros EIP and DF ? I'm OK with all 12 patches as stated before. However as pointed out below ... or can you pick these patches or cherry-pick some of them. Thanks! If so, Reviewed-by: Andreas Färber afaer...@suse.de However, it would be nice if you could fix the \ alignment in patch 06/12 or in the cleanup patch 12/12. ... patch 06/12 breaks the alignment of the '\' characters through your search-and-replace, so please fix that up in patch 06/12 or in 12/12 or append a 13th patch. I'm not the maintainer of target-i386 TCG code, so this is not for me to pick up, therefore my Reviewed-by. I'm expecting rth or Blue to pick them up once you've sent a v4. Thanks, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH V3 1/4] block: drop bs_snapshots global variable
On Mon, May 27, 2013 at 05:25:16PM +0200, Kevin Wolf wrote:
Am 25.05.2013 um 05:09 hat Wenchao Xia geschrieben:
From: Stefan Hajnoczi stefa...@redhat.com
The bs_snapshots global variable points to the BlockDriverState which
will be used to save vmstate. This is really a savevm.c concept but was
moved into block.c:bdrv_snapshots() when it became clear that hotplug
could result in a dangling pointer.
While auditing the block layer's global state I came upon bs_snapshots
and realized that a variable is not necessary here. Simply find the
first BlockDriverState capable of internal snapshots each time this is
needed.
The behavior of bdrv_snapshots() is preserved across hotplug because new
drives are always appended to the bdrv_states list. This means that
calling the new find_vmstate_bs() function is idempotent - it returns
the same BlockDriverState unless it was hot-unplugged.
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
Reviewed-by: Wenchao Xia xiaw...@linux.vnet.ibm.com
Signed-off-by: Wenchao Xia xiaw...@linux.vnet.ibm.com
---
block.c | 28
include/block/block.h |1 -
savevm.c | 19 +++
3 files changed, 15 insertions(+), 33 deletions(-)
diff --git a/block.c b/block.c
index 3f87489..478a3b2 100644
--- a/block.c
+++ b/block.c
@@ -99,9 +99,6 @@ static QTAILQ_HEAD(, BlockDriverState) bdrv_states =
static QLIST_HEAD(, BlockDriver) bdrv_drivers =
QLIST_HEAD_INITIALIZER(bdrv_drivers);
-/* The device to use for VM snapshots */
-static BlockDriverState *bs_snapshots;
-
/* If non-zero, use only whitelisted block drivers */
static int use_bdrv_whitelist;
@@ -1357,9 +1354,6 @@ void bdrv_close(BlockDriverState *bs)
notifier_list_notify(bs-close_notifiers, bs);
if (bs-drv) {
-if (bs == bs_snapshots) {
-bs_snapshots = NULL;
-}
if (bs-backing_hd) {
bdrv_delete(bs-backing_hd);
bs-backing_hd = NULL;
@@ -1591,7 +1585,6 @@ void bdrv_delete(BlockDriverState *bs)
bdrv_close(bs);
-assert(bs != bs_snapshots);
g_free(bs);
}
@@ -1635,9 +1628,6 @@ void bdrv_set_dev_ops(BlockDriverState *bs, const
BlockDevOps *ops,
{
bs-dev_ops = ops;
bs-dev_opaque = opaque;
-if (bdrv_dev_has_removable_media(bs) bs == bs_snapshots) {
-bs_snapshots = NULL;
-}
This hunk isn't replaced by any other code. If I understand correctly
what it's doing, it prevented you from saving the VM state to a
removable device, which would be allowed after this patch.
Is this a change we want to make? Why isn't it described in the commit
message?
My understanding of this change is different. Markus is on CC so maybe
he can confirm.
The point of bs_snapshots = NULL is not to prevent you from saving
snapshots. It's simply to reset the pointer to the next snapshottable
device (used by bdrv_snapshots()).
See the bdrv_close() hunk above which does the same thing, as well as
bdrv_snapshots() which iterates bdrv_states and updates bs_snapshots.
So what this hunk does is to reset the bdrv_snapshots() iterator when a
removable device is hooked up to an emulated storage controller. It's
no longer necessary since this patch drops the global state
(bs_snapshots) and users will always iterate from scratch.
The whole stateful approach was not necessary.
Stefan
Re: [Qemu-devel] [PATCH v6 00/12] curl: fix curl read
On Tue, May 28, 2013 at 03:30:49PM +0800, Fam Zheng wrote: Sure, I'm using the attached test script. I used your script to test, but I don't see errors as you posted, attached the output. The only difference is that I put libguestfs in different directory with you and I'm using a linux guest image instead of windows xp. Do I need to get a windows image to reproduce? There's actually an error in the output of libguestfs. As a result the test didn't fully run. The error is hidden in all the extra debugging information we're printing, but here it is: guestfsd: error: feature 'augeas' is not available in this build of libguestfs. Read 'AVAILABILITY' in the guestfs(3) man page for how to check for the availability of features. libguestfs: trace: aug_init = -1 (error) libguestfs: error: aug_init: feature 'augeas' is not available in this build of libguestfs. Read 'AVAILABILITY' in the guestfs(3) man page for how to check for the availability of features. libguestfs: trace: umount_all You need to install the Augeas development package (augeas-devel on Fedora, libaugeas-dev on Debian) and recompile libguestfs. It's a good idea to make sure you have every dependency installed by doing: yum-builddep libguestfs or apt-get build-dep libguestfs (this is covered in the libguestfs README). - - - I'm not sure if a Windows guest is somehow necessary to show the errors. I'll retest with a Linux guest and get back to you about that. Also I'm testing against a remote Apache2 server over a very slow Wifi connection. Whereas your test was against localhost. Again, I will test this scenario to see if that makes a difference and get back to you. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
Re: [Qemu-devel] [update][PATCH 00/12] target-i386: remove some macros
在 2013-05-28二的 09:41 +0200，Andreas Färber写道： Am 28.05.2013 04:11, schrieb li guang: 在 2013-05-26日的 17:55 +0200，Andreas Färber写道： Am 24.05.2013 13:37, schrieb Andreas Färber: Am 23.04.2013 10:16, schrieb liguang: remove macros EAX, EBX, ECX, EDX, EBP, ESP, ESI, EDI, EIP, DF as suggested by Richard Henderson r...@twiddle.net Li Guang (12) target-i386/helper: remove EAX macro target-i386/helper: remove EBX macro target-i386/helper: remove ECX macro target-i386/helper: remove EDX macro target-i386/helper: remove EBP macro target-i386/helper: remove ESP macro target-i386/helper: remove ESI macro target-i386/helper: remove EDI macro target-i386/helper: remove EIP macro target-i386/helper: remove DF macro target-i386/helper: remove redundant env-eip assignment target-i386: fix over 80 chars warnings Hard Freeze is over, so more time to look into refactorings: There's one thing to be aware of here, macros would make it easier to transition from CPUX86State to X86CPU fields. However I am guessing that all these registers are accessed by TCG code via offsets from cpu_env - please verify that. Confirmed, I just stumbled over it myself in translate.c: * all but EIP and DF are assigned to cpu_regs[] * EIP is manually stored with offsetof() twice * DF is manually loaded/stored with offsetof() thrice Hi, Andreas do you mean I should not remove macros EIP and DF ? I'm OK with all 12 patches as stated before. However as pointed out below ... or can you pick these patches or cherry-pick some of them. Thanks! If so, Reviewed-by: Andreas Färber afaer...@suse.de However, it would be nice if you could fix the \ alignment in patch 06/12 or in the cleanup patch 12/12. ... patch 06/12 breaks the alignment of the '\' characters through your search-and-replace, so please fix that up in patch 06/12 or in 12/12 or append a 13th patch. I'm not the maintainer of target-i386 TCG code, so this is not for me to pick up, therefore my Reviewed-by. I'm expecting rth or Blue to pick them up once you've sent a v4. OK, I'll send a v4 Thanks a lot!
[Qemu-devel] [PATCH v2] OVS: update INSTALL.KVM
From: Zhi Yong Wu wu...@linux.vnet.ibm.com When i played with OVS again today, i found that the argument of ovs-dpctl show is not correct, so INSTALL.KVM need to be updated accordingly. Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com --- INSTALL.KVM |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/INSTALL.KVM b/INSTALL.KVM index 18a7bd4..aa7ab92 100644 --- a/INSTALL.KVM +++ b/INSTALL.KVM @@ -69,7 +69,7 @@ guest will be able to communicate over that bridge. To get some more information and for debugging you can use Open vSwitch utilities such as ovs-dpctl and ovs-ofctl, For example: - % ovs-dpctl show br0 + % ovs-dpctl show % ovs-ofctl show br0 You should see tap devices for each KVM guest added as ports to -- 1.7.6.5
Re: [Qemu-devel] [PATCH] block: add read only to whitelist
Am 28.05.2013 um 08:44 hat Fam Zheng geschrieben: We may want to include a driver in the whitelist for read only tasks such as diagnosing or exporting guest data (with libguestfs as a good example). This patch introduces the magic prefix ^ to include a driver to the whitelist, but only enables qemu to open specific image format readonly, and returns -ENOTSUP for RW opening. Example: To include vmdk readonly, and others read+write: ./configure --block-drv-whitelist=qcow2,raw,file,qed,^vmdk Signed-off-by: Fam Zheng f...@redhat.com ^ looks a bit like not, so this is potentially confusing syntax. Why not simply add a second option? ./configure --block-drv-whitelist=qcow2,raw,file,qed \ --block-drv-ro-whitelist=vmdk Kevin
Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
Il 28/05/2013 09:13, Wenchao Xia ha scritto: From: Nicholas Bellinger n...@linux-iscsi.org The WWPN specified in configfs is passed to -device vhost-scsi-pci. The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is not available from the QEMU command-line. Instead, I hardcode it to zero. Hi, Paolo Any document about how to config it correctly in configfs, before invoking qemu with the WWPN number? Unfortunately no, but vhost-scsi doesn't have many knobs (unlike iSCSI for example) so it's quite simple. Here is an example: cd /sys/kernel/config/target mkdir -p core/fileio_0/fileio echo 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' core/fileio_0/fileio/control echo 1 core/fileio_0/fileio/enable mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0 cd vhost/naa.600140554cf3a18e/tpgt_0 ln -sf ../../../../../core/fileio_0/fileio/ lun/lun_0/virtual_scsi_port echo naa.60014053226f0388 nexus The nexus value is the initiator WWN. naa.600140554cf3a18e is the target WWN that you have to pass to -device vhost-scsi-pci. Paolo
Re: [Qemu-devel] [PATCH] block: add read only to whitelist
On Tue, May 28, 2013 at 02:44:26PM +0800, Fam Zheng wrote:
We may want to include a driver in the whitelist for read only tasks
such as diagnosing or exporting guest data (with libguestfs as a good
example). This patch introduces the magic prefix ^ to include a driver
to the whitelist, but only enables qemu to open specific image
format readonly, and returns -ENOTSUP for RW opening.
Example: To include vmdk readonly, and others read+write:
./configure --block-drv-whitelist=qcow2,raw,file,qed,^vmdk
This is great, thanks for tackling this. block/vmdk.c isn't suitable
for running real VMs (read-write) since it's not optimized for
concurrent I/O but it is usable for libguestfs (read-only).
Signed-off-by: Fam Zheng f...@redhat.com
---
block.c | 43 +++
blockdev.c| 4 ++--
configure | 2 ++
include/block/block.h | 3 ++-
scripts/create_config | 9 -
5 files changed, 41 insertions(+), 20 deletions(-)
diff --git a/block.c b/block.c
index 3f87489..e6a7270 100644
--- a/block.c
+++ b/block.c
@@ -328,28 +328,40 @@ BlockDriver *bdrv_find_format(const char *format_name)
return NULL;
}
-static int bdrv_is_whitelisted(BlockDriver *drv)
+static int bdrv_is_whitelisted(BlockDriver *drv, bool read_only)
{
-static const char *whitelist[] = {
-CONFIG_BDRV_WHITELIST
+static const char *whitelist_rw[] = {
+CONFIG_BDRV_WHITELIST_RW
+};
+static const char *whitelist_ro[] = {
+CONFIG_BDRV_WHITELIST_RO
};
const char **p;
Please also make the ./configure lists separate. The funky ^ syntax is
not obvious. Better to have:
./configure --block-drv-whitelist-rw=qcow2,raw,file,qed \
--block-drv-whitelist-ro=vmdk,vpc
-if (!whitelist[0])
+if (!whitelist_rw[0] !whitelist_ro[0]) {
return 1; /* no whitelist, anything goes */
+}
-for (p = whitelist; *p; p++) {
+for (p = whitelist_rw; *p; p++) {
if (!strcmp(drv-format_name, *p)) {
return 1;
}
}
+if (read_only) {
+for (p = whitelist_ro; *p; p++) {
+if (!strcmp(drv-format_name, *p)) {
+return 1;
+}
+}
+}
return 0;
}
-BlockDriver *bdrv_find_whitelisted_format(const char *format_name)
+BlockDriver *bdrv_find_whitelisted_format(const char *format_name,
+ bool read_only)
{
BlockDriver *drv = bdrv_find_format(format_name);
-return drv bdrv_is_whitelisted(drv) ? drv : NULL;
+return drv bdrv_is_whitelisted(drv, read_only) ? drv : NULL;
}
typedef struct CreateCo {
@@ -684,10 +696,6 @@ static int bdrv_open_common(BlockDriverState *bs,
BlockDriverState *file,
trace_bdrv_open_common(bs, filename ?: , flags, drv-format_name);
-if (use_bdrv_whitelist !bdrv_is_whitelisted(drv)) {
-return -ENOTSUP;
-}
-
/* bdrv_open() with directly using a protocol as drv. This layer is
already
* opened, so assign it to bs (while file becomes a closed
BlockDriverState)
* and return immediately. */
if (file != NULL drv-bdrv_file_open) {
bdrv_swap(file, bs);
return 0;
}
I think your change is okay. You moved the check after this early
return, but file is already opened so we passed the whitelist check
already. This is a little tricky but it seems fine.
Stefan
Re: [Qemu-devel] kvm process disappears
On Mon, May 27, 2013 at 11:09:51PM +0200, Stefan Priebe wrote:
Am 10.05.2013 13:09, schrieb Stefan Hajnoczi:
On Fri, May 10, 2013 at 11:07 AM, Stefan Priebe - Profihost AG
s.pri...@profihost.ag wrote:
Am 10.05.2013 09:42, schrieb Stefan Hajnoczi:
On Fri, May 10, 2013 at 08:12:39AM +0200, Stefan Priebe - Profihost AG
wrote:
3. Either use gdb or an LD_PRELOAD library that catches exit(3) and
_exit(2) and dumps core using abort(3). Make sure core dumps are
enabled.
LD_PRELOAD sounds good can you point me to such a lib?
$ cat /tmp/catchexit.c
#include unistd.h
#include stdlib.h
void exit(int status)
{
const char msg[] = *** CAUGHT EXIT, DUMPING CORE ***\n;
write(2, msg, sizeof msg);
abort();
}
void _exit(int status) __attribute__((alias(exit)));
$ gcc -o catchexit.so -shared -fPIC -std=gnu99 catchexit.c
$ LD_PRELOAD=/tmp/catchexit.so x86_64-softmmu/qemu-system-x86_64 -m
1024 -enable-kvm -cpu host -vga asdf
Unknown vga type: asdf
*** CAUGHT EXIT, DUMPING CORE ***
Aborted (core dumped)
Make sure to give the absolute path to catchexit.so. Also keep in
mind that this does not catch a normal return from main() or possibly
other ways of terminating the process.
You can hook more library functions, if necessary.
Stefan
I'm really sorry for bothering you. It turned out to be a host
kernel bug. Without NUMA Balancing turned on (kernel 3.8.13) i see
no vm crashes at all...
No worries. Glad you found the solution.
Stefan
Re: [Qemu-devel] [PATCH] boot: fix path pattern of scsi device
Il 28/05/2013 09:40, Amos Kong ha scritto: bootindex parameter of scsi device doesn't work, it causes by wrong pattern in seabios. qemu passes the following firmware dev_path to seabios: /pci@i0cf8/scsi@4/virtio-scsi-device/channel@0/disk@0,0 No, this is another unexpected change due to the virtio refactoring in QEMU. The right fix is in QEMU, by adding a get_fw_dev_path implementation in hw/virtio/virtio-bus.c. We fixed it already for migration paths, it should be easy to do the same for this. Please Cc qemu-sta...@nongnu.org when sending the QEMU patch. Thanks, Paolo Signed-off-by: Amos Kong ak...@redhat.com --- src/boot.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/boot.c b/src/boot.c index c308602..cd9d784 100644 --- a/src/boot.c +++ b/src/boot.c @@ -138,10 +138,11 @@ int bootprio_find_scsi_device(struct pci_device *pci, int target, int lun) if (!pci) // support only pci machine for now return -1; -// Find scsi drive - for example: /pci@i0cf8/scsi@5/channel@0/disk@1,0 +/* Find scsi drive - for example: + /pci@i0cf8/scsi@5/virtio-scsi-device/channel@0/disk@1,0 */ char desc[256], *p; p = build_pci_path(desc, sizeof(desc), *, pci); -snprintf(p, desc+sizeof(desc)-p, /*@0/*@%d,%d, target, lun); +snprintf(p, desc+sizeof(desc)-p, /*/*@0/*@%d,%d, target, lun); return find_prio(desc); }
Re: [Qemu-devel] [PATCH 1/4] include/elf.h: add aarch64 ELF machine and relocs
Hello,
On Thu, May 23, 2013 at 10:14 AM, Claudio Fontana
claudio.font...@huawei.com wrote:
we will use the 26bit relative relocs in the aarch64 tcg target.
Is there really any point in adding all of the relocation types?
i386 doesn't, mips doesn't, x86_64 doesn't. I didn't check the
others.
I guess we can at least get rid of dynamic relocs.
Thanks,
Laurent
Signed-off-by: Claudio Fontana claudio.font...@huawei.com
---
include/elf.h | 129
++
1 file changed, 129 insertions(+)
diff --git a/include/elf.h b/include/elf.h
index a21ea53..cf0d3e2 100644
--- a/include/elf.h
+++ b/include/elf.h
@@ -129,6 +129,8 @@ typedef int64_t Elf64_Sxword;
#define EM_XTENSA 94 /* Tensilica Xtensa */
+#define EM_AARCH64 183
+
/* This is the info that is needed to parse the dynamic section of the file
*/
#define DT_NULL0
#define DT_NEEDED 1
@@ -616,6 +618,133 @@ typedef struct {
/* Keep this the last entry. */
#define R_ARM_NUM 256
+/* ARM Aarch64 relocation types */
+#define R_AARCH64_NONE256 /* also accepts R_ARM_NONE (0) */
+/* static data relocations */
+#define R_AARCH64_ABS64 257
+#define R_AARCH64_ABS32 258
+#define R_AARCH64_ABS16 259
+#define R_AARCH64_PREL64 260
+#define R_AARCH64_PREL32 261
+#define R_AARCH64_PREL16 262
+/* static aarch64 group relocations */
+/* group relocs to create unsigned data value or address inline */
+#define R_AARCH64_MOVW_UABS_G0263
+#define R_AARCH64_MOVW_UABS_G0_NC 264
+#define R_AARCH64_MOVW_UABS_G1265
+#define R_AARCH64_MOVW_UABS_G1_NC 266
+#define R_AARCH64_MOVW_UABS_G2267
+#define R_AARCH64_MOVW_UABS_G2_NC 268
+#define R_AARCH64_MOVW_UABS_G3269
+/* group relocs to create signed data or offset value inline */
+#define R_AARCH64_MOVW_SABS_G0270
+#define R_AARCH64_MOVW_SABS_G1271
+#define R_AARCH64_MOVW_SABS_G2272
+/* relocs to generate 19, 21, and 33 bit PC-relative addresses */
+#define R_AARCH64_LD_PREL_LO19273
+#define R_AARCH64_ADR_PREL_LO21 274
+#define R_AARCH64_ADR_PREL_PG_HI21275
+#define R_AARCH64_ADR_PREL_PG_HI21_NC 276
+#define R_AARCH64_ADD_ABS_LO12_NC 277
+#define R_AARCH64_LDST8_ABS_LO12_NC 278
+#define R_AARCH64_LDST16_ABS_LO12_NC 284
+#define R_AARCH64_LDST32_ABS_LO12_NC 285
+#define R_AARCH64_LDST64_ABS_LO12_NC 286
+#define R_AARCH64_LDST128_ABS_LO12_NC 299
+/* relocs for control-flow - all offsets as multiple of 4 */
+#define R_AARCH64_TSTBR14 279
+#define R_AARCH64_CONDBR19280
+#define R_AARCH64_JUMP26 282
+#define R_AARCH64_CALL26 283
+/* group relocs to create pc-relative offset inline */
+#define R_AARCH64_MOVW_PREL_G0287
+#define R_AARCH64_MOVW_PREL_G0_NC 288
+#define R_AARCH64_MOVW_PREL_G1289
+#define R_AARCH64_MOVW_PREL_G1_NC 290
+#define R_AARCH64_MOVW_PREL_G2291
+#define R_AARCH64_MOVW_PREL_G2_NC 292
+#define R_AARCH64_MOVW_PREL_G3293
+/* group relocs to create a GOT-relative offset inline */
+#define R_AARCH64_MOVW_GOTOFF_G0 300
+#define R_AARCH64_MOVW_GOTOFF_G0_NC 301
+#define R_AARCH64_MOVW_GOTOFF_G1 302
+#define R_AARCH64_MOVW_GOTOFF_G1_NC 303
+#define R_AARCH64_MOVW_GOTOFF_G2 304
+#define R_AARCH64_MOVW_GOTOFF_G2_NC 305
+#define R_AARCH64_MOVW_GOTOFF_G3 306
+/* GOT-relative data relocs */
+#define R_AARCH64_GOTREL64307
+#define R_AARCH64_GOTREL32308
+/* GOT-relative instr relocs */
+#define R_AARCH64_GOT_LD_PREL19 309
+#define R_AARCH64_LD64_GOTOFF_LO15310
+#define R_AARCH64_ADR_GOT_PAGE311
+#define R_AARCH64_LD64_GOT_LO12_NC312
+#define R_AARCH64_LD64_GOTPAGE_LO15 313
+/* General Dynamic TLS relocations */
+#define R_AARCH64_TLSGD_ADR_PREL21512
+#define R_AARCH64_TLSGD_ADR_PAGE21513
+#define R_AARCH64_TLSGD_ADD_LO12_NC 514
+#define R_AARCH64_TLSGD_MOVW_G1 515
+#define R_AARCH64_TLSGD_MOVW_G0_NC516
+/* Local Dynamic TLS relocations */
+#define R_AARCH64_TLSLD_ADR_PREL21517
+#define R_AARCH64_TLSLD_ADR_PAGE21518
+#define R_AARCH64_TLSLD_ADD_LO12_NC 519
+#define R_AARCH64_TLSLD_MOVW_G1 520
+#define R_AARCH64_TLSLD_MOVW_G0_NC521
+#define R_AARCH64_TLSLD_LD_PREL19 522
+#define R_AARCH64_TLSLD_MOVW_DTPREL_G2523
+#define R_AARCH64_TLSLD_MOVW_DTPREL_G1524
+#define R_AARCH64_TLSLD_MOVW_DTPREL_G1_NC 525
+#define R_AARCH64_TLSLD_MOVW_DTPREL_G0526
+#define R_AARCH64_TLSLD_MOVW_DTPREL_G0_NC 527
+#define R_AARCH64_TLSLD_ADD_DTPREL_HI12 528
+#define R_AARCH64_TLSLD_ADD_DTPREL_LO12 529
+#define
Re: [Qemu-devel] [PATCH] block: add read only to whitelist
Il 28/05/2013 08:44, Fam Zheng ha scritto:
diff --git a/scripts/create_config b/scripts/create_config
index c471e8c..2dfda3e 100755
--- a/scripts/create_config
+++ b/scripts/create_config
@@ -35,11 +35,18 @@ case $line in
echo
;;
CONFIG_BDRV_WHITELIST=*)
-echo #define CONFIG_BDRV_WHITELIST \\
+echo #define CONFIG_BDRV_WHITELIST_RW \\
for drv in ${line#*=}; do
+ [[ ${drv} = ^* ]] continue;
I didn't know about this feature. Can you point me to the documentation?
You would need to change the #! header to #! /bin/bash if you use it,
but since you have to respin anyway, I'd ask you to use case instead. :)
Paolo
echo \${drv}\,\\
done
echo NULL
+echo #define CONFIG_BDRV_WHITELIST_RO \\
+for drv in ${line#*=}; do
+ [[ ${drv} != ^* ]] continue;
+ echo \${drv#^}\,\\
+done
+echo NULL
;;
CONFIG_*=y) # configuration
name=${line%=*}
Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
On Tue, 28 May 2013 08:28:09 +0800
li guang lig.f...@cn.fujitsu.com wrote:
在 2013-05-27一的 13:45 +0200，Igor Mammedov写道：
On Mon, 27 May 2013 09:22:59 +0800
li guang lig.f...@cn.fujitsu.com wrote:
在 2013-05-26日的 19:51 -0500，Anthony Liguori写道：
li guang lig.f...@cn.fujitsu.com writes:
在 2013-05-24五的 14:45 +0300，Michael S. Tsirkin写道：
On Wed, May 22, 2013 at 11:46:33AM +0800, liguang wrote:
These patches try to add ACPI Embedded Controller (EC),
refer-to:
ACPI SPEC v5 chapter 5
ACPI Embedded Controller Interface Specification
EC is a standard ACPI device, it plays flexible roles,
e.g.
power controller, it can control power sequence for
platform to enter or leave system state(0,1,3,4,5),
it can controller CPU fan by the temperature of sensor.
event carrier, it can pass events between platform
and OS, so OS can execute _Qxx method which defined
by yourself.
So, I want to deliver CPU online/offline event between
OS and QEMU for CPU hotplug feature, then we will don't
need to echo 1 /sys/devices/system/cpu/cpu1/online
again after 'cpu-add'.
patches for online/offline event handler of QEUM and
linux kernel are writing, and will send once finished.
since EC is a common device, so I send pathes separately.
Do any non-linux guests support this device?
In fact, any OSes support ACPI will support this device.
so, windows will.
When you say any OSes supporting ACPI I think what you really mean is
that we can provide bytecode that interacts with the embedded
controller.
There is not explicit driver in Linux or Windows AFAIK.
Hmm, yep, mostly there's no special driver for EC,
because it is directly embedded in code for ACPI
for linux kernel, it's drivers/acpi/ec.c
I still don't get the point of this. We can make ACPI hotplug work
without introducing a new device like this.
when you 'cpu-add' a cpu, acpi driver for cpu will not
trigger 'cpu_up' for linux kernel AFAIK, unless you add
a user space program to listen it's uevent and tigger 'cpu_up'.
it is up to guest OS policy to decide if CPU should be onlined or not,
Yep, but I think it's a favor to do cpu online.
Then you have to teach kernel driver (EC) to do cpu_up on _Q02 event,
the question is why would you do this when there is ACPI processor driver
already that handles CPU hotplug in kernel.
You can try add cpu_up() there and perhaps with good enough reasoning it
would be accepted.
at least I've seen this rationale on LKML when topic was discussed and
automatic cpu_up on hotplug was rejected.
Oh, and the reason is?
Reason was to let guest decide whether online new CPU or nor instead of
doing it unconditionally.
can you give me a link?
I'm sorry but I can't find link quickly.
Oh, Igor,
I remember that you said you can give me some your considerations
on the further development of cpu hotplug feature, but I haven't got
them :-)
I'm sorry, I haven't time yet to update TODO list on wiki page:
But here some items that need some attention:
* try to introduce generic QOM interface for CPU topology introspection
something like
/machine/node/socket[xxx]/{(core[yyy]/thread[zzz])|thread[zzz]}
* allow to specify at CLI specific CPUs to be created at start-up time
- important for hot-adding/removing an arbitrary CPU
- probably depends on previous item so that each CPU could be specified by
socket/core/thread numbers
* extend/rework -numa CLI option to support socket to node binding
- goal is to obsolete node to thread biding which allows specify incorrect
topology.
Thanks!
[Qemu-devel] [PATCH] ide: Set BSY bit during FLUSH
The implementation of the ATA FLUSH command invokes a flush at the block
layer, which may on raw files on POSIX entail a synchronous fdatasync().
This may in some cases take so long that the SLES 11 SP1 guest driver
reports I/O errors and filesystems get corrupted or remounted read-only.
Avoid this by setting BUSY_STAT, so that the guest is made aware we are
in the middle of an operation and no ATA commands are attempted to be
processed concurrently.
Addresses BNC#637297.
Suggested-by: Gonglei (Arei) arei.gong...@huawei.com
Signed-off-by: Andreas Färber afaer...@suse.de
---
hw/ide/core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index c7a8041..bf1ff18 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -795,6 +795,8 @@ static void ide_flush_cb(void *opaque, int ret)
{
IDEState *s = opaque;
+s-status = ~BUSY_STAT;
+
if (ret 0) {
/* XXX: What sector number to set here? */
if (ide_handle_rw_error(s, -ret, BM_STATUS_RETRY_FLUSH)) {
@@ -814,6 +816,7 @@ void ide_flush_cache(IDEState *s)
return;
}
+s-status |= BUSY_STAT;
bdrv_acct_start(s-bs, s-acct, 0, BDRV_ACCT_FLUSH);
bdrv_aio_flush(s-bs, ide_flush_cb, s);
}
--
1.8.1.4
[Qemu-devel] [PATCH v4 00/12] target-i386: remove some macros
remove macros EAX, EBX, ECX, EDX, EBP, ESP, ESI, EDI, EIP, DF as suggested by Richard Henderson r...@twiddle.net v4: fix alignment issue in patch 6. Li Guang (12) target-i386/helper: remove EAX macro target-i386/helper: remove EBX macro target-i386/helper: remove ECX macro target-i386/helper: remove EDX macro target-i386/helper: remove EBP macro target-i386/helper: remove ESP macro target-i386/helper: remove ESI macro target-i386/helper: remove EDI macro target-i386/helper: remove EIP macro target-i386/helper: remove DF macro target-i386/helper: remove redundant env-eip assignment target-i386: fix over 80 chars warnings cpu-exec.c| 4 ++-- target-i386/cc_helper.c | 2 +- target-i386/cpu.h | 24 - target-i386/excp_helper.c | 2 +- target-i386/int_helper.c | 86 ++-- target-i386/mem_helper.c | 24 +++--- target-i386/misc_helper.c | 107 +++--- target-i386/seg_helper.c | 182 +++--- target-i386/smm_helper.c | 64 +++--- target-i386/svm_helper.c | 66 10 files changed, 280 insertions(+), 281 deletions(-)
[Qemu-devel] [PATCH v4 01/12] target-i386/helper: remove EAX macro
Signed-off-by: liguang lig.f...@cn.fujitsu.com
---
target-i386/cpu.h |2 -
target-i386/int_helper.c | 62 ++--
target-i386/mem_helper.c |8 +++---
target-i386/misc_helper.c | 10 +++---
target-i386/seg_helper.c |8 +++---
target-i386/smm_helper.c |8 +++---
target-i386/svm_helper.c | 24
7 files changed, 60 insertions(+), 62 deletions(-)
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 058c57f..4585c0a 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -1101,8 +1101,6 @@ static inline int cpu_mmu_index (CPUX86State *env)
? MMU_KSMAP_IDX : MMU_KERNEL_IDX;
}
-#undef EAX
-#define EAX (env-regs[R_EAX])
#undef ECX
#define ECX (env-regs[R_ECX])
#undef EDX
diff --git a/target-i386/int_helper.c b/target-i386/int_helper.c
index 74c7c36..16d1ed5 100644
--- a/target-i386/int_helper.c
+++ b/target-i386/int_helper.c
@@ -45,7 +45,7 @@ void helper_divb_AL(CPUX86State *env, target_ulong t0)
{
unsigned int num, den, q, r;
-num = (EAX 0x);
+num = (env-regs[R_EAX] 0x);
den = (t0 0xff);
if (den == 0) {
raise_exception(env, EXCP00_DIVZ);
@@ -56,14 +56,14 @@ void helper_divb_AL(CPUX86State *env, target_ulong t0)
}
q = 0xff;
r = (num % den) 0xff;
-EAX = (EAX ~0x) | (r 8) | q;
+env-regs[R_EAX] = (env-regs[R_EAX] ~0x) | (r 8) | q;
}
void helper_idivb_AL(CPUX86State *env, target_ulong t0)
{
int num, den, q, r;
-num = (int16_t)EAX;
+num = (int16_t)env-regs[R_EAX];
den = (int8_t)t0;
if (den == 0) {
raise_exception(env, EXCP00_DIVZ);
@@ -74,14 +74,14 @@ void helper_idivb_AL(CPUX86State *env, target_ulong t0)
}
q = 0xff;
r = (num % den) 0xff;
-EAX = (EAX ~0x) | (r 8) | q;
+env-regs[R_EAX] = (env-regs[R_EAX] ~0x) | (r 8) | q;
}
void helper_divw_AX(CPUX86State *env, target_ulong t0)
{
unsigned int num, den, q, r;
-num = (EAX 0x) | ((EDX 0x) 16);
+num = (env-regs[R_EAX] 0x) | ((EDX 0x) 16);
den = (t0 0x);
if (den == 0) {
raise_exception(env, EXCP00_DIVZ);
@@ -92,7 +92,7 @@ void helper_divw_AX(CPUX86State *env, target_ulong t0)
}
q = 0x;
r = (num % den) 0x;
-EAX = (EAX ~0x) | q;
+env-regs[R_EAX] = (env-regs[R_EAX] ~0x) | q;
EDX = (EDX ~0x) | r;
}
@@ -100,7 +100,7 @@ void helper_idivw_AX(CPUX86State *env, target_ulong t0)
{
int num, den, q, r;
-num = (EAX 0x) | ((EDX 0x) 16);
+num = (env-regs[R_EAX] 0x) | ((EDX 0x) 16);
den = (int16_t)t0;
if (den == 0) {
raise_exception(env, EXCP00_DIVZ);
@@ -111,7 +111,7 @@ void helper_idivw_AX(CPUX86State *env, target_ulong t0)
}
q = 0x;
r = (num % den) 0x;
-EAX = (EAX ~0x) | q;
+env-regs[R_EAX] = (env-regs[R_EAX] ~0x) | q;
EDX = (EDX ~0x) | r;
}
@@ -120,7 +120,7 @@ void helper_divl_EAX(CPUX86State *env, target_ulong t0)
unsigned int den, r;
uint64_t num, q;
-num = ((uint32_t)EAX) | ((uint64_t)((uint32_t)EDX) 32);
+num = ((uint32_t)env-regs[R_EAX]) | ((uint64_t)((uint32_t)EDX) 32);
den = t0;
if (den == 0) {
raise_exception(env, EXCP00_DIVZ);
@@ -130,7 +130,7 @@ void helper_divl_EAX(CPUX86State *env, target_ulong t0)
if (q 0x) {
raise_exception(env, EXCP00_DIVZ);
}
-EAX = (uint32_t)q;
+env-regs[R_EAX] = (uint32_t)q;
EDX = (uint32_t)r;
}
@@ -139,7 +139,7 @@ void helper_idivl_EAX(CPUX86State *env, target_ulong t0)
int den, r;
int64_t num, q;
-num = ((uint32_t)EAX) | ((uint64_t)((uint32_t)EDX) 32);
+num = ((uint32_t)env-regs[R_EAX]) | ((uint64_t)((uint32_t)EDX) 32);
den = t0;
if (den == 0) {
raise_exception(env, EXCP00_DIVZ);
@@ -149,7 +149,7 @@ void helper_idivl_EAX(CPUX86State *env, target_ulong t0)
if (q != (int32_t)q) {
raise_exception(env, EXCP00_DIVZ);
}
-EAX = (uint32_t)q;
+env-regs[R_EAX] = (uint32_t)q;
EDX = (uint32_t)r;
}
@@ -160,10 +160,10 @@ void helper_aam(CPUX86State *env, int base)
{
int al, ah;
-al = EAX 0xff;
+al = env-regs[R_EAX] 0xff;
ah = al / base;
al = al % base;
-EAX = (EAX ~0x) | al | (ah 8);
+env-regs[R_EAX] = (env-regs[R_EAX] ~0x) | al | (ah 8);
CC_DST = al;
}
@@ -171,10 +171,10 @@ void helper_aad(CPUX86State *env, int base)
{
int al, ah;
-al = EAX 0xff;
-ah = (EAX 8) 0xff;
+al = env-regs[R_EAX] 0xff;
+ah = (env-regs[R_EAX] 8) 0xff;
al = ((ah * base) + al) 0xff;
-EAX = (EAX ~0x) | al;
+env-regs[R_EAX] = (env-regs[R_EAX] ~0x) | al;
CC_DST = al;
}
@@ -186,8 +186,8 @@ void helper_aaa(CPUX86State *env)
eflags = cpu_cc_compute_all(env, CC_OP);
af = eflags CC_A;
-al = EAX 0xff;
-ah = (EAX
Re: [Qemu-devel] [Bug 1184089] Re: [Feature request] loadvm snapshot as read-only
On Mon, May 27, 2013 at 10:42:17PM -, Michael Coppola wrote: Awesome, looking forward to it. I may be misunderstanding what's happening under the hood, but at least for me, calling 'loadvm' on a single snapshot over and over seems to work the first few times and then immediately blue screens the WinXP guest with PFN_LIST_CORRUPT. I was under the assumption that all runtime modifications were being written back to the image, effectively corrupting something (whether it was changes to the snapshot or the backing image causing things to break). savevm/loadvm does not use backing images. It relies on internal snapshot which are stored inside the existing qcow2 image file. If you *are* using backing images then you're right - modifying the backing image is likely to trigger weird guest behavior. Until then, I've seemed to have found a workaround for the feature itself. Instead of creating a snapshot with 'savevm', I can start the VM with -snapshot and then call: migrate exec: gzip -c snapshot.gz in QMP and it saves the live image to a compressed file. Make sure it's completed migration before exiting with info migrate. Subsequently loading the snapshot with: qemu-* whatever flags -incoming exec: gzip -c -d snapshot.gz -snapshot will load the live snapshot and redirect all runtime modifications to a temp file. http://www.linux-kvm.org/page/Migration says not to use -snapshot, but who follows the rules anyways? ;) It seems to work so far and things haven't exploded yet. Running md5sum on the qcow2 image and gzip snapshot before and after shows no changes to either files. The reason that -snapshot isn't used together with migration is because the disk state will be discarded and not migrated. Stefan
[Qemu-devel] [PATCH v4 02/12] target-i386/helper: remove EBX macro
Signed-off-by: liguang lig.f...@cn.fujitsu.com
---
target-i386/cpu.h |2 --
target-i386/mem_helper.c |4 ++--
target-i386/misc_helper.c |2 +-
target-i386/seg_helper.c |6 +++---
target-i386/smm_helper.c |8
5 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 4585c0a..28ff02d 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -1105,8 +1105,6 @@ static inline int cpu_mmu_index (CPUX86State *env)
#define ECX (env-regs[R_ECX])
#undef EDX
#define EDX (env-regs[R_EDX])
-#undef EBX
-#define EBX (env-regs[R_EBX])
#undef ESP
#define ESP (env-regs[R_ESP])
#undef EBP
diff --git a/target-i386/mem_helper.c b/target-i386/mem_helper.c
index f0f5aec..6370fb5 100644
--- a/target-i386/mem_helper.c
+++ b/target-i386/mem_helper.c
@@ -46,7 +46,7 @@ void helper_cmpxchg8b(CPUX86State *env, target_ulong a0)
eflags = cpu_cc_compute_all(env, CC_OP);
d = cpu_ldq_data(env, a0);
if (d == (((uint64_t)EDX 32) | (uint32_t)env-regs[R_EAX])) {
-cpu_stq_data(env, a0, ((uint64_t)ECX 32) | (uint32_t)EBX);
+cpu_stq_data(env, a0, ((uint64_t)ECX 32) |
(uint32_t)env-regs[R_EBX]);
eflags |= CC_Z;
} else {
/* always do the store */
@@ -71,7 +71,7 @@ void helper_cmpxchg16b(CPUX86State *env, target_ulong a0)
d0 = cpu_ldq_data(env, a0);
d1 = cpu_ldq_data(env, a0 + 8);
if (d0 == env-regs[R_EAX] d1 == EDX) {
-cpu_stq_data(env, a0, EBX);
+cpu_stq_data(env, a0, env-regs[R_EBX]);
cpu_stq_data(env, a0 + 8, ECX);
eflags |= CC_Z;
} else {
diff --git a/target-i386/misc_helper.c b/target-i386/misc_helper.c
index a6a787f..d7be4f4 100644
--- a/target-i386/misc_helper.c
+++ b/target-i386/misc_helper.c
@@ -124,7 +124,7 @@ void helper_cpuid(CPUX86State *env)
cpu_x86_cpuid(env, (uint32_t)env-regs[R_EAX], (uint32_t)ECX, eax, ebx,
ecx, edx);
env-regs[R_EAX] = eax;
-EBX = ebx;
+env-regs[R_EBX] = ebx;
ECX = ecx;
EDX = edx;
}
diff --git a/target-i386/seg_helper.c b/target-i386/seg_helper.c
index 719b7bb..b3c087f 100644
--- a/target-i386/seg_helper.c
+++ b/target-i386/seg_helper.c
@@ -327,7 +327,7 @@ static void switch_tss(CPUX86State *env, int tss_selector,
cpu_stl_kernel(env, env-tr.base + (0x28 + 0 * 4), env-regs[R_EAX]);
cpu_stl_kernel(env, env-tr.base + (0x28 + 1 * 4), ECX);
cpu_stl_kernel(env, env-tr.base + (0x28 + 2 * 4), EDX);
-cpu_stl_kernel(env, env-tr.base + (0x28 + 3 * 4), EBX);
+cpu_stl_kernel(env, env-tr.base + (0x28 + 3 * 4), env-regs[R_EBX]);
cpu_stl_kernel(env, env-tr.base + (0x28 + 4 * 4), ESP);
cpu_stl_kernel(env, env-tr.base + (0x28 + 5 * 4), EBP);
cpu_stl_kernel(env, env-tr.base + (0x28 + 6 * 4), ESI);
@@ -343,7 +343,7 @@ static void switch_tss(CPUX86State *env, int tss_selector,
cpu_stw_kernel(env, env-tr.base + (0x12 + 0 * 2), env-regs[R_EAX]);
cpu_stw_kernel(env, env-tr.base + (0x12 + 1 * 2), ECX);
cpu_stw_kernel(env, env-tr.base + (0x12 + 2 * 2), EDX);
-cpu_stw_kernel(env, env-tr.base + (0x12 + 3 * 2), EBX);
+cpu_stw_kernel(env, env-tr.base + (0x12 + 3 * 2), env-regs[R_EBX]);
cpu_stw_kernel(env, env-tr.base + (0x12 + 4 * 2), ESP);
cpu_stw_kernel(env, env-tr.base + (0x12 + 5 * 2), EBP);
cpu_stw_kernel(env, env-tr.base + (0x12 + 6 * 2), ESI);
@@ -399,7 +399,7 @@ static void switch_tss(CPUX86State *env, int tss_selector,
env-regs[R_EAX] = new_regs[0];
ECX = new_regs[1];
EDX = new_regs[2];
-EBX = new_regs[3];
+env-regs[R_EBX] = new_regs[3];
ESP = new_regs[4];
EBP = new_regs[5];
ESI = new_regs[6];
diff --git a/target-i386/smm_helper.c b/target-i386/smm_helper.c
index 1ea6107..28c78a5 100644
--- a/target-i386/smm_helper.c
+++ b/target-i386/smm_helper.c
@@ -85,7 +85,7 @@ void do_smm_enter(CPUX86State *env)
stq_phys(sm_state + 0x7ff8, env-regs[R_EAX]);
stq_phys(sm_state + 0x7ff0, ECX);
stq_phys(sm_state + 0x7fe8, EDX);
-stq_phys(sm_state + 0x7fe0, EBX);
+stq_phys(sm_state + 0x7fe0, env-regs[R_EBX]);
stq_phys(sm_state + 0x7fd8, ESP);
stq_phys(sm_state + 0x7fd0, EBP);
stq_phys(sm_state + 0x7fc8, ESI);
@@ -113,7 +113,7 @@ void do_smm_enter(CPUX86State *env)
stl_phys(sm_state + 0x7fe8, ESI);
stl_phys(sm_state + 0x7fe4, EBP);
stl_phys(sm_state + 0x7fe0, ESP);
-stl_phys(sm_state + 0x7fdc, EBX);
+stl_phys(sm_state + 0x7fdc, env-regs[R_EBX]);
stl_phys(sm_state + 0x7fd8, EDX);
stl_phys(sm_state + 0x7fd4, ECX);
stl_phys(sm_state + 0x7fd0, env-regs[R_EAX]);
@@ -216,7 +216,7 @@ void helper_rsm(CPUX86State *env)
env-regs[R_EAX] = ldq_phys(sm_state + 0x7ff8);
ECX = ldq_phys(sm_state + 0x7ff0);
EDX = ldq_phys(sm_state + 0x7fe8);
-EBX = ldq_phys(sm_state + 0x7fe0);
+env-regs[R_EBX] = ldq_phys(sm_state + 0x7fe0);
ESP = ldq_phys(sm_state +
[Qemu-devel] [PATCH v4 08/12] target-i386/helper: remove EDI macro
Signed-off-by: liguang lig.f...@cn.fujitsu.com
---
target-i386/cpu.h|2 --
target-i386/seg_helper.c |6 +++---
target-i386/smm_helper.c |8
3 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index e287290..585776a 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -1101,8 +1101,6 @@ static inline int cpu_mmu_index (CPUX86State *env)
? MMU_KSMAP_IDX : MMU_KERNEL_IDX;
}
-#undef EDI
-#define EDI (env-regs[R_EDI])
#undef EIP
#define EIP (env-eip)
#define DF (env-df)
diff --git a/target-i386/seg_helper.c b/target-i386/seg_helper.c
index 0e02eda..8b2766d 100644
--- a/target-i386/seg_helper.c
+++ b/target-i386/seg_helper.c
@@ -331,7 +331,7 @@ static void switch_tss(CPUX86State *env, int tss_selector,
cpu_stl_kernel(env, env-tr.base + (0x28 + 4 * 4), env-regs[R_ESP]);
cpu_stl_kernel(env, env-tr.base + (0x28 + 5 * 4), env-regs[R_EBP]);
cpu_stl_kernel(env, env-tr.base + (0x28 + 6 * 4), env-regs[R_ESI]);
-cpu_stl_kernel(env, env-tr.base + (0x28 + 7 * 4), EDI);
+cpu_stl_kernel(env, env-tr.base + (0x28 + 7 * 4), env-regs[R_EDI]);
for (i = 0; i 6; i++) {
cpu_stw_kernel(env, env-tr.base + (0x48 + i * 4),
env-segs[i].selector);
@@ -347,7 +347,7 @@ static void switch_tss(CPUX86State *env, int tss_selector,
cpu_stw_kernel(env, env-tr.base + (0x12 + 4 * 2), env-regs[R_ESP]);
cpu_stw_kernel(env, env-tr.base + (0x12 + 5 * 2), env-regs[R_EBP]);
cpu_stw_kernel(env, env-tr.base + (0x12 + 6 * 2), env-regs[R_ESI]);
-cpu_stw_kernel(env, env-tr.base + (0x12 + 7 * 2), EDI);
+cpu_stw_kernel(env, env-tr.base + (0x12 + 7 * 2), env-regs[R_EDI]);
for (i = 0; i 4; i++) {
cpu_stw_kernel(env, env-tr.base + (0x22 + i * 4),
env-segs[i].selector);
@@ -403,7 +403,7 @@ static void switch_tss(CPUX86State *env, int tss_selector,
env-regs[R_ESP] = new_regs[4];
env-regs[R_EBP] = new_regs[5];
env-regs[R_ESI] = new_regs[6];
-EDI = new_regs[7];
+env-regs[R_EDI] = new_regs[7];
if (new_eflags VM_MASK) {
for (i = 0; i 6; i++) {
load_seg_vm(env, i, new_segs[i]);
diff --git a/target-i386/smm_helper.c b/target-i386/smm_helper.c
index d051f03..2489573 100644
--- a/target-i386/smm_helper.c
+++ b/target-i386/smm_helper.c
@@ -89,7 +89,7 @@ void do_smm_enter(CPUX86State *env)
stq_phys(sm_state + 0x7fd8, env-regs[R_ESP]);
stq_phys(sm_state + 0x7fd0, env-regs[R_EBP]);
stq_phys(sm_state + 0x7fc8, env-regs[R_ESI]);
-stq_phys(sm_state + 0x7fc0, EDI);
+stq_phys(sm_state + 0x7fc0, env-regs[R_EDI]);
for (i = 8; i 16; i++) {
stq_phys(sm_state + 0x7ff8 - i * 8, env-regs[i]);
}
@@ -109,7 +109,7 @@ void do_smm_enter(CPUX86State *env)
stl_phys(sm_state + 0x7ff8, env-cr[3]);
stl_phys(sm_state + 0x7ff4, cpu_compute_eflags(env));
stl_phys(sm_state + 0x7ff0, env-eip);
-stl_phys(sm_state + 0x7fec, EDI);
+stl_phys(sm_state + 0x7fec, env-regs[R_EDI]);
stl_phys(sm_state + 0x7fe8, env-regs[R_ESI]);
stl_phys(sm_state + 0x7fe4, env-regs[R_EBP]);
stl_phys(sm_state + 0x7fe0, env-regs[R_ESP]);
@@ -220,7 +220,7 @@ void helper_rsm(CPUX86State *env)
env-regs[R_ESP] = ldq_phys(sm_state + 0x7fd8);
env-regs[R_EBP] = ldq_phys(sm_state + 0x7fd0);
env-regs[R_ESI] = ldq_phys(sm_state + 0x7fc8);
-EDI = ldq_phys(sm_state + 0x7fc0);
+env-regs[R_EDI] = ldq_phys(sm_state + 0x7fc0);
for (i = 8; i 16; i++) {
env-regs[i] = ldq_phys(sm_state + 0x7ff8 - i * 8);
}
@@ -244,7 +244,7 @@ void helper_rsm(CPUX86State *env)
cpu_load_eflags(env, ldl_phys(sm_state + 0x7ff4),
~(CC_O | CC_S | CC_Z | CC_A | CC_P | CC_C | DF_MASK));
env-eip = ldl_phys(sm_state + 0x7ff0);
-EDI = ldl_phys(sm_state + 0x7fec);
+env-regs[R_EDI] = ldl_phys(sm_state + 0x7fec);
env-regs[R_ESI] = ldl_phys(sm_state + 0x7fe8);
env-regs[R_EBP] = ldl_phys(sm_state + 0x7fe4);
env-regs[R_ESP] = ldl_phys(sm_state + 0x7fe0);
--
1.7.2.5
[Qemu-devel] [PATCH v4 05/12] target-i386/helper: remove EBP macro
Signed-off-by: liguang lig.f...@cn.fujitsu.com
---
target-i386/cpu.h|2 --
target-i386/seg_helper.c | 10 +-
target-i386/smm_helper.c |8
3 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index ebc5abd..fc0cf65 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -1103,8 +1103,6 @@ static inline int cpu_mmu_index (CPUX86State *env)
#undef ESP
#define ESP (env-regs[R_ESP])
-#undef EBP
-#define EBP (env-regs[R_EBP])
#undef ESI
#define ESI (env-regs[R_ESI])
#undef EDI
diff --git a/target-i386/seg_helper.c b/target-i386/seg_helper.c
index fc67f52..56db00f 100644
--- a/target-i386/seg_helper.c
+++ b/target-i386/seg_helper.c
@@ -329,7 +329,7 @@ static void switch_tss(CPUX86State *env, int tss_selector,
cpu_stl_kernel(env, env-tr.base + (0x28 + 2 * 4), env-regs[R_EDX]);
cpu_stl_kernel(env, env-tr.base + (0x28 + 3 * 4), env-regs[R_EBX]);
cpu_stl_kernel(env, env-tr.base + (0x28 + 4 * 4), ESP);
-cpu_stl_kernel(env, env-tr.base + (0x28 + 5 * 4), EBP);
+cpu_stl_kernel(env, env-tr.base + (0x28 + 5 * 4), env-regs[R_EBP]);
cpu_stl_kernel(env, env-tr.base + (0x28 + 6 * 4), ESI);
cpu_stl_kernel(env, env-tr.base + (0x28 + 7 * 4), EDI);
for (i = 0; i 6; i++) {
@@ -345,7 +345,7 @@ static void switch_tss(CPUX86State *env, int tss_selector,
cpu_stw_kernel(env, env-tr.base + (0x12 + 2 * 2), env-regs[R_EDX]);
cpu_stw_kernel(env, env-tr.base + (0x12 + 3 * 2), env-regs[R_EBX]);
cpu_stw_kernel(env, env-tr.base + (0x12 + 4 * 2), ESP);
-cpu_stw_kernel(env, env-tr.base + (0x12 + 5 * 2), EBP);
+cpu_stw_kernel(env, env-tr.base + (0x12 + 5 * 2), env-regs[R_EBP]);
cpu_stw_kernel(env, env-tr.base + (0x12 + 6 * 2), ESI);
cpu_stw_kernel(env, env-tr.base + (0x12 + 7 * 2), EDI);
for (i = 0; i 4; i++) {
@@ -401,7 +401,7 @@ static void switch_tss(CPUX86State *env, int tss_selector,
env-regs[R_EDX] = new_regs[2];
env-regs[R_EBX] = new_regs[3];
ESP = new_regs[4];
-EBP = new_regs[5];
+env-regs[R_EBP] = new_regs[5];
ESI = new_regs[6];
EDI = new_regs[7];
if (new_eflags VM_MASK) {
@@ -1272,7 +1272,7 @@ void helper_enter_level(CPUX86State *env, int level, int
data32,
esp_mask = get_sp_mask(env-segs[R_SS].flags);
ssp = env-segs[R_SS].base;
-ebp = EBP;
+ebp = env-regs[R_EBP];
esp = ESP;
if (data32) {
/* 32 bit */
@@ -1305,7 +1305,7 @@ void helper_enter64_level(CPUX86State *env, int level,
int data64,
{
target_ulong esp, ebp;
-ebp = EBP;
+ebp = env-regs[R_EBP];
esp = ESP;
if (data64) {
diff --git a/target-i386/smm_helper.c b/target-i386/smm_helper.c
index 5bc6802..4bd73eb 100644
--- a/target-i386/smm_helper.c
+++ b/target-i386/smm_helper.c
@@ -87,7 +87,7 @@ void do_smm_enter(CPUX86State *env)
stq_phys(sm_state + 0x7fe8, env-regs[R_EDX]);
stq_phys(sm_state + 0x7fe0, env-regs[R_EBX]);
stq_phys(sm_state + 0x7fd8, ESP);
-stq_phys(sm_state + 0x7fd0, EBP);
+stq_phys(sm_state + 0x7fd0, env-regs[R_EBP]);
stq_phys(sm_state + 0x7fc8, ESI);
stq_phys(sm_state + 0x7fc0, EDI);
for (i = 8; i 16; i++) {
@@ -111,7 +111,7 @@ void do_smm_enter(CPUX86State *env)
stl_phys(sm_state + 0x7ff0, env-eip);
stl_phys(sm_state + 0x7fec, EDI);
stl_phys(sm_state + 0x7fe8, ESI);
-stl_phys(sm_state + 0x7fe4, EBP);
+stl_phys(sm_state + 0x7fe4, env-regs[R_EBP]);
stl_phys(sm_state + 0x7fe0, ESP);
stl_phys(sm_state + 0x7fdc, env-regs[R_EBX]);
stl_phys(sm_state + 0x7fd8, env-regs[R_EDX]);
@@ -218,7 +218,7 @@ void helper_rsm(CPUX86State *env)
env-regs[R_EDX] = ldq_phys(sm_state + 0x7fe8);
env-regs[R_EBX] = ldq_phys(sm_state + 0x7fe0);
ESP = ldq_phys(sm_state + 0x7fd8);
-EBP = ldq_phys(sm_state + 0x7fd0);
+env-regs[R_EBP] = ldq_phys(sm_state + 0x7fd0);
ESI = ldq_phys(sm_state + 0x7fc8);
EDI = ldq_phys(sm_state + 0x7fc0);
for (i = 8; i 16; i++) {
@@ -246,7 +246,7 @@ void helper_rsm(CPUX86State *env)
env-eip = ldl_phys(sm_state + 0x7ff0);
EDI = ldl_phys(sm_state + 0x7fec);
ESI = ldl_phys(sm_state + 0x7fe8);
-EBP = ldl_phys(sm_state + 0x7fe4);
+env-regs[R_EBP] = ldl_phys(sm_state + 0x7fe4);
ESP = ldl_phys(sm_state + 0x7fe0);
env-regs[R_EBX] = ldl_phys(sm_state + 0x7fdc);
env-regs[R_EDX] = ldl_phys(sm_state + 0x7fd8);
--
1.7.2.5
[Qemu-devel] [PATCH v4 07/12] target-i386/helper: remove ESI macro
Signed-off-by: liguang lig.f...@cn.fujitsu.com
---
target-i386/cpu.h|2 --
target-i386/seg_helper.c |6 +++---
target-i386/smm_helper.c |8
3 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 6b058bb..e287290 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -1101,8 +1101,6 @@ static inline int cpu_mmu_index (CPUX86State *env)
? MMU_KSMAP_IDX : MMU_KERNEL_IDX;
}
-#undef ESI
-#define ESI (env-regs[R_ESI])
#undef EDI
#define EDI (env-regs[R_EDI])
#undef EIP
diff --git a/target-i386/seg_helper.c b/target-i386/seg_helper.c
index 0c4b3d8..0e02eda 100644
--- a/target-i386/seg_helper.c
+++ b/target-i386/seg_helper.c
@@ -330,7 +330,7 @@ static void switch_tss(CPUX86State *env, int tss_selector,
cpu_stl_kernel(env, env-tr.base + (0x28 + 3 * 4), env-regs[R_EBX]);
cpu_stl_kernel(env, env-tr.base + (0x28 + 4 * 4), env-regs[R_ESP]);
cpu_stl_kernel(env, env-tr.base + (0x28 + 5 * 4), env-regs[R_EBP]);
-cpu_stl_kernel(env, env-tr.base + (0x28 + 6 * 4), ESI);
+cpu_stl_kernel(env, env-tr.base + (0x28 + 6 * 4), env-regs[R_ESI]);
cpu_stl_kernel(env, env-tr.base + (0x28 + 7 * 4), EDI);
for (i = 0; i 6; i++) {
cpu_stw_kernel(env, env-tr.base + (0x48 + i * 4),
@@ -346,7 +346,7 @@ static void switch_tss(CPUX86State *env, int tss_selector,
cpu_stw_kernel(env, env-tr.base + (0x12 + 3 * 2), env-regs[R_EBX]);
cpu_stw_kernel(env, env-tr.base + (0x12 + 4 * 2), env-regs[R_ESP]);
cpu_stw_kernel(env, env-tr.base + (0x12 + 5 * 2), env-regs[R_EBP]);
-cpu_stw_kernel(env, env-tr.base + (0x12 + 6 * 2), ESI);
+cpu_stw_kernel(env, env-tr.base + (0x12 + 6 * 2), env-regs[R_ESI]);
cpu_stw_kernel(env, env-tr.base + (0x12 + 7 * 2), EDI);
for (i = 0; i 4; i++) {
cpu_stw_kernel(env, env-tr.base + (0x22 + i * 4),
@@ -402,7 +402,7 @@ static void switch_tss(CPUX86State *env, int tss_selector,
env-regs[R_EBX] = new_regs[3];
env-regs[R_ESP] = new_regs[4];
env-regs[R_EBP] = new_regs[5];
-ESI = new_regs[6];
+env-regs[R_ESI] = new_regs[6];
EDI = new_regs[7];
if (new_eflags VM_MASK) {
for (i = 0; i 6; i++) {
diff --git a/target-i386/smm_helper.c b/target-i386/smm_helper.c
index 50c5d99..d051f03 100644
--- a/target-i386/smm_helper.c
+++ b/target-i386/smm_helper.c
@@ -88,7 +88,7 @@ void do_smm_enter(CPUX86State *env)
stq_phys(sm_state + 0x7fe0, env-regs[R_EBX]);
stq_phys(sm_state + 0x7fd8, env-regs[R_ESP]);
stq_phys(sm_state + 0x7fd0, env-regs[R_EBP]);
-stq_phys(sm_state + 0x7fc8, ESI);
+stq_phys(sm_state + 0x7fc8, env-regs[R_ESI]);
stq_phys(sm_state + 0x7fc0, EDI);
for (i = 8; i 16; i++) {
stq_phys(sm_state + 0x7ff8 - i * 8, env-regs[i]);
@@ -110,7 +110,7 @@ void do_smm_enter(CPUX86State *env)
stl_phys(sm_state + 0x7ff4, cpu_compute_eflags(env));
stl_phys(sm_state + 0x7ff0, env-eip);
stl_phys(sm_state + 0x7fec, EDI);
-stl_phys(sm_state + 0x7fe8, ESI);
+stl_phys(sm_state + 0x7fe8, env-regs[R_ESI]);
stl_phys(sm_state + 0x7fe4, env-regs[R_EBP]);
stl_phys(sm_state + 0x7fe0, env-regs[R_ESP]);
stl_phys(sm_state + 0x7fdc, env-regs[R_EBX]);
@@ -219,7 +219,7 @@ void helper_rsm(CPUX86State *env)
env-regs[R_EBX] = ldq_phys(sm_state + 0x7fe0);
env-regs[R_ESP] = ldq_phys(sm_state + 0x7fd8);
env-regs[R_EBP] = ldq_phys(sm_state + 0x7fd0);
-ESI = ldq_phys(sm_state + 0x7fc8);
+env-regs[R_ESI] = ldq_phys(sm_state + 0x7fc8);
EDI = ldq_phys(sm_state + 0x7fc0);
for (i = 8; i 16; i++) {
env-regs[i] = ldq_phys(sm_state + 0x7ff8 - i * 8);
@@ -245,7 +245,7 @@ void helper_rsm(CPUX86State *env)
~(CC_O | CC_S | CC_Z | CC_A | CC_P | CC_C | DF_MASK));
env-eip = ldl_phys(sm_state + 0x7ff0);
EDI = ldl_phys(sm_state + 0x7fec);
-ESI = ldl_phys(sm_state + 0x7fe8);
+env-regs[R_ESI] = ldl_phys(sm_state + 0x7fe8);
env-regs[R_EBP] = ldl_phys(sm_state + 0x7fe4);
env-regs[R_ESP] = ldl_phys(sm_state + 0x7fe0);
env-regs[R_EBX] = ldl_phys(sm_state + 0x7fdc);
--
1.7.2.5
[Qemu-devel] [PATCH v4 03/12] target-i386/helper: remove ECX macro
Signed-off-by: liguang lig.f...@cn.fujitsu.com
---
target-i386/cpu.h |2 --
target-i386/mem_helper.c |4 ++--
target-i386/misc_helper.c | 44 ++--
target-i386/seg_helper.c | 18 +-
target-i386/smm_helper.c |8
target-i386/svm_helper.c | 10 +-
6 files changed, 42 insertions(+), 44 deletions(-)
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 28ff02d..b3c6fcb 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -1101,8 +1101,6 @@ static inline int cpu_mmu_index (CPUX86State *env)
? MMU_KSMAP_IDX : MMU_KERNEL_IDX;
}
-#undef ECX
-#define ECX (env-regs[R_ECX])
#undef EDX
#define EDX (env-regs[R_EDX])
#undef ESP
diff --git a/target-i386/mem_helper.c b/target-i386/mem_helper.c
index 6370fb5..41ac847 100644
--- a/target-i386/mem_helper.c
+++ b/target-i386/mem_helper.c
@@ -46,7 +46,7 @@ void helper_cmpxchg8b(CPUX86State *env, target_ulong a0)
eflags = cpu_cc_compute_all(env, CC_OP);
d = cpu_ldq_data(env, a0);
if (d == (((uint64_t)EDX 32) | (uint32_t)env-regs[R_EAX])) {
-cpu_stq_data(env, a0, ((uint64_t)ECX 32) |
(uint32_t)env-regs[R_EBX]);
+cpu_stq_data(env, a0, ((uint64_t)env-regs[R_ECX] 32) |
(uint32_t)env-regs[R_EBX]);
eflags |= CC_Z;
} else {
/* always do the store */
@@ -72,7 +72,7 @@ void helper_cmpxchg16b(CPUX86State *env, target_ulong a0)
d1 = cpu_ldq_data(env, a0 + 8);
if (d0 == env-regs[R_EAX] d1 == EDX) {
cpu_stq_data(env, a0, env-regs[R_EBX]);
-cpu_stq_data(env, a0 + 8, ECX);
+cpu_stq_data(env, a0 + 8, env-regs[R_ECX]);
eflags |= CC_Z;
} else {
/* always do the store */
diff --git a/target-i386/misc_helper.c b/target-i386/misc_helper.c
index d7be4f4..b0afffe 100644
--- a/target-i386/misc_helper.c
+++ b/target-i386/misc_helper.c
@@ -122,10 +122,10 @@ void helper_cpuid(CPUX86State *env)
cpu_svm_check_intercept_param(env, SVM_EXIT_CPUID, 0);
-cpu_x86_cpuid(env, (uint32_t)env-regs[R_EAX], (uint32_t)ECX, eax, ebx,
ecx, edx);
+cpu_x86_cpuid(env, (uint32_t)env-regs[R_EAX], (uint32_t)env-regs[R_ECX],
eax, ebx, ecx, edx);
env-regs[R_EAX] = eax;
env-regs[R_EBX] = ebx;
-ECX = ecx;
+env-regs[R_ECX] = ecx;
EDX = edx;
}
@@ -241,7 +241,7 @@ void helper_rdtsc(CPUX86State *env)
void helper_rdtscp(CPUX86State *env)
{
helper_rdtsc(env);
-ECX = (uint32_t)(env-tsc_aux);
+env-regs[R_ECX] = (uint32_t)(env-tsc_aux);
}
void helper_rdpmc(CPUX86State *env)
@@ -273,7 +273,7 @@ void helper_wrmsr(CPUX86State *env)
val = ((uint32_t)env-regs[R_EAX]) | ((uint64_t)((uint32_t)EDX) 32);
-switch ((uint32_t)ECX) {
+switch ((uint32_t)env-regs[R_ECX]) {
case MSR_IA32_SYSENTER_CS:
env-sysenter_cs = val 0x;
break;
@@ -350,7 +350,7 @@ void helper_wrmsr(CPUX86State *env)
case MSR_MTRRphysBase(5):
case MSR_MTRRphysBase(6):
case MSR_MTRRphysBase(7):
-env-mtrr_var[((uint32_t)ECX - MSR_MTRRphysBase(0)) / 2].base = val;
+env-mtrr_var[((uint32_t)env-regs[R_ECX] - MSR_MTRRphysBase(0)) /
2].base = val;
break;
case MSR_MTRRphysMask(0):
case MSR_MTRRphysMask(1):
@@ -360,14 +360,14 @@ void helper_wrmsr(CPUX86State *env)
case MSR_MTRRphysMask(5):
case MSR_MTRRphysMask(6):
case MSR_MTRRphysMask(7):
-env-mtrr_var[((uint32_t)ECX - MSR_MTRRphysMask(0)) / 2].mask = val;
+env-mtrr_var[((uint32_t)env-regs[R_ECX] - MSR_MTRRphysMask(0)) /
2].mask = val;
break;
case MSR_MTRRfix64K_0:
-env-mtrr_fixed[(uint32_t)ECX - MSR_MTRRfix64K_0] = val;
+env-mtrr_fixed[(uint32_t)env-regs[R_ECX] - MSR_MTRRfix64K_0] =
val;
break;
case MSR_MTRRfix16K_8:
case MSR_MTRRfix16K_A:
-env-mtrr_fixed[(uint32_t)ECX - MSR_MTRRfix16K_8 + 1] = val;
+env-mtrr_fixed[(uint32_t)env-regs[R_ECX] - MSR_MTRRfix16K_8 + 1]
= val;
break;
case MSR_MTRRfix4K_C:
case MSR_MTRRfix4K_C8000:
@@ -377,7 +377,7 @@ void helper_wrmsr(CPUX86State *env)
case MSR_MTRRfix4K_E8000:
case MSR_MTRRfix4K_F:
case MSR_MTRRfix4K_F8000:
-env-mtrr_fixed[(uint32_t)ECX - MSR_MTRRfix4K_C + 3] = val;
+env-mtrr_fixed[(uint32_t)env-regs[R_ECX] - MSR_MTRRfix4K_C + 3]
= val;
break;
case MSR_MTRRdefType:
env-mtrr_deftype = val;
@@ -398,9 +398,9 @@ void helper_wrmsr(CPUX86State *env)
env-msr_ia32_misc_enable = val;
break;
default:
-if ((uint32_t)ECX = MSR_MC0_CTL
- (uint32_t)ECX MSR_MC0_CTL + (4 * env-mcg_cap 0xff)) {
-uint32_t offset = (uint32_t)ECX - MSR_MC0_CTL;
+if ((uint32_t)env-regs[R_ECX] = MSR_MC0_CTL
+ (uint32_t)env-regs[R_ECX] MSR_MC0_CTL + (4 * env-mcg_cap
0xff)) {
+uint32_t offset = (uint32_t)env-regs[R_ECX] - MSR_MC0_CTL;
[Qemu-devel] [PATCH v4 09/12] target-i386/helper: remove EIP macro
Signed-off-by: liguang lig.f...@cn.fujitsu.com
---
target-i386/cpu.h |2 --
target-i386/excp_helper.c |2 +-
target-i386/misc_helper.c |4 ++--
target-i386/seg_helper.c | 24
target-i386/svm_helper.c | 16
5 files changed, 23 insertions(+), 25 deletions(-)
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 585776a..b909f73 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -1101,8 +1101,6 @@ static inline int cpu_mmu_index (CPUX86State *env)
? MMU_KSMAP_IDX : MMU_KERNEL_IDX;
}
-#undef EIP
-#define EIP (env-eip)
#define DF (env-df)
#define CC_DST (env-cc_dst)
diff --git a/target-i386/excp_helper.c b/target-i386/excp_helper.c
index 179ea82..5319aef 100644
--- a/target-i386/excp_helper.c
+++ b/target-i386/excp_helper.c
@@ -87,7 +87,7 @@ static int check_exception(CPUX86State *env, int intno, int
*error_code)
/*
* Signal an interruption. It is executed in the main CPU loop.
* is_int is TRUE if coming from the int instruction. next_eip is the
- * EIP value AFTER the interrupt instruction. It is only relevant if
+ * env-eip value AFTER the interrupt instruction. It is only relevant if
* is_int is TRUE.
*/
static void QEMU_NORETURN raise_interrupt2(CPUX86State *env, int intno,
diff --git a/target-i386/misc_helper.c b/target-i386/misc_helper.c
index 380e54e..4ee618d 100644
--- a/target-i386/misc_helper.c
+++ b/target-i386/misc_helper.c
@@ -569,7 +569,7 @@ void helper_hlt(CPUX86State *env, int next_eip_addend)
X86CPU *cpu = x86_env_get_cpu(env);
cpu_svm_check_intercept_param(env, SVM_EXIT_HLT, 0);
-EIP += next_eip_addend;
+env-eip += next_eip_addend;
do_hlt(cpu);
}
@@ -592,7 +592,7 @@ void helper_mwait(CPUX86State *env, int next_eip_addend)
raise_exception(env, EXCP0D_GPF);
}
cpu_svm_check_intercept_param(env, SVM_EXIT_MWAIT, 0);
-EIP += next_eip_addend;
+env-eip += next_eip_addend;
cpu = x86_env_get_cpu(env);
cs = CPU(cpu);
diff --git a/target-i386/seg_helper.c b/target-i386/seg_helper.c
index 8b2766d..939d7dc 100644
--- a/target-i386/seg_helper.c
+++ b/target-i386/seg_helper.c
@@ -457,7 +457,7 @@ static void switch_tss(CPUX86State *env, int tss_selector,
tss_load_seg(env, R_GS, new_segs[R_GS]);
}
-/* check that EIP is in the CS segment limits */
+/* check that env-eip is in the CS segment limits */
if (new_eip env-segs[R_CS].limit) {
/* XXX: different exception if CALL? */
raise_exception_err(env, EXCP0D_GPF, 0);
@@ -1122,7 +1122,7 @@ static void do_interrupt_user(CPUX86State *env, int
intno, int is_int,
exiting the emulation with the suitable exception and error
code */
if (is_int) {
-EIP = next_eip;
+env-eip = next_eip;
}
}
@@ -1157,7 +1157,7 @@ static void handle_even_inj(CPUX86State *env, int intno,
int is_int,
/*
* Begin execution of an interruption. is_int is TRUE if coming from
- * the int instruction. next_eip is the EIP value AFTER the interrupt
+ * the int instruction. next_eip is the env-eip value AFTER the interrupt
* instruction. It is only relevant if is_int is TRUE.
*/
static void do_interrupt_all(CPUX86State *env, int intno, int is_int,
@@ -1171,8 +1171,8 @@ static void do_interrupt_all(CPUX86State *env, int intno,
int is_int,
pc= TARGET_FMT_lx SP=%04x: TARGET_FMT_lx,
count, intno, error_code, is_int,
env-hflags HF_CPL_MASK,
- env-segs[R_CS].selector, EIP,
- (int)env-segs[R_CS].base + EIP,
+ env-segs[R_CS].selector, env-eip,
+ (int)env-segs[R_CS].base + env-eip,
env-segs[R_SS].selector, env-regs[R_ESP]);
if (intno == 0x0e) {
qemu_log( CR2= TARGET_FMT_lx, env-cr[2]);
@@ -1584,7 +1584,7 @@ void helper_ljmp_protected(CPUX86State *env, int new_cs,
target_ulong new_eip,
}
cpu_x86_load_seg_cache(env, R_CS, (new_cs 0xfffc) | cpl,
get_seg_base(e1, e2), limit, e2);
-EIP = new_eip;
+env-eip = new_eip;
} else {
/* jump to call or task gate */
dpl = (e2 DESC_DPL_SHIFT) 3;
@@ -1637,7 +1637,7 @@ void helper_ljmp_protected(CPUX86State *env, int new_cs,
target_ulong new_eip,
}
cpu_x86_load_seg_cache(env, R_CS, (gate_cs 0xfffc) | cpl,
get_seg_base(e1, e2), limit, e2);
-EIP = new_eip;
+env-eip = new_eip;
break;
default:
raise_exception_err(env, EXCP0D_GPF, new_cs 0xfffc);
@@ -1731,7 +1731,7 @@ void helper_lcall_protected(CPUX86State *env, int new_cs,
target_ulong new_eip,
cpu_x86_load_seg_cache(env, R_CS, (new_cs 0xfffc) | cpl,
get_seg_base(e1, e2),
[Qemu-devel] [PATCH v4 12/12] target-i386: fix over 80 chars warnings
Signed-off-by: liguang lig.f...@cn.fujitsu.com
---
target-i386/misc_helper.c | 39 ++-
target-i386/seg_helper.c | 16 +---
target-i386/svm_helper.c |6 --
3 files changed, 39 insertions(+), 22 deletions(-)
diff --git a/target-i386/misc_helper.c b/target-i386/misc_helper.c
index 4ee618d..e345f9a 100644
--- a/target-i386/misc_helper.c
+++ b/target-i386/misc_helper.c
@@ -122,7 +122,8 @@ void helper_cpuid(CPUX86State *env)
cpu_svm_check_intercept_param(env, SVM_EXIT_CPUID, 0);
-cpu_x86_cpuid(env, (uint32_t)env-regs[R_EAX], (uint32_t)env-regs[R_ECX],
eax, ebx, ecx, edx);
+cpu_x86_cpuid(env, (uint32_t)env-regs[R_EAX], (uint32_t)env-regs[R_ECX],
+ eax, ebx, ecx, edx);
env-regs[R_EAX] = eax;
env-regs[R_EBX] = ebx;
env-regs[R_ECX] = ecx;
@@ -271,7 +272,8 @@ void helper_wrmsr(CPUX86State *env)
cpu_svm_check_intercept_param(env, SVM_EXIT_MSR, 1);
-val = ((uint32_t)env-regs[R_EAX]) |
((uint64_t)((uint32_t)env-regs[R_EDX]) 32);
+val = ((uint32_t)env-regs[R_EAX]) |
+((uint64_t)((uint32_t)env-regs[R_EDX]) 32);
switch ((uint32_t)env-regs[R_ECX]) {
case MSR_IA32_SYSENTER_CS:
@@ -350,7 +352,8 @@ void helper_wrmsr(CPUX86State *env)
case MSR_MTRRphysBase(5):
case MSR_MTRRphysBase(6):
case MSR_MTRRphysBase(7):
-env-mtrr_var[((uint32_t)env-regs[R_ECX] - MSR_MTRRphysBase(0)) /
2].base = val;
+env-mtrr_var[((uint32_t)env-regs[R_ECX] -
+ MSR_MTRRphysBase(0)) / 2].base = val;
break;
case MSR_MTRRphysMask(0):
case MSR_MTRRphysMask(1):
@@ -360,14 +363,17 @@ void helper_wrmsr(CPUX86State *env)
case MSR_MTRRphysMask(5):
case MSR_MTRRphysMask(6):
case MSR_MTRRphysMask(7):
-env-mtrr_var[((uint32_t)env-regs[R_ECX] - MSR_MTRRphysMask(0)) /
2].mask = val;
+env-mtrr_var[((uint32_t)env-regs[R_ECX] -
+ MSR_MTRRphysMask(0)) / 2].mask = val;
break;
case MSR_MTRRfix64K_0:
-env-mtrr_fixed[(uint32_t)env-regs[R_ECX] - MSR_MTRRfix64K_0] =
val;
+env-mtrr_fixed[(uint32_t)env-regs[R_ECX] -
+MSR_MTRRfix64K_0] = val;
break;
case MSR_MTRRfix16K_8:
case MSR_MTRRfix16K_A:
-env-mtrr_fixed[(uint32_t)env-regs[R_ECX] - MSR_MTRRfix16K_8 + 1]
= val;
+env-mtrr_fixed[(uint32_t)env-regs[R_ECX] -
+MSR_MTRRfix16K_8 + 1] = val;
break;
case MSR_MTRRfix4K_C:
case MSR_MTRRfix4K_C8000:
@@ -377,7 +383,8 @@ void helper_wrmsr(CPUX86State *env)
case MSR_MTRRfix4K_E8000:
case MSR_MTRRfix4K_F:
case MSR_MTRRfix4K_F8000:
-env-mtrr_fixed[(uint32_t)env-regs[R_ECX] - MSR_MTRRfix4K_C + 3]
= val;
+env-mtrr_fixed[(uint32_t)env-regs[R_ECX] -
+MSR_MTRRfix4K_C + 3] = val;
break;
case MSR_MTRRdefType:
env-mtrr_deftype = val;
@@ -399,7 +406,8 @@ void helper_wrmsr(CPUX86State *env)
break;
default:
if ((uint32_t)env-regs[R_ECX] = MSR_MC0_CTL
- (uint32_t)env-regs[R_ECX] MSR_MC0_CTL + (4 * env-mcg_cap
0xff)) {
+ (uint32_t)env-regs[R_ECX] MSR_MC0_CTL +
+(4 * env-mcg_cap 0xff)) {
uint32_t offset = (uint32_t)env-regs[R_ECX] - MSR_MC0_CTL;
if ((offset 0x3) != 0
|| (val == 0 || val == ~(uint64_t)0)) {
@@ -480,7 +488,8 @@ void helper_rdmsr(CPUX86State *env)
case MSR_MTRRphysBase(5):
case MSR_MTRRphysBase(6):
case MSR_MTRRphysBase(7):
-val = env-mtrr_var[((uint32_t)env-regs[R_ECX] - MSR_MTRRphysBase(0))
/ 2].base;
+val = env-mtrr_var[((uint32_t)env-regs[R_ECX] -
+ MSR_MTRRphysBase(0)) / 2].base;
break;
case MSR_MTRRphysMask(0):
case MSR_MTRRphysMask(1):
@@ -490,14 +499,16 @@ void helper_rdmsr(CPUX86State *env)
case MSR_MTRRphysMask(5):
case MSR_MTRRphysMask(6):
case MSR_MTRRphysMask(7):
-val = env-mtrr_var[((uint32_t)env-regs[R_ECX] - MSR_MTRRphysMask(0))
/ 2].mask;
+val = env-mtrr_var[((uint32_t)env-regs[R_ECX] -
+ MSR_MTRRphysMask(0)) / 2].mask;
break;
case MSR_MTRRfix64K_0:
val = env-mtrr_fixed[0];
break;
case MSR_MTRRfix16K_8:
case MSR_MTRRfix16K_A:
-val = env-mtrr_fixed[(uint32_t)env-regs[R_ECX] -
MSR_MTRRfix16K_8 + 1];
+val = env-mtrr_fixed[(uint32_t)env-regs[R_ECX] -
+ MSR_MTRRfix16K_8 + 1];
break;
case MSR_MTRRfix4K_C:
case MSR_MTRRfix4K_C8000:
@@ -507,7 +518,8 @@ void helper_rdmsr(CPUX86State *env)
case MSR_MTRRfix4K_E8000:
case MSR_MTRRfix4K_F:
case MSR_MTRRfix4K_F8000:
-val = env-mtrr_fixed[(uint32_t)env-regs[R_ECX] - MSR_MTRRfix4K_C
+ 3];
+val =
[Qemu-devel] [PATCH v4 11/12] target-i386/helper: remove redundant env-eip assignment
Signed-off-by: liguang lig.f...@cn.fujitsu.com --- target-i386/svm_helper.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/target-i386/svm_helper.c b/target-i386/svm_helper.c index 649be02..e18fa35 100644 --- a/target-i386/svm_helper.c +++ b/target-i386/svm_helper.c @@ -249,7 +249,7 @@ void helper_vmrun(CPUX86State *env, int aflag, int next_eip_addend) R_DS); env-eip = ldq_phys(env-vm_vmcb + offsetof(struct vmcb, save.rip)); -env-eip = env-eip; + env-regs[R_ESP] = ldq_phys(env-vm_vmcb + offsetof(struct vmcb, save.rsp)); env-regs[R_EAX] = ldq_phys(env-vm_vmcb + offsetof(struct vmcb, save.rax)); env-dr[7] = ldq_phys(env-vm_vmcb + offsetof(struct vmcb, save.dr7)); -- 1.7.2.5
Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
On Tue, 28 May 2013 14:40:30 +0800 li guang lig.f...@cn.fujitsu.com wrote: Hi, Michael 在 2013-05-28二的 09:31 +0300，Michael S. Tsirkin写道： On Tue, May 28, 2013 at 08:21:24AM +0800, li guang wrote: 在 2013-05-27一的 23:23 +0300，Michael S. Tsirkin写道： On Mon, May 27, 2013 at 09:22:59AM +0800, li guang wrote: 在 2013-05-26日的 19:51 -0500，Anthony Liguori写道： li guang lig.f...@cn.fujitsu.com writes: 在 2013-05-24五的 14:45 +0300，Michael S. Tsirkin写道： On Wed, May 22, 2013 at 11:46:33AM +0800, liguang wrote: These patches try to add ACPI Embedded Controller (EC), refer-to: ACPI SPEC v5 chapter 5 ACPI Embedded Controller Interface Specification EC is a standard ACPI device, it plays flexible roles, e.g. power controller, it can control power sequence for platform to enter or leave system state(0,1,3,4,5), it can controller CPU fan by the temperature of sensor. event carrier, it can pass events between platform and OS, so OS can execute _Qxx method which defined by yourself. So, I want to deliver CPU online/offline event between OS and QEMU for CPU hotplug feature, then we will don't need to echo 1 /sys/devices/system/cpu/cpu1/online again after 'cpu-add'. patches for online/offline event handler of QEUM and linux kernel are writing, and will send once finished. since EC is a common device, so I send pathes separately. Do any non-linux guests support this device? In fact, any OSes support ACPI will support this device. so, windows will. When you say any OSes supporting ACPI I think what you really mean is that we can provide bytecode that interacts with the embedded controller. There is not explicit driver in Linux or Windows AFAIK. Hmm, yep, mostly there's no special driver for EC, because it is directly embedded in code for ACPI for linux kernel, it's drivers/acpi/ec.c I still don't get the point of this. We can make ACPI hotplug work without introducing a new device like this. when you 'cpu-add' a cpu, acpi driver for cpu will not trigger 'cpu_up' for linux kernel AFAIK, unless you add a user space program to listen it's uevent and tigger 'cpu_up'. and EC is not only for ACPI hotplug for example, the 'pvpanic', if there's a EC, we can pass pvpanic event by EC's ACPI space or Q-event, then we will not need this kind of special devices anymore. So just to clarify: this patchset doesn't do anything useful itself, the first patch is pure EC implementation which is useful. Sorry, I didn't mean to imply that this is not useful, merely that it is not yet directly useful for users. Yep, by now, of course, only 1 user, that's me. :-) it's some infrastructure that you want to build on top of? Yes, I'd like to use EC as infrastructure for my further development. I (and apparently others in this thread) would like to know some more about planned use for this code before deciding on inclusion. OK, currently, I am using EC to pass cpu hotplug event between QEMU and linux kernel, and I'll post these patches later. then, I'll query usages like this in QEMU, and convert them to use EC's acpi approach if possible. When I see these patches for qemu/seebios/kernel, I probably would be able to comment on them. But right now I don't see benefits in switching CPU hot-plug to EC. Thanks!
[Qemu-devel] [PATCH v4 04/12] target-i386/helper: remove EDX macro
Signed-off-by: liguang lig.f...@cn.fujitsu.com
---
target-i386/cpu.h |2 --
target-i386/int_helper.c | 24
target-i386/mem_helper.c |8
target-i386/misc_helper.c |8
target-i386/seg_helper.c |8
target-i386/smm_helper.c |8
6 files changed, 28 insertions(+), 30 deletions(-)
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index b3c6fcb..ebc5abd 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -1101,8 +1101,6 @@ static inline int cpu_mmu_index (CPUX86State *env)
? MMU_KSMAP_IDX : MMU_KERNEL_IDX;
}
-#undef EDX
-#define EDX (env-regs[R_EDX])
#undef ESP
#define ESP (env-regs[R_ESP])
#undef EBP
diff --git a/target-i386/int_helper.c b/target-i386/int_helper.c
index 16d1ed5..0555318 100644
--- a/target-i386/int_helper.c
+++ b/target-i386/int_helper.c
@@ -81,7 +81,7 @@ void helper_divw_AX(CPUX86State *env, target_ulong t0)
{
unsigned int num, den, q, r;
-num = (env-regs[R_EAX] 0x) | ((EDX 0x) 16);
+num = (env-regs[R_EAX] 0x) | ((env-regs[R_EDX] 0x) 16);
den = (t0 0x);
if (den == 0) {
raise_exception(env, EXCP00_DIVZ);
@@ -93,14 +93,14 @@ void helper_divw_AX(CPUX86State *env, target_ulong t0)
q = 0x;
r = (num % den) 0x;
env-regs[R_EAX] = (env-regs[R_EAX] ~0x) | q;
-EDX = (EDX ~0x) | r;
+env-regs[R_EDX] = (env-regs[R_EDX] ~0x) | r;
}
void helper_idivw_AX(CPUX86State *env, target_ulong t0)
{
int num, den, q, r;
-num = (env-regs[R_EAX] 0x) | ((EDX 0x) 16);
+num = (env-regs[R_EAX] 0x) | ((env-regs[R_EDX] 0x) 16);
den = (int16_t)t0;
if (den == 0) {
raise_exception(env, EXCP00_DIVZ);
@@ -112,7 +112,7 @@ void helper_idivw_AX(CPUX86State *env, target_ulong t0)
q = 0x;
r = (num % den) 0x;
env-regs[R_EAX] = (env-regs[R_EAX] ~0x) | q;
-EDX = (EDX ~0x) | r;
+env-regs[R_EDX] = (env-regs[R_EDX] ~0x) | r;
}
void helper_divl_EAX(CPUX86State *env, target_ulong t0)
@@ -120,7 +120,7 @@ void helper_divl_EAX(CPUX86State *env, target_ulong t0)
unsigned int den, r;
uint64_t num, q;
-num = ((uint32_t)env-regs[R_EAX]) | ((uint64_t)((uint32_t)EDX) 32);
+num = ((uint32_t)env-regs[R_EAX]) |
((uint64_t)((uint32_t)env-regs[R_EDX]) 32);
den = t0;
if (den == 0) {
raise_exception(env, EXCP00_DIVZ);
@@ -131,7 +131,7 @@ void helper_divl_EAX(CPUX86State *env, target_ulong t0)
raise_exception(env, EXCP00_DIVZ);
}
env-regs[R_EAX] = (uint32_t)q;
-EDX = (uint32_t)r;
+env-regs[R_EDX] = (uint32_t)r;
}
void helper_idivl_EAX(CPUX86State *env, target_ulong t0)
@@ -139,7 +139,7 @@ void helper_idivl_EAX(CPUX86State *env, target_ulong t0)
int den, r;
int64_t num, q;
-num = ((uint32_t)env-regs[R_EAX]) | ((uint64_t)((uint32_t)EDX) 32);
+num = ((uint32_t)env-regs[R_EAX]) |
((uint64_t)((uint32_t)env-regs[R_EDX]) 32);
den = t0;
if (den == 0) {
raise_exception(env, EXCP00_DIVZ);
@@ -150,7 +150,7 @@ void helper_idivl_EAX(CPUX86State *env, target_ulong t0)
raise_exception(env, EXCP00_DIVZ);
}
env-regs[R_EAX] = (uint32_t)q;
-EDX = (uint32_t)r;
+env-regs[R_EDX] = (uint32_t)r;
}
/* bcd */
@@ -382,12 +382,12 @@ void helper_divq_EAX(CPUX86State *env, target_ulong t0)
raise_exception(env, EXCP00_DIVZ);
}
r0 = env-regs[R_EAX];
-r1 = EDX;
+r1 = env-regs[R_EDX];
if (div64(r0, r1, t0)) {
raise_exception(env, EXCP00_DIVZ);
}
env-regs[R_EAX] = r0;
-EDX = r1;
+env-regs[R_EDX] = r1;
}
void helper_idivq_EAX(CPUX86State *env, target_ulong t0)
@@ -398,12 +398,12 @@ void helper_idivq_EAX(CPUX86State *env, target_ulong t0)
raise_exception(env, EXCP00_DIVZ);
}
r0 = env-regs[R_EAX];
-r1 = EDX;
+r1 = env-regs[R_EDX];
if (idiv64(r0, r1, t0)) {
raise_exception(env, EXCP00_DIVZ);
}
env-regs[R_EAX] = r0;
-EDX = r1;
+env-regs[R_EDX] = r1;
}
#endif
diff --git a/target-i386/mem_helper.c b/target-i386/mem_helper.c
index 41ac847..319a219 100644
--- a/target-i386/mem_helper.c
+++ b/target-i386/mem_helper.c
@@ -45,13 +45,13 @@ void helper_cmpxchg8b(CPUX86State *env, target_ulong a0)
eflags = cpu_cc_compute_all(env, CC_OP);
d = cpu_ldq_data(env, a0);
-if (d == (((uint64_t)EDX 32) | (uint32_t)env-regs[R_EAX])) {
+if (d == (((uint64_t)env-regs[R_EDX] 32) |
(uint32_t)env-regs[R_EAX])) {
cpu_stq_data(env, a0, ((uint64_t)env-regs[R_ECX] 32) |
(uint32_t)env-regs[R_EBX]);
eflags |= CC_Z;
} else {
/* always do the store */
cpu_stq_data(env, a0, d);
-EDX = (uint32_t)(d 32);
+env-regs[R_EDX] = (uint32_t)(d 32);
env-regs[R_EAX] = (uint32_t)d;
eflags = ~CC_Z;
}
@@ -70,7 +70,7 @@ void
Re: [Qemu-devel] [PATCH] ide: Set BSY bit during FLUSH
Am 28.05.2013 um 10:18 hat Andreas Färber geschrieben:
The implementation of the ATA FLUSH command invokes a flush at the block
layer, which may on raw files on POSIX entail a synchronous fdatasync().
This may in some cases take so long that the SLES 11 SP1 guest driver
reports I/O errors and filesystems get corrupted or remounted read-only.
Avoid this by setting BUSY_STAT, so that the guest is made aware we are
in the middle of an operation and no ATA commands are attempted to be
processed concurrently.
Addresses BNC#637297.
Suggested-by: Gonglei (Arei) arei.gong...@huawei.com
Signed-off-by: Andreas Färber afaer...@suse.de
---
hw/ide/core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index c7a8041..bf1ff18 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -795,6 +795,8 @@ static void ide_flush_cb(void *opaque, int ret)
{
IDEState *s = opaque;
+s-status = ~BUSY_STAT;
+
This part is unnecessary, the status is already reset.
if (ret 0) {
/* XXX: What sector number to set here? */
if (ide_handle_rw_error(s, -ret, BM_STATUS_RETRY_FLUSH)) {
@@ -814,6 +816,7 @@ void ide_flush_cache(IDEState *s)
return;
}
+s-status |= BUSY_STAT;
bdrv_acct_start(s-bs, s-acct, 0, BDRV_ACCT_FLUSH);
bdrv_aio_flush(s-bs, ide_flush_cb, s);
}
This should fix the bug, however in an one-off way. I was planning to
fix it by setting BSY for all commands and having an explicit command
completion everywhere. This part is a mess currently in IDE.
The other part why I haven't sent a fix yet is that I don't have a test
case for it. I guess I need to extend blkdebug first before this can be
reliably tested by qtest.
Kevin
Re: [Qemu-devel] [PATCH v4 00/12] target-i386: remove some macros
Am 28.05.2013 10:19, schrieb li guang: remove macros EAX, EBX, ECX, EDX, EBP, ESP, ESI, EDI, EIP, DF as suggested by Richard Henderson r...@twiddle.net v4: fix alignment issue in patch 6. Thanks, I reviewed patch 6, the rest was already Reviewed-by, so Li Guang (12) target-i386/helper: remove EAX macro target-i386/helper: remove EBX macro target-i386/helper: remove ECX macro target-i386/helper: remove EDX macro target-i386/helper: remove EBP macro target-i386/helper: remove ESP macro target-i386/helper: remove ESI macro target-i386/helper: remove EDI macro target-i386/helper: remove EIP macro target-i386/helper: remove DF macro target-i386/helper: remove redundant env-eip assignment target-i386: fix over 80 chars warnings Reviewed-by: Andreas Färber afaer...@suse.de Thanks, Andreas cpu-exec.c| 4 ++-- target-i386/cc_helper.c | 2 +- target-i386/cpu.h | 24 - target-i386/excp_helper.c | 2 +- target-i386/int_helper.c | 86 ++-- target-i386/mem_helper.c | 24 +++--- target-i386/misc_helper.c | 107 +++--- target-i386/seg_helper.c | 182 +++--- target-i386/smm_helper.c | 64 +++--- target-i386/svm_helper.c | 66 10 files changed, 280 insertions(+), 281 deletions(-) -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
On Tue, May 28, 2013 at 10:01:14AM +0200, Paolo Bonzini wrote: Il 28/05/2013 09:13, Wenchao Xia ha scritto: From: Nicholas Bellinger n...@linux-iscsi.org The WWPN specified in configfs is passed to -device vhost-scsi-pci. The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is not available from the QEMU command-line. Instead, I hardcode it to zero. Hi, Paolo Any document about how to config it correctly in configfs, before invoking qemu with the WWPN number? Unfortunately no, but vhost-scsi doesn't have many knobs (unlike iSCSI for example) so it's quite simple. Here is an example: cd /sys/kernel/config/target mkdir -p core/fileio_0/fileio echo 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' core/fileio_0/fileio/control echo 1 core/fileio_0/fileio/enable mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0 cd vhost/naa.600140554cf3a18e/tpgt_0 ln -sf ../../../../../core/fileio_0/fileio/ lun/lun_0/virtual_scsi_port echo naa.60014053226f0388 nexus The nexus value is the initiator WWN. naa.600140554cf3a18e is the target WWN that you have to pass to -device vhost-scsi-pci. Paolo For me, I always use targetcli utils instead of the sysfs interface. targetcli in F18 has vhost support now. -- Asias
Re: [Qemu-devel] [PATCH] block: add read only to whitelist
On Tue, 05/28 10:10, Paolo Bonzini wrote:
Il 28/05/2013 08:44, Fam Zheng ha scritto:
diff --git a/scripts/create_config b/scripts/create_config
index c471e8c..2dfda3e 100755
--- a/scripts/create_config
+++ b/scripts/create_config
@@ -35,11 +35,18 @@ case $line in
echo
;;
CONFIG_BDRV_WHITELIST=*)
-echo #define CONFIG_BDRV_WHITELIST \\
+echo #define CONFIG_BDRV_WHITELIST_RW \\
for drv in ${line#*=}; do
+ [[ ${drv} = ^* ]] continue;
I didn't know about this feature. Can you point me to the documentation?
Yes, it is bash only, I'd better use a more compatible way.
http://mywiki.wooledge.org/glob
You would need to change the #! header to #! /bin/bash if you use it,
but since you have to respin anyway, I'd ask you to use case instead. :)
As Stefan and Kevin pointed out, I'll replace ^ prefix with a separate
configure option, it'll become
CONFIG_BDRV_WHITELIST_RW=*)
...
;;
CONFIG_BDRV_WHITELIST_RO=*)
...
;;
Then I won't need globbing.
--
Fam
Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
在 2013-05-28二的 10:16 +0200，Igor Mammedov写道：
On Tue, 28 May 2013 08:28:09 +0800
li guang lig.f...@cn.fujitsu.com wrote:
在 2013-05-27一的 13:45 +0200，Igor Mammedov写道：
On Mon, 27 May 2013 09:22:59 +0800
li guang lig.f...@cn.fujitsu.com wrote:
在 2013-05-26日的 19:51 -0500，Anthony Liguori写道：
li guang lig.f...@cn.fujitsu.com writes:
在 2013-05-24五的 14:45 +0300，Michael S. Tsirkin写道：
On Wed, May 22, 2013 at 11:46:33AM +0800, liguang wrote:
These patches try to add ACPI Embedded Controller (EC),
refer-to:
ACPI SPEC v5 chapter 5
ACPI Embedded Controller Interface Specification
EC is a standard ACPI device, it plays flexible roles,
e.g.
power controller, it can control power sequence for
platform to enter or leave system state(0,1,3,4,5),
it can controller CPU fan by the temperature of sensor.
event carrier, it can pass events between platform
and OS, so OS can execute _Qxx method which defined
by yourself.
So, I want to deliver CPU online/offline event between
OS and QEMU for CPU hotplug feature, then we will don't
need to echo 1 /sys/devices/system/cpu/cpu1/online
again after 'cpu-add'.
patches for online/offline event handler of QEUM and
linux kernel are writing, and will send once finished.
since EC is a common device, so I send pathes separately.
Do any non-linux guests support this device?
In fact, any OSes support ACPI will support this device.
so, windows will.
When you say any OSes supporting ACPI I think what you really mean
is
that we can provide bytecode that interacts with the embedded
controller.
There is not explicit driver in Linux or Windows AFAIK.
Hmm, yep, mostly there's no special driver for EC,
because it is directly embedded in code for ACPI
for linux kernel, it's drivers/acpi/ec.c
I still don't get the point of this. We can make ACPI hotplug work
without introducing a new device like this.
when you 'cpu-add' a cpu, acpi driver for cpu will not
trigger 'cpu_up' for linux kernel AFAIK, unless you add
a user space program to listen it's uevent and tigger 'cpu_up'.
it is up to guest OS policy to decide if CPU should be onlined or not,
Yep, but I think it's a favor to do cpu online.
Then you have to teach kernel driver (EC) to do cpu_up on _Q02 event,
I think it's not necessary to do this.
we can also add another platform driver to listen cpu plug/unplug event
and query EC's ACPI space to decide what to do next.
the question is why would you do this when there is ACPI processor driver
already that handles CPU hotplug in kernel.
You can try add cpu_up() there and perhaps with good enough reasoning it
would be accepted.
it's not so convenient to trigger cpu_up/down process for ACPI processor
driver as far as I can see, it seems like informal or hack there.
so I'd like to make a bridge between them.
but, anyway, it's a good point to think about or even try to do.
at least I've seen this rationale on LKML when topic was discussed and
automatic cpu_up on hotplug was rejected.
Oh, and the reason is?
Reason was to let guest decide whether online new CPU or nor instead of
doing it unconditionally.
can this be a Kconfig option?
or it's strongly recommended to let guest decide?
can you give me a link?
I'm sorry but I can't find link quickly.
Oh, Igor,
I remember that you said you can give me some your considerations
on the further development of cpu hotplug feature, but I haven't got
them :-)
I'm sorry, I haven't time yet to update TODO list on wiki page:
But here some items that need some attention:
* try to introduce generic QOM interface for CPU topology introspection
something like
/machine/node/socket[xxx]/{(core[yyy]/thread[zzz])|thread[zzz]}
* allow to specify at CLI specific CPUs to be created at start-up time
- important for hot-adding/removing an arbitrary CPU
- probably depends on previous item so that each CPU could be specified by
socket/core/thread numbers
* extend/rework -numa CLI option to support socket to node binding
- goal is to obsolete node to thread biding which allows specify incorrect
topology.
OK, thank you so much!
[Qemu-devel] [PATCH v4 10/12] target-i386/helper: remove DF macro
Signed-off-by: liguang lig.f...@cn.fujitsu.com
---
cpu-exec.c |4 ++--
target-i386/cc_helper.c |2 +-
target-i386/cpu.h |6 ++
3 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/cpu-exec.c b/cpu-exec.c
index 31c089d..ec46380 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -230,7 +230,7 @@ int cpu_exec(CPUArchState *env)
#if defined(TARGET_I386)
/* put eflags in CPU temporary format */
CC_SRC = env-eflags (CC_O | CC_S | CC_Z | CC_A | CC_P | CC_C);
-DF = 1 - (2 * ((env-eflags 10) 1));
+env-df = 1 - (2 * ((env-eflags 10) 1));
CC_OP = CC_OP_EFLAGS;
env-eflags = ~(DF_MASK | CC_O | CC_S | CC_Z | CC_A | CC_P | CC_C);
#elif defined(TARGET_SPARC)
@@ -681,7 +681,7 @@ int cpu_exec(CPUArchState *env)
#if defined(TARGET_I386)
/* restore flags in standard format */
env-eflags = env-eflags | cpu_cc_compute_all(env, CC_OP)
-| (DF DF_MASK);
+| (env-df DF_MASK);
#elif defined(TARGET_ARM)
/* XXX: Save/restore host fpu exception state?. */
#elif defined(TARGET_UNICORE32)
diff --git a/target-i386/cc_helper.c b/target-i386/cc_helper.c
index 9daa1a0..ee04092 100644
--- a/target-i386/cc_helper.c
+++ b/target-i386/cc_helper.c
@@ -331,7 +331,7 @@ target_ulong helper_read_eflags(CPUX86State *env)
uint32_t eflags;
eflags = cpu_cc_compute_all(env, CC_OP);
-eflags |= (DF DF_MASK);
+eflags |= (env-df DF_MASK);
eflags |= env-eflags ~(VM_MASK | RF_MASK);
return eflags;
}
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index b909f73..62e3547 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -1101,8 +1101,6 @@ static inline int cpu_mmu_index (CPUX86State *env)
? MMU_KSMAP_IDX : MMU_KERNEL_IDX;
}
-#define DF (env-df)
-
#define CC_DST (env-cc_dst)
#define CC_SRC (env-cc_src)
#define CC_SRC2 (env-cc_src2)
@@ -1196,7 +1194,7 @@ uint32_t cpu_cc_compute_all(CPUX86State *env1, int op);
static inline uint32_t cpu_compute_eflags(CPUX86State *env)
{
-return env-eflags | cpu_cc_compute_all(env, CC_OP) | (DF DF_MASK);
+return env-eflags | cpu_cc_compute_all(env, CC_OP) | (env-df DF_MASK);
}
/* NOTE: CC_OP must be modified manually to CC_OP_EFLAGS */
@@ -1204,7 +1202,7 @@ static inline void cpu_load_eflags(CPUX86State *env, int
eflags,
int update_mask)
{
CC_SRC = eflags (CC_O | CC_S | CC_Z | CC_A | CC_P | CC_C);
-DF = 1 - (2 * ((eflags 10) 1));
+env-df = 1 - (2 * ((eflags 10) 1));
env-eflags = (env-eflags ~update_mask) |
(eflags update_mask) | 0x2;
}
--
1.7.2.5
[Qemu-devel] [PATCH v4 06/12] target-i386/helper: remove ESP macro
Signed-off-by: liguang lig.f...@cn.fujitsu.com
---
target-i386/cpu.h|2 -
target-i386/seg_helper.c | 90 +++--
target-i386/smm_helper.c |8 ++--
target-i386/svm_helper.c |8 ++--
4 files changed, 54 insertions(+), 54 deletions(-)
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index fc0cf65..6b058bb 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -1101,8 +1101,6 @@ static inline int cpu_mmu_index (CPUX86State *env)
? MMU_KSMAP_IDX : MMU_KERNEL_IDX;
}
-#undef ESP
-#define ESP (env-regs[R_ESP])
#undef ESI
#define ESI (env-regs[R_ESI])
#undef EDI
diff --git a/target-i386/seg_helper.c b/target-i386/seg_helper.c
index 56db00f..0c4b3d8 100644
--- a/target-i386/seg_helper.c
+++ b/target-i386/seg_helper.c
@@ -328,7 +328,7 @@ static void switch_tss(CPUX86State *env, int tss_selector,
cpu_stl_kernel(env, env-tr.base + (0x28 + 1 * 4), env-regs[R_ECX]);
cpu_stl_kernel(env, env-tr.base + (0x28 + 2 * 4), env-regs[R_EDX]);
cpu_stl_kernel(env, env-tr.base + (0x28 + 3 * 4), env-regs[R_EBX]);
-cpu_stl_kernel(env, env-tr.base + (0x28 + 4 * 4), ESP);
+cpu_stl_kernel(env, env-tr.base + (0x28 + 4 * 4), env-regs[R_ESP]);
cpu_stl_kernel(env, env-tr.base + (0x28 + 5 * 4), env-regs[R_EBP]);
cpu_stl_kernel(env, env-tr.base + (0x28 + 6 * 4), ESI);
cpu_stl_kernel(env, env-tr.base + (0x28 + 7 * 4), EDI);
@@ -344,7 +344,7 @@ static void switch_tss(CPUX86State *env, int tss_selector,
cpu_stw_kernel(env, env-tr.base + (0x12 + 1 * 2), env-regs[R_ECX]);
cpu_stw_kernel(env, env-tr.base + (0x12 + 2 * 2), env-regs[R_EDX]);
cpu_stw_kernel(env, env-tr.base + (0x12 + 3 * 2), env-regs[R_EBX]);
-cpu_stw_kernel(env, env-tr.base + (0x12 + 4 * 2), ESP);
+cpu_stw_kernel(env, env-tr.base + (0x12 + 4 * 2), env-regs[R_ESP]);
cpu_stw_kernel(env, env-tr.base + (0x12 + 5 * 2), env-regs[R_EBP]);
cpu_stw_kernel(env, env-tr.base + (0x12 + 6 * 2), ESI);
cpu_stw_kernel(env, env-tr.base + (0x12 + 7 * 2), EDI);
@@ -400,7 +400,7 @@ static void switch_tss(CPUX86State *env, int tss_selector,
env-regs[R_ECX] = new_regs[1];
env-regs[R_EDX] = new_regs[2];
env-regs[R_EBX] = new_regs[3];
-ESP = new_regs[4];
+env-regs[R_ESP] = new_regs[4];
env-regs[R_EBP] = new_regs[5];
ESI = new_regs[6];
EDI = new_regs[7];
@@ -502,20 +502,22 @@ static int exception_has_error_code(int intno)
}
#ifdef TARGET_X86_64
-#define SET_ESP(val, sp_mask) \
-do {\
-if ((sp_mask) == 0x) { \
-ESP = (ESP ~0x) | ((val) 0x); \
-} else if ((sp_mask) == 0xLL) { \
-ESP = (uint32_t)(val); \
-} else {\
-ESP = (val);\
-} \
+#define SET_ESP(val, sp_mask) \
+do {\
+if ((sp_mask) == 0x) { \
+env-regs[R_ESP] = (env-regs[R_ESP] ~0x) | \
+((val) 0x); \
+} else if ((sp_mask) == 0xLL) { \
+env-regs[R_ESP] = (uint32_t)(val); \
+} else {\
+env-regs[R_ESP] = (val); \
+} \
} while (0)
#else
-#define SET_ESP(val, sp_mask) \
-do {\
-ESP = (ESP ~(sp_mask)) | ((val) (sp_mask)); \
+#define SET_ESP(val, sp_mask) \
+do {\
+env-regs[R_ESP] = (env-regs[R_ESP] ~(sp_mask)) |\
+((val) (sp_mask));\
} while (0)
#endif
@@ -598,7 +600,7 @@ static void do_interrupt_protected(CPUX86State *env, int
intno, int is_int,
} else {
mask = 0x;
}
-esp = (ESP - (2 shift)) mask;
+esp = (env-regs[R_ESP] - (2 shift)) mask;
ssp = env-segs[R_SS].base + esp;
if (shift) {
cpu_stl_kernel(env, ssp, error_code);
@@ -680,7 +682,7 @@ static void do_interrupt_protected(CPUX86State *env, int
intno, int is_int,
new_stack = 0;
sp_mask = get_sp_mask(env-segs[R_SS].flags);
ssp = env-segs[R_SS].base;
-esp = ESP;
+esp = env-regs[R_ESP];
dpl = cpl;
} else {
raise_exception_err(env, EXCP0D_GPF, selector 0xfffc);
@@ -709,7
Re: [Qemu-devel] [Bug 1184616] [NEW] undefined reference to`trace_qemu_anon_ram_alloc'
On Mon, May 27, 2013 at 09:04:26PM -, Nigel Horne wrote: On Mon, May 27, 2013 at 4:02 PM, Nigel Horne 1184...@bugs.launchpad.net wrote: The latest git version (commit 6a4e17711442849bf2cc731ccddef5a2a2d92d29) fails to compile: ... LINK qemu-ga libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_alloc': oslib-posix.c:(.text+0x154): undefined reference to `trace_qemu_anon_ram_alloc' libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_free': oslib-posix.c:(.text+0x1e7): undefined reference to `trace_qemu_anon_ram_free' collect2: error: ld returned 1 exit status make: *** [qemu-ga] Error 1 This is on Ubuntu 13.04, gcc 4.7.3, configure flags: './configure' '--enable-linux-aio' '--enable-kvm' '--enable-vhost-net' Please try: make distclean ./configure --enable-linux-aio --enable-kvm --enable-vhost-net make I tried that before I raised the bug. However I tried it again to be sure, and yes I still get the same error. Please post the output of git status. I wonder if there are stale files because the build works fine here. Stefan
Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
Hi, Igor 在 2013-05-28二的 10:26 +0200，Igor Mammedov写道： On Tue, 28 May 2013 14:40:30 +0800 li guang lig.f...@cn.fujitsu.com wrote: Hi, Michael 在 2013-05-28二的 09:31 +0300，Michael S. Tsirkin写道： On Tue, May 28, 2013 at 08:21:24AM +0800, li guang wrote: 在 2013-05-27一的 23:23 +0300，Michael S. Tsirkin写道： On Mon, May 27, 2013 at 09:22:59AM +0800, li guang wrote: 在 2013-05-26日的 19:51 -0500，Anthony Liguori写道： li guang lig.f...@cn.fujitsu.com writes: 在 2013-05-24五的 14:45 +0300，Michael S. Tsirkin写道： On Wed, May 22, 2013 at 11:46:33AM +0800, liguang wrote: These patches try to add ACPI Embedded Controller (EC), refer-to: ACPI SPEC v5 chapter 5 ACPI Embedded Controller Interface Specification EC is a standard ACPI device, it plays flexible roles, e.g. power controller, it can control power sequence for platform to enter or leave system state(0,1,3,4,5), it can controller CPU fan by the temperature of sensor. event carrier, it can pass events between platform and OS, so OS can execute _Qxx method which defined by yourself. So, I want to deliver CPU online/offline event between OS and QEMU for CPU hotplug feature, then we will don't need to echo 1 /sys/devices/system/cpu/cpu1/online again after 'cpu-add'. patches for online/offline event handler of QEUM and linux kernel are writing, and will send once finished. since EC is a common device, so I send pathes separately. Do any non-linux guests support this device? In fact, any OSes support ACPI will support this device. so, windows will. When you say any OSes supporting ACPI I think what you really mean is that we can provide bytecode that interacts with the embedded controller. There is not explicit driver in Linux or Windows AFAIK. Hmm, yep, mostly there's no special driver for EC, because it is directly embedded in code for ACPI for linux kernel, it's drivers/acpi/ec.c I still don't get the point of this. We can make ACPI hotplug work without introducing a new device like this. when you 'cpu-add' a cpu, acpi driver for cpu will not trigger 'cpu_up' for linux kernel AFAIK, unless you add a user space program to listen it's uevent and tigger 'cpu_up'. and EC is not only for ACPI hotplug for example, the 'pvpanic', if there's a EC, we can pass pvpanic event by EC's ACPI space or Q-event, then we will not need this kind of special devices anymore. So just to clarify: this patchset doesn't do anything useful itself, the first patch is pure EC implementation which is useful. Sorry, I didn't mean to imply that this is not useful, merely that it is not yet directly useful for users. Yep, by now, of course, only 1 user, that's me. :-) it's some infrastructure that you want to build on top of? Yes, I'd like to use EC as infrastructure for my further development. I (and apparently others in this thread) would like to know some more about planned use for this code before deciding on inclusion. OK, currently, I am using EC to pass cpu hotplug event between QEMU and linux kernel, and I'll post these patches later. then, I'll query usages like this in QEMU, and convert them to use EC's acpi approach if possible. When I see these patches for qemu/seebios/kernel, I probably would be able to comment on them. I'll send a RFC patch-set which will include all my work tomorrow. But right now I don't see benefits in switching CPU hot-plug to EC. sorry, maybe a mistake here, I am not trying to switching CPU hot-plug to EC, but just make EC as a helper to do CPU hot-plug, like pass plug/unplug event between OS and platform, it's convenient.
Re: [Qemu-devel] [PATCH] ide: Set BSY bit during FLUSH
Am 28.05.2013 10:27, schrieb Kevin Wolf:
Am 28.05.2013 um 10:18 hat Andreas Färber geschrieben:
The implementation of the ATA FLUSH command invokes a flush at the block
layer, which may on raw files on POSIX entail a synchronous fdatasync().
This may in some cases take so long that the SLES 11 SP1 guest driver
reports I/O errors and filesystems get corrupted or remounted read-only.
Avoid this by setting BUSY_STAT, so that the guest is made aware we are
in the middle of an operation and no ATA commands are attempted to be
processed concurrently.
Addresses BNC#637297.
Suggested-by: Gonglei (Arei) arei.gong...@huawei.com
Signed-off-by: Andreas Färber afaer...@suse.de
---
hw/ide/core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index c7a8041..bf1ff18 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -795,6 +795,8 @@ static void ide_flush_cb(void *opaque, int ret)
{
IDEState *s = opaque;
+s-status = ~BUSY_STAT;
+
This part is unnecessary, the status is already reset.
Only in the ret = 0 case though AFAICS?
if (ret 0) {
/* XXX: What sector number to set here? */
if (ide_handle_rw_error(s, -ret, BM_STATUS_RETRY_FLUSH)) {
@@ -814,6 +816,7 @@ void ide_flush_cache(IDEState *s)
return;
}
+s-status |= BUSY_STAT;
bdrv_acct_start(s-bs, s-acct, 0, BDRV_ACCT_FLUSH);
bdrv_aio_flush(s-bs, ide_flush_cb, s);
}
This should fix the bug, however in an one-off way. I was planning to
fix it by setting BSY for all commands and having an explicit command
completion everywhere. This part is a mess currently in IDE.
That's a valid idea, but I had backporting to 0.15 in mind. ;)
And doh, I forgot qemu-stable.
The other part why I haven't sent a fix yet is that I don't have a test
case for it.
Temporarily add a sleep(31) in qemu_fdatasync()?
I was lazy in testing with -snapshot to not corrupt my disk image, which
would not trigger the same issue since qcow2-backed AFAIU.
I guess I need to extend blkdebug first before this can be
reliably tested by qtest.
It can't, since it's not a pure device emulation issue but depends on
the relative timing of filesystem operations and subsequent commands.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH v6 00/12] curl: fix curl read
On Tue, May 28, 2013 at 08:47:59AM +0100, Richard W.M. Jones wrote: I'm not sure if a Windows guest is somehow necessary to show the errors. I'll retest with a Linux guest and get back to you about that. Reproducible with Linux guest (remotely over slow Wifi). Also I'm testing against a remote Apache2 server over a very slow Wifi connection. Whereas your test was against localhost. Again, I will test this scenario to see if that makes a difference and get back to you. NOT reproducible with Windows XP guest over localhost, Apache2 server. So it seems to have something to do with the long latency and/or low bandwidth of the slow wifi connection here. I will add: This bug is not 100% reproducible on every run. However it does occur very frequently, probably in 9 out of 10 runs for me. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org
Re: [Qemu-devel] [Bug 1184616] [NEW] undefined reference to`trace_qemu_anon_ram_alloc'
On Tue, 05/28 10:38, Stefan Hajnoczi wrote: On Mon, May 27, 2013 at 09:04:26PM -, Nigel Horne wrote: On Mon, May 27, 2013 at 4:02 PM, Nigel Horne 1184...@bugs.launchpad.net wrote: The latest git version (commit 6a4e17711442849bf2cc731ccddef5a2a2d92d29) fails to compile: ... LINK qemu-ga libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_alloc': oslib-posix.c:(.text+0x154): undefined reference to `trace_qemu_anon_ram_alloc' libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_free': oslib-posix.c:(.text+0x1e7): undefined reference to `trace_qemu_anon_ram_free' collect2: error: ld returned 1 exit status make: *** [qemu-ga] Error 1 This is on Ubuntu 13.04, gcc 4.7.3, configure flags: './configure' '--enable-linux-aio' '--enable-kvm' '--enable-vhost-net' Please try: make distclean ./configure --enable-linux-aio --enable-kvm --enable-vhost-net make I tried that before I raised the bug. However I tried it again to be sure, and yes I still get the same error. Please post the output of git status. I wonder if there are stale files because the build works fine here. Stefan In my case, git ignored files may also have affects. So make distclean then git clean -dfx is worth a try. -- Fam
Re: [Qemu-devel] [PATCH v6 00/12] curl: fix curl read
On Tue, 05/28 09:46, Richard W.M. Jones wrote: On Tue, May 28, 2013 at 08:47:59AM +0100, Richard W.M. Jones wrote: I'm not sure if a Windows guest is somehow necessary to show the errors. I'll retest with a Linux guest and get back to you about that. Reproducible with Linux guest (remotely over slow Wifi). Also I'm testing against a remote Apache2 server over a very slow Wifi connection. Whereas your test was against localhost. Again, I will test this scenario to see if that makes a difference and get back to you. NOT reproducible with Windows XP guest over localhost, Apache2 server. So it seems to have something to do with the long latency and/or low bandwidth of the slow wifi connection here. I will add: This bug is not 100% reproducible on every run. However it does occur very frequently, probably in 9 out of 10 runs for me. Rich. OK, I'll try a remote image then. -- Fam
Re: [Qemu-devel] [PATCH v3] qemu: fix out of tree cross compile
Il 28/05/2013 01:49, Alexey Kardashevskiy ha scritto: The symlink to asm platform linux headers is made in the build tree by the configure script but gcc is not told to look for them there. The patch fixes this. Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru --- The previous patch did not remove the old line adding includes. Early morning, lack of focus :) --- configure |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 5ae7e4a..eca2a20 100755 --- a/configure +++ b/configure @@ -547,7 +547,7 @@ Haiku) if [ $cpu = i386 -o $cpu = x86_64 ] ; then audio_possible_drivers=$audio_possible_drivers fmod fi - QEMU_INCLUDES=-I\$(SRC_PATH)/linux-headers $QEMU_INCLUDES + QEMU_INCLUDES=-I\$(SRC_PATH)/linux-headers -I$(pwd)/linux-headers $QEMU_INCLUDES ;; esac Reviewed-by: Paolo Bonzini pbonz...@redhat.com Paolo
Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
于 2013-5-28 16:33, Asias He 写道: On Tue, May 28, 2013 at 10:01:14AM +0200, Paolo Bonzini wrote: Il 28/05/2013 09:13, Wenchao Xia ha scritto: From: Nicholas Bellinger n...@linux-iscsi.org The WWPN specified in configfs is passed to -device vhost-scsi-pci. The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is not available from the QEMU command-line. Instead, I hardcode it to zero. Hi, Paolo Any document about how to config it correctly in configfs, before invoking qemu with the WWPN number? Unfortunately no, but vhost-scsi doesn't have many knobs (unlike iSCSI for example) so it's quite simple. Here is an example: cd /sys/kernel/config/target mkdir -p core/fileio_0/fileio echo 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' core/fileio_0/fileio/control echo 1 core/fileio_0/fileio/enable mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0 cd vhost/naa.600140554cf3a18e/tpgt_0 ln -sf ../../../../../core/fileio_0/fileio/ lun/lun_0/virtual_scsi_port echo naa.60014053226f0388 nexus The nexus value is the initiator WWN. naa.600140554cf3a18e is the target WWN that you have to pass to -device vhost-scsi-pci. Paolo For me, I always use targetcli utils instead of the sysfs interface. targetcli in F18 has vhost support now. Thanks very much for above information, I'll try it for test. -- Best Regards Wenchao Xia
Re: [Qemu-devel] [PATCH 1/4] configure: Require libfdt for arm, ppc, microblaze softmmu targets
Am 24.05.2013 17:26, schrieb Peter Maydell: A number of our softmmu targets (PPC, ARM, Microblaze) now more or less require flattened device tree support for various board models to work correctly. Make libfdt mandatory if the target list includes these, rather than building unhelpful half-functional binaries. Signed-off-by: Peter Maydell peter.mayd...@linaro.org --- configure | 20 1 file changed, 20 insertions(+) diff --git a/configure b/configure index 5ae7e4a..708c010 100755 --- a/configure +++ b/configure @@ -2518,6 +2518,26 @@ fi ## # fdt probe +# fdt support is mandatory for at least some target architectures, +# so insist on it if we're building those system emulators. +fdt_required=no +for target in $target_list; do + case $target in +arm*softmmu|ppc*softmmu|microblaze*softmmu) Assuming you'll apply this through your tree, it would be more self-explanatory to use foo*-softmmu despite no practical difference. I'm guessing arm* is in preparation for a future armeb-softmmu? Otherwise looks good; still have testing pseries on my TODO list. Andreas + fdt_required=yes +;; + esac +done + +if test $fdt_required = yes; then + if test $fdt = no; then +error_exit fdt disabled but some requested targets require it. \ + You can turn off fdt only if you also disable all the system emulation \ + targets which need it (by specifying a cut down --target-list). + fi + fdt=yes +fi + if test $fdt != no ; then fdt_libs=-lfdt cat $TMPC EOF -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH v3] qemu: fix out of tree cross compile
Am 28.05.2013 10:54, schrieb Paolo Bonzini: Il 28/05/2013 01:49, Alexey Kardashevskiy ha scritto: The symlink to asm platform linux headers is made in the build tree by the configure script but gcc is not told to look for them there. The patch fixes this. Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru --- The previous patch did not remove the old line adding includes. Early morning, lack of focus :) --- configure |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 5ae7e4a..eca2a20 100755 --- a/configure +++ b/configure @@ -547,7 +547,7 @@ Haiku) if [ $cpu = i386 -o $cpu = x86_64 ] ; then audio_possible_drivers=$audio_possible_drivers fmod fi - QEMU_INCLUDES=-I\$(SRC_PATH)/linux-headers $QEMU_INCLUDES + QEMU_INCLUDES=-I\$(SRC_PATH)/linux-headers -I$(pwd)/linux-headers $QEMU_INCLUDES ;; esac Reviewed-by: Paolo Bonzini pbonz...@redhat.com Hm, I see no other case of adding $(pwd) to QEMU_INCLUDES - shouldn't this just be -Ilinux-headers? And might it make sense to give the build directory precedence over the source directory? Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH] ide: Set BSY bit during FLUSH
Am 28.05.2013 um 10:46 hat Andreas Färber geschrieben:
Am 28.05.2013 10:27, schrieb Kevin Wolf:
Am 28.05.2013 um 10:18 hat Andreas Färber geschrieben:
The implementation of the ATA FLUSH command invokes a flush at the block
layer, which may on raw files on POSIX entail a synchronous fdatasync().
This may in some cases take so long that the SLES 11 SP1 guest driver
reports I/O errors and filesystems get corrupted or remounted read-only.
Avoid this by setting BUSY_STAT, so that the guest is made aware we are
in the middle of an operation and no ATA commands are attempted to be
processed concurrently.
Addresses BNC#637297.
Suggested-by: Gonglei (Arei) arei.gong...@huawei.com
Signed-off-by: Andreas Färber afaer...@suse.de
---
hw/ide/core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index c7a8041..bf1ff18 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -795,6 +795,8 @@ static void ide_flush_cb(void *opaque, int ret)
{
IDEState *s = opaque;
+s-status = ~BUSY_STAT;
+
This part is unnecessary, the status is already reset.
Only in the ret = 0 case though AFAICS?
ide_handle_rw_error() takes care of resetting the status as well, except
when the VM is stopped. But then it will be immediately set again when
the VM is continued and the request is restarted. So the semantic
difference is just whether BSY would be set or not when you somehow
inspect the state while the VM is stopped after an I/O error.
if (ret 0) {
/* XXX: What sector number to set here? */
if (ide_handle_rw_error(s, -ret, BM_STATUS_RETRY_FLUSH)) {
@@ -814,6 +816,7 @@ void ide_flush_cache(IDEState *s)
return;
}
+s-status |= BUSY_STAT;
bdrv_acct_start(s-bs, s-acct, 0, BDRV_ACCT_FLUSH);
bdrv_aio_flush(s-bs, ide_flush_cb, s);
}
This should fix the bug, however in an one-off way. I was planning to
fix it by setting BSY for all commands and having an explicit command
completion everywhere. This part is a mess currently in IDE.
That's a valid idea, but I had backporting to 0.15 in mind. ;)
And doh, I forgot qemu-stable.
Fair enough, we can merge something like this first and do the real
thing on top. Though nobody will be interested in the real thing any
more, as usual... :-/
The other part why I haven't sent a fix yet is that I don't have a test
case for it.
Temporarily add a sleep(31) in qemu_fdatasync()?
I was lazy in testing with -snapshot to not corrupt my disk image, which
would not trigger the same issue since qcow2-backed AFAIU.
I guess I need to extend blkdebug first before this can be
reliably tested by qtest.
It can't, since it's not a pure device emulation issue but depends on
the relative timing of filesystem operations and subsequent commands.
That's why you need to take influence on the timing. It's no excuse for
merging without a test case. If we only ever tested devices that have no
relation to the outside world, our testing would be pretty useless and
always stay as bad as it is today in many areas.
Kevin
[Qemu-devel] [PATCH] qemu-iotests: fix 054 cluster size help output
Commit f3f4d2c09b9cf46903ba38425ec46c44185162bd added a hint to increase the cluster size when a large image cannot be created. Test 054 now has outdated output and fails because the golden output does not match. This patch updates the 054 golden output. Signed-off-by: Stefan Hajnoczi stefa...@redhat.com --- tests/qemu-iotests/054.out | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/qemu-iotests/054.out b/tests/qemu-iotests/054.out index 0b2fe30..2f357c2 100644 --- a/tests/qemu-iotests/054.out +++ b/tests/qemu-iotests/054.out @@ -1,7 +1,7 @@ QA output created by 054 creating too large image (1 EB) -qemu-img: The image size is too large for file format 'qcow2' +qemu-img: The image size is too large for file format 'qcow2' (try using a larger cluster size) Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1152921504606846976 creating too large image (1 EB) using qcow2.py -- 1.8.1.4
Re: [Qemu-devel] [PATCH v3] qemu: fix out of tree cross compile
Il 28/05/2013 11:12, Andreas Färber ha scritto: Am 28.05.2013 10:54, schrieb Paolo Bonzini: Il 28/05/2013 01:49, Alexey Kardashevskiy ha scritto: The symlink to asm platform linux headers is made in the build tree by the configure script but gcc is not told to look for them there. The patch fixes this. Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru --- The previous patch did not remove the old line adding includes. Early morning, lack of focus :) --- configure |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 5ae7e4a..eca2a20 100755 --- a/configure +++ b/configure @@ -547,7 +547,7 @@ Haiku) if [ $cpu = i386 -o $cpu = x86_64 ] ; then audio_possible_drivers=$audio_possible_drivers fmod fi - QEMU_INCLUDES=-I\$(SRC_PATH)/linux-headers $QEMU_INCLUDES + QEMU_INCLUDES=-I\$(SRC_PATH)/linux-headers -I$(pwd)/linux-headers $QEMU_INCLUDES ;; esac Reviewed-by: Paolo Bonzini pbonz...@redhat.com Hm, I see no other case of adding $(pwd) to QEMU_INCLUDES - shouldn't this just be -Ilinux-headers? I think -Ilinux-headers would add builddir/x86_64-softmmu/linux-headers, which is wrong. And might it make sense to give the build directory precedence over the source directory? It shouldn't matter. Paolo
Re: [Qemu-devel] [PATCH] ide: Set BSY bit during FLUSH
Il 28/05/2013 11:18, Kevin Wolf ha scritto: The other part why I haven't sent a fix yet is that I don't have a test case for it. Temporarily add a sleep(31) in qemu_fdatasync()? I was lazy in testing with -snapshot to not corrupt my disk image, which would not trigger the same issue since qcow2-backed AFAIU. I guess I need to extend blkdebug first before this can be reliably tested by qtest. It can't, since it's not a pure device emulation issue but depends on the relative timing of filesystem operations and subsequent commands. That's why you need to take influence on the timing. It's no excuse for merging without a test case. If we only ever tested devices that have no relation to the outside world, our testing would be pretty useless and always stay as bad as it is today in many areas. I don't think the qtest would be timing dependent. The Linux testcase is timing dependent, but for the qtest all you need to check is is BUSY set during a flush?. This can be done with blkdebug suspend/resume, except that there is no way to call bdrv_debug_resume from QEMU. Paolo
Re: [Qemu-devel] [PATCH qom-cpu 0/3] Conroe/Penryn/Nehalem CPUID family/level fixes
On Mon, 27 May 2013 17:23:52 -0300 Eduardo Habkost ehabk...@redhat.com wrote: This series changes the CPUID family and level fields of the Conroe, Penryn, and Nehalem CPU models. Testing: those model/level values have been in use on Red Hat Enterprise Linux since version 6.0 (released in 2010). The fix wasn't submitted to QEMU earlier because we didn't have a good mechanism and clear procedure to update CPUID values of existing CPU models in QEMU. Eduardo Habkost (3): pc: create pc-*-1.6 machine-types target-i386: update model values on Conroe/Penryn/Nehalem CPU models target-i386: set level=4 on Conroe/Penryn/Nehalem hw/i386/pc_piix.c| 18 -- hw/i386/pc_q35.c | 16 +++- include/hw/i386/pc.h | 28 target-i386/cpu.c| 12 ++-- 4 files changed, 65 insertions(+), 9 deletions(-) Reviewed-By: Igor Mammedov imamm...@redhat.com
Re: [Qemu-devel] [PATCH] boot: fix path pattern of scsi device
On Tue, May 28, 2013 at 10:06:51AM +0200, Paolo Bonzini wrote:
Il 28/05/2013 09:40, Amos Kong ha scritto:
bootindex parameter of scsi device doesn't work, it causes
by wrong pattern in seabios.
qemu passes the following firmware dev_path to seabios:
/pci@i0cf8/scsi@4/virtio-scsi-device/channel@0/disk@0,0
No, this is another unexpected change due to the virtio refactoring in
QEMU. The right fix is in QEMU, by adding a get_fw_dev_path
implementation in hw/virtio/virtio-bus.c.
Hi Paolo,
We could not fix this by implementing get_fw_dev_path in
hw/virtio/virtio-bus.c
virtio-bus is the parent bus of scsi-bus, scsibus_get_fw_dev_path()
will be called after called virtio_bus_get_fw_dev_path().
str0 = returns of parents of virtio-bus /* eg: /pci@i0cf8/scsi@4 */
str1 = return of virtio_bus_get_fw_dev_path() /* eg: .. */
str2 = scsibus_get_fw_dev_path() /* eg: channel@0/disk@0,0 */
The final fw_dev_path should be $str0/$str1/$str2
| static int qdev_get_fw_dev_path_helper(DeviceState *dev, char *p, int size)
| {
| int l = 0;
|
| if (dev dev-parent_bus) {
| char *d;
| l = qdev_get_fw_dev_path_helper(dev-parent_bus-parent, p, size);
| d = bus_get_fw_dev_path(dev-parent_bus, dev);
| if (d) {
| l += snprintf(p + l, size - l, %s, d);
| g_free(d);
if we implement virtio_bus_get_fw_dev_path(), the return value will be set to
$str1
| } else {
| l += snprintf(p + l, size - l, %s,
object_get_typename(OBJECT(dev)));
Currently we didn't implement virtio_bus_get_fw_dev_path(), so
'virtio-scsi-device' was set to $str1
| }
|
However, we need to change the pattern.
Amos.
We fixed it already for migration paths, it should be easy to do the
same for this.
Please Cc qemu-sta...@nongnu.org when sending the QEMU patch.
Thanks,
Paolo
Signed-off-by: Amos Kong ak...@redhat.com
---
src/boot.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/boot.c b/src/boot.c
index c308602..cd9d784 100644
--- a/src/boot.c
+++ b/src/boot.c
@@ -138,10 +138,11 @@ int bootprio_find_scsi_device(struct pci_device *pci,
int target, int lun)
if (!pci)
// support only pci machine for now
return -1;
-// Find scsi drive - for example: /pci@i0cf8/scsi@5/channel@0/disk@1,0
+/* Find scsi drive - for example:
+ /pci@i0cf8/scsi@5/virtio-scsi-device/channel@0/disk@1,0 */
char desc[256], *p;
p = build_pci_path(desc, sizeof(desc), *, pci);
-snprintf(p, desc+sizeof(desc)-p, /*@0/*@%d,%d, target, lun);
+snprintf(p, desc+sizeof(desc)-p, /*/*@0/*@%d,%d, target, lun);
return find_prio(desc);
}
Re: [Qemu-devel] [PATCH] ide: Set BSY bit during FLUSH
Am 28.05.2013 um 11:24 hat Paolo Bonzini geschrieben: Il 28/05/2013 11:18, Kevin Wolf ha scritto: The other part why I haven't sent a fix yet is that I don't have a test case for it. Temporarily add a sleep(31) in qemu_fdatasync()? I was lazy in testing with -snapshot to not corrupt my disk image, which would not trigger the same issue since qcow2-backed AFAIU. I guess I need to extend blkdebug first before this can be reliably tested by qtest. It can't, since it's not a pure device emulation issue but depends on the relative timing of filesystem operations and subsequent commands. That's why you need to take influence on the timing. It's no excuse for merging without a test case. If we only ever tested devices that have no relation to the outside world, our testing would be pretty useless and always stay as bad as it is today in many areas. I don't think the qtest would be timing dependent. The Linux testcase is timing dependent, but for the qtest all you need to check is is BUSY set during a flush?. This can be done with blkdebug suspend/resume, except that there is no way to call bdrv_debug_resume from QEMU. That's exactly what I was talking about, suspending a request is taking influence on its timing. I'm looking into this right now. (And it's not just resume, bdrv_debug_suspend can't be called from QEMU either) In fact, I'm checking whether we can have a monitor command to issue qemu-io commands, which will be more generally useful for test cases. We just need to make obvious that it doesn't become an ABI. Maybe prefix it with __org.qemu.debug- or something like that. Kevin
Re: [Qemu-devel] [PATCH] qemu-iotests: fix 054 cluster size help output
On Tue, 05/28 11:19, Stefan Hajnoczi wrote: Commit f3f4d2c09b9cf46903ba38425ec46c44185162bd added a hint to increase the cluster size when a large image cannot be created. Test 054 now has outdated output and fails because the golden output does not match. This patch updates the 054 golden output. Signed-off-by: Stefan Hajnoczi stefa...@redhat.com --- tests/qemu-iotests/054.out | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/qemu-iotests/054.out b/tests/qemu-iotests/054.out index 0b2fe30..2f357c2 100644 --- a/tests/qemu-iotests/054.out +++ b/tests/qemu-iotests/054.out @@ -1,7 +1,7 @@ QA output created by 054 creating too large image (1 EB) -qemu-img: The image size is too large for file format 'qcow2' +qemu-img: The image size is too large for file format 'qcow2' (try using a larger cluster size) Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1152921504606846976 creating too large image (1 EB) using qcow2.py -- 1.8.1.4 Reviewed-by: Fam Zheng f...@redhat.com
Re: [Qemu-devel] [PATCH] qemu-iotests: fix 054 cluster size help output
Am 28.05.2013 um 11:19 hat Stefan Hajnoczi geschrieben: Commit f3f4d2c09b9cf46903ba38425ec46c44185162bd added a hint to increase the cluster size when a large image cannot be created. Test 054 now has outdated output and fails because the golden output does not match. This patch updates the 054 golden output. Signed-off-by: Stefan Hajnoczi stefa...@redhat.com Thanks, applied to the block branch. Kevin
Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
On Tue, 28 May 2013 16:34:42 +0800 li guang lig.f...@cn.fujitsu.com wrote: 在 2013-05-28二的 10:16 +0200，Igor Mammedov写道： On Tue, 28 May 2013 08:28:09 +0800 li guang lig.f...@cn.fujitsu.com wrote: 在 2013-05-27一的 13:45 +0200，Igor Mammedov写道： On Mon, 27 May 2013 09:22:59 +0800 li guang lig.f...@cn.fujitsu.com wrote: 在 2013-05-26日的 19:51 -0500，Anthony Liguori写道： li guang lig.f...@cn.fujitsu.com writes: 在 2013-05-24五的 14:45 +0300，Michael S. Tsirkin写道： On Wed, May 22, 2013 at 11:46:33AM +0800, liguang wrote: These patches try to add ACPI Embedded Controller (EC), refer-to: ACPI SPEC v5 chapter 5 ACPI Embedded Controller Interface Specification EC is a standard ACPI device, it plays flexible roles, e.g. power controller, it can control power sequence for platform to enter or leave system state(0,1,3,4,5), it can controller CPU fan by the temperature of sensor. event carrier, it can pass events between platform and OS, so OS can execute _Qxx method which defined by yourself. So, I want to deliver CPU online/offline event between OS and QEMU for CPU hotplug feature, then we will don't need to echo 1 /sys/devices/system/cpu/cpu1/online again after 'cpu-add'. patches for online/offline event handler of QEUM and linux kernel are writing, and will send once finished. since EC is a common device, so I send pathes separately. Do any non-linux guests support this device? In fact, any OSes support ACPI will support this device. so, windows will. When you say any OSes supporting ACPI I think what you really mean is that we can provide bytecode that interacts with the embedded controller. There is not explicit driver in Linux or Windows AFAIK. Hmm, yep, mostly there's no special driver for EC, because it is directly embedded in code for ACPI for linux kernel, it's drivers/acpi/ec.c I still don't get the point of this. We can make ACPI hotplug work without introducing a new device like this. when you 'cpu-add' a cpu, acpi driver for cpu will not trigger 'cpu_up' for linux kernel AFAIK, unless you add a user space program to listen it's uevent and tigger 'cpu_up'. it is up to guest OS policy to decide if CPU should be onlined or not, Yep, but I think it's a favor to do cpu online. Then you have to teach kernel driver (EC) to do cpu_up on _Q02 event, I think it's not necessary to do this. we can also add another platform driver to listen cpu plug/unplug event and query EC's ACPI space to decide what to do next. the question is why would you do this when there is ACPI processor driver already that handles CPU hotplug in kernel. You can try add cpu_up() there and perhaps with good enough reasoning it would be accepted. it's not so convenient to trigger cpu_up/down process for ACPI processor driver as far as I can see, it seems like informal or hack there. so I'd like to make a bridge between them. but, anyway, it's a good point to think about or even try to do. at least I've seen this rationale on LKML when topic was discussed and automatic cpu_up on hotplug was rejected. Oh, and the reason is? Reason was to let guest decide whether online new CPU or nor instead of doing it unconditionally. can this be a Kconfig option? or it's strongly recommended to let guest decide? Probably there is no harm in trying to post patch to LKML and get feedback.
Re: [Qemu-devel] [PATCH qom-cpu 4/4] memory_mapping: Move stubs to libqemustub.a
Am 23.05.2013 12:08, schrieb Paolo Bonzini: Il 22/05/2013 15:09, Andreas Färber ha scritto: Allows us to drop CONFIG_NO_GET_MEMORY_MAPPING with its indirect dependency on CONFIG_HAVE_GET_MEMORY_MAPPING in Makefile.target. Signed-off-by: Andreas Färber afaer...@suse.de --- Makefile.target | 2 -- stubs/Makefile.objs | 1 + memory_mapping-stub.c = stubs/memory_mapping.c | 5 +++-- 3 files changed, 4 insertions(+), 4 deletions(-) rename memory_mapping-stub.c = stubs/memory_mapping.c (85%) [...] diff --git a/memory_mapping-stub.c b/stubs/memory_mapping.c similarity index 85% rename from memory_mapping-stub.c rename to stubs/memory_mapping.c index c48ea44..4db2108 100644 --- a/memory_mapping-stub.c +++ b/stubs/memory_mapping.c @@ -11,8 +11,9 @@ * */ -#include cpu.h -#include exec/cpu-all.h +#include qemu-common.h +#include exec/cpu-common.h +#include qom/cpu.h #include sysemu/memory_mapping.h int qemu_get_guest_memory_mapping(MemoryMappingList *list) Patches 1-3 are fine. Thanks. But I wonder if a better replacement for stubs is methods in CPU. None of the functions I have moved from *-stub.c to stubs/ operate on a single CPU, so now that the conflict with the kdump format support has been resolved I'd like to move them as a step towards dropping per-target configure changes for guest-memory-dump support. With my note in the cover letter I was rather referring to cpu_paging_enabled(), which is mandatory currently without any stub. Do you have a concrete suggestion what else to do for these stubs? Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH 1/4] configure: Require libfdt for arm, ppc, microblaze softmmu targets
On 28 May 2013 10:03, Andreas Färber afaer...@suse.de wrote: Am 24.05.2013 17:26, schrieb Peter Maydell: +# fdt support is mandatory for at least some target architectures, +# so insist on it if we're building those system emulators. +fdt_required=no +for target in $target_list; do + case $target in +arm*softmmu|ppc*softmmu|microblaze*softmmu) Assuming you'll apply this through your tree, it would be more self-explanatory to use foo*-softmmu despite no practical difference. Agreed. I'm guessing arm* is in preparation for a future armeb-softmmu? Yes, also for consistency with ppc. -- PMM
Re: [Qemu-devel] should qemu-palcode git submodule be hosted on git.qemu.org?
On 23 April 2013 19:35, Anthony Liguori aligu...@us.ibm.com wrote: Peter Maydell peter.mayd...@linaro.org writes: I thought that our git submodules were all supposed to be hosted on git.qemu.org, or does that only apply to the ones which have sources we use to generate binary blobs we ship in our tarballs? Why is it even a submodule? If it's only used by QEMU, why not just make it part of the tree? I don't know the answer to this, but can we at least put it on qemu.org somewhere -- repo.or.cz is being flaky again... thanks -- PMM
Re: [Qemu-devel] [PATCH] boot: fix path pattern of scsi device
Il 28/05/2013 11:35, Amos Kong ha scritto:
On Tue, May 28, 2013 at 10:06:51AM +0200, Paolo Bonzini wrote:
Il 28/05/2013 09:40, Amos Kong ha scritto:
bootindex parameter of scsi device doesn't work, it causes
by wrong pattern in seabios.
qemu passes the following firmware dev_path to seabios:
/pci@i0cf8/scsi@4/virtio-scsi-device/channel@0/disk@0,0
No, this is another unexpected change due to the virtio refactoring in
QEMU. The right fix is in QEMU, by adding a get_fw_dev_path
implementation in hw/virtio/virtio-bus.c.
Hi Paolo,
We could not fix this by implementing get_fw_dev_path in
hw/virtio/virtio-bus.c
virtio-bus is the parent bus of scsi-bus, scsibus_get_fw_dev_path()
will be called after called virtio_bus_get_fw_dev_path().
str0 = returns of parents of virtio-bus /* eg: /pci@i0cf8/scsi@4 */
str1 = return of virtio_bus_get_fw_dev_path() /* eg: .. */
str2 = scsibus_get_fw_dev_path() /* eg: channel@0/disk@0,0 */
The final fw_dev_path should be $str0/$str1/$str2
| static int qdev_get_fw_dev_path_helper(DeviceState *dev, char *p, int size)
| {
| int l = 0;
|
| if (dev dev-parent_bus) {
| char *d;
| l = qdev_get_fw_dev_path_helper(dev-parent_bus-parent, p, size);
| d = bus_get_fw_dev_path(dev-parent_bus, dev);
| if (d) {
| l += snprintf(p + l, size - l, %s, d);
| g_free(d);
if we implement virtio_bus_get_fw_dev_path(), the return value will be set to
$str1
| } else {
| l += snprintf(p + l, size - l, %s,
object_get_typename(OBJECT(dev)));
Currently we didn't implement virtio_bus_get_fw_dev_path(), so
'virtio-scsi-device' was set to $str1
| }
|
However, we need to change the pattern.
Turn this:
l += snprintf(p + l, size - l, %s,
object_get_typename(OBJECT(dev)));
into the default implementation of get_fw_dev_path (in TYPE_BUS),
and change qdev_get_fw_dev_path_helper to
if (d) {
l += snprintf(p + l, size - l, %s, d);
g_free(d);
} else {
return l;
}
Then virtio_bus_get_fw_dev_path can just return NULL.
Paolo
Amos.
We fixed it already for migration paths, it should be easy to do the
same for this.
Please Cc qemu-sta...@nongnu.org when sending the QEMU patch.
Thanks,
Paolo
Signed-off-by: Amos Kong ak...@redhat.com
---
src/boot.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/boot.c b/src/boot.c
index c308602..cd9d784 100644
--- a/src/boot.c
+++ b/src/boot.c
@@ -138,10 +138,11 @@ int bootprio_find_scsi_device(struct pci_device *pci,
int target, int lun)
if (!pci)
// support only pci machine for now
return -1;
-// Find scsi drive - for example: /pci@i0cf8/scsi@5/channel@0/disk@1,0
+/* Find scsi drive - for example:
+ /pci@i0cf8/scsi@5/virtio-scsi-device/channel@0/disk@1,0 */
char desc[256], *p;
p = build_pci_path(desc, sizeof(desc), *, pci);
-snprintf(p, desc+sizeof(desc)-p, /*@0/*@%d,%d, target, lun);
+snprintf(p, desc+sizeof(desc)-p, /*/*@0/*@%d,%d, target, lun);
return find_prio(desc);
}
Re: [Qemu-devel] [PATCH] ide: Set BSY bit during FLUSH
Il 28/05/2013 11:36, Kevin Wolf ha scritto: Am 28.05.2013 um 11:24 hat Paolo Bonzini geschrieben: Il 28/05/2013 11:18, Kevin Wolf ha scritto: The other part why I haven't sent a fix yet is that I don't have a test case for it. Temporarily add a sleep(31) in qemu_fdatasync()? I was lazy in testing with -snapshot to not corrupt my disk image, which would not trigger the same issue since qcow2-backed AFAIU. I guess I need to extend blkdebug first before this can be reliably tested by qtest. It can't, since it's not a pure device emulation issue but depends on the relative timing of filesystem operations and subsequent commands. That's why you need to take influence on the timing. It's no excuse for merging without a test case. If we only ever tested devices that have no relation to the outside world, our testing would be pretty useless and always stay as bad as it is today in many areas. I don't think the qtest would be timing dependent. The Linux testcase is timing dependent, but for the qtest all you need to check is is BUSY set during a flush?. This can be done with blkdebug suspend/resume, except that there is no way to call bdrv_debug_resume from QEMU. That's exactly what I was talking about, suspending a request is taking influence on its timing. I'm looking into this right now. (And it's not just resume, bdrv_debug_suspend can't be called from QEMU either) It can be called from the rules file though, can't it? In fact, I'm checking whether we can have a monitor command to issue qemu-io commands, which will be more generally useful for test cases. We just need to make obvious that it doesn't become an ABI. Maybe prefix it with __org.qemu.debug- or something like that. Makes sense. I'm not sure why you'd want to read or write from testcases, but bdrv_drain(_all) can also be useful from testcases. Paolo
Re: [Qemu-devel] [PATCH qom-cpu 4/4] memory_mapping: Move stubs to libqemustub.a
Il 28/05/2013 11:39, Andreas Färber ha scritto: Am 23.05.2013 12:08, schrieb Paolo Bonzini: Il 22/05/2013 15:09, Andreas Färber ha scritto: Allows us to drop CONFIG_NO_GET_MEMORY_MAPPING with its indirect dependency on CONFIG_HAVE_GET_MEMORY_MAPPING in Makefile.target. Signed-off-by: Andreas Färber afaer...@suse.de --- Makefile.target | 2 -- stubs/Makefile.objs | 1 + memory_mapping-stub.c = stubs/memory_mapping.c | 5 +++-- 3 files changed, 4 insertions(+), 4 deletions(-) rename memory_mapping-stub.c = stubs/memory_mapping.c (85%) [...] diff --git a/memory_mapping-stub.c b/stubs/memory_mapping.c similarity index 85% rename from memory_mapping-stub.c rename to stubs/memory_mapping.c index c48ea44..4db2108 100644 --- a/memory_mapping-stub.c +++ b/stubs/memory_mapping.c @@ -11,8 +11,9 @@ * */ -#include cpu.h -#include exec/cpu-all.h +#include qemu-common.h +#include exec/cpu-common.h +#include qom/cpu.h #include sysemu/memory_mapping.h int qemu_get_guest_memory_mapping(MemoryMappingList *list) Patches 1-3 are fine. Thanks. But I wonder if a better replacement for stubs is methods in CPU. None of the functions I have moved from *-stub.c to stubs/ operate on a single CPU, cpu_get_memory_mapping and cpu_paging_enabled can be made methods in CPU, can't they? And as far as this patch is concerned, this only leaves out qemu_get_guest_memory_mapping. If you make cpu_paging_enabled and cpu_get_memory_mapping return a different value for not supported (e.g. -ENOSYS), qemu_get_guest_memory_mapping need not be a stub at all. Paolo so now that the conflict with the kdump format support has been resolved I'd like to move them as a step towards dropping per-target configure changes for guest-memory-dump support. With my note in the cover letter I was rather referring to cpu_paging_enabled(), which is mandatory currently without any stub. Do you have a concrete suggestion what else to do for these stubs? Andreas
Re: [Qemu-devel] [PATCH 2/2] chardev: fix info chardev output
On 05/28/13 08:34, Gerd Hoffmann wrote:
Fill unset CharDriverState-filename with the backend name, so
'info chardev' will return at least the chardev type. Don't
touch it in case the chardev init function filled it already,
like the socket+pty chardevs do for example.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
qemu-char.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/qemu-char.c b/qemu-char.c
index f825294..d04b429 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -3801,6 +3801,9 @@ ChardevReturn *qmp_chardev_add(const char *id,
ChardevBackend *backend,
chr-label = g_strdup(id);
chr-avail_connections =
(backend-kind == CHARDEV_BACKEND_KIND_MUX) ? MAX_MUX : 1;
+if (!chr-filename) {
+chr-filename =
g_strdup(ChardevBackendKind_lookup[backend-kind]);
+}
QTAILQ_INSERT_TAIL(chardevs, chr, next);
return ret;
} else {
this one is a stable candidate, cc'ing qemu-stable
cheers,
Gerd
Re: [Qemu-devel] [PATCH] ide: Set BSY bit during FLUSH
Am 28.05.2013 um 11:48 hat Paolo Bonzini geschrieben: Il 28/05/2013 11:36, Kevin Wolf ha scritto: Am 28.05.2013 um 11:24 hat Paolo Bonzini geschrieben: Il 28/05/2013 11:18, Kevin Wolf ha scritto: The other part why I haven't sent a fix yet is that I don't have a test case for it. Temporarily add a sleep(31) in qemu_fdatasync()? I was lazy in testing with -snapshot to not corrupt my disk image, which would not trigger the same issue since qcow2-backed AFAIU. I guess I need to extend blkdebug first before this can be reliably tested by qtest. It can't, since it's not a pure device emulation issue but depends on the relative timing of filesystem operations and subsequent commands. That's why you need to take influence on the timing. It's no excuse for merging without a test case. If we only ever tested devices that have no relation to the outside world, our testing would be pretty useless and always stay as bad as it is today in many areas. I don't think the qtest would be timing dependent. The Linux testcase is timing dependent, but for the qtest all you need to check is is BUSY set during a flush?. This can be done with blkdebug suspend/resume, except that there is no way to call bdrv_debug_resume from QEMU. That's exactly what I was talking about, suspending a request is taking influence on its timing. I'm looking into this right now. (And it's not just resume, bdrv_debug_suspend can't be called from QEMU either) It can be called from the rules file though, can't it? No, you can only define ACTION_INJECT_ERROR and ACTION_SET_STATE from the config file, but not ACTION_SUSPEND. Maybe we should add it, but it would still require a manual resume. So far all test cases suspend requests with explicit qemu-io commands. In fact, I'm checking whether we can have a monitor command to issue qemu-io commands, which will be more generally useful for test cases. We just need to make obvious that it doesn't become an ABI. Maybe prefix it with __org.qemu.debug- or something like that. Makes sense. I'm not sure why you'd want to read or write from testcases, but bdrv_drain(_all) can also be useful from testcases. I imagine writing could be very useful for block job test cases. Kevin
Re: [Qemu-devel] snabbswitch integration with QEMU for userspace ethernet I/O
On 27 May 2013 11:34, Stefan Hajnoczi stefa...@redhat.com wrote: vhost_net is about connecting the a virtio-net speaking process to a tun-like device. The problem you are trying to solve is connecting a virtio-net speaking process to Snabb Switch. Yep! Either you need to replace vhost or you need a tun-like device interface. Replacing vhost would mean that your switch implements virtio-net, shares guest RAM with the guest, and shares the ioeventfd and irqfd which are used to signal with the guest. This would be a great solution from my perspective. This is the design that I am now struggling to find a good implementation strategy for. At that point your switch is similar to the virtio-net data plane work that Ping Fan Liu is working on but your switch is in a separate process rather than a thread. Thanks for the reference! I was not aware of this work and it sounds highly relevant. How does your switch talk to hardware? If you have userspace NIC drivers that bypass the Linux network stack then the approach I mentioned fits well. The switch talks to hardware using a built-in userspace (kernel bypass) device driver. The switch runs in a single userspace process with realtime priority and polls for traffic. The design is similar to what Intel are now promoting with their Data Plane Development Kit. The only system call in the main traffic loop is to sleep for a microsecond or so when idle. The Intel 10G NIC driver is written in Lua btw, in case anybody is curious to check out something so exotic here's the link: https://github.com/SnabbCo/snabbswitch/blob/master/src/intel10g.lua
[Qemu-devel] [PATCH RFC] virtio-pci: fix LE host/BE guest capacity for blk
When a BE guest reads capacity from an LE host virtio-blk device or vice
versa, it will get the dwords of the qword field swapped.
As virtio-blk is the only one with such a quirk,
and as non-pci transports don't do byte-swaps at all,
solve this with a bit of device-specific hackery in
virtio-pci.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
I don't seem to be able to boot any big-endian
guests ATM, so this is only compile-tested - sending
this out for early feedback/flames.
Testing reports also wellcome!
hw/virtio/virtio-pci.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 9668b2b..0e9ae4c 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -411,6 +411,15 @@ static uint64_t virtio_pci_config_read(void *opaque,
hwaddr addr,
}
break;
case 4:
+/* Most devices don't have 64 bit config fields.
+ * Block is an exception: first 8 bytes include
+ * a 64 bit capacity field.
+ */
+if (virtio_is_big_endian() != defined(HOST_WORDS_BIGENDIAN)
+proxy-vdev-dev_id == VIRTIO_ID_BLOCK addr 8) {
+/* Swap first two words */
+addr ^= 0x4;
+}
val = virtio_config_readl(proxy-vdev, addr);
if (virtio_is_big_endian()) {
val = bswap32(val);
--
MST
Re: [Qemu-devel] [PATCH RFC] virtio-pci: fix LE host/BE guest capacity for blk
Il 28/05/2013 12:11, Michael S. Tsirkin ha scritto:
When a BE guest reads capacity from an LE host virtio-blk device or vice
versa, it will get the dwords of the qword field swapped.
As virtio-blk is the only one with such a quirk,
and as non-pci transports don't do byte-swaps at all,
solve this with a bit of device-specific hackery in
virtio-pci.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
I don't seem to be able to boot any big-endian
guests ATM, so this is only compile-tested - sending
this out for early feedback/flames.
Testing reports also wellcome!
hw/virtio/virtio-pci.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 9668b2b..0e9ae4c 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -411,6 +411,15 @@ static uint64_t virtio_pci_config_read(void *opaque,
hwaddr addr,
}
break;
case 4:
+/* Most devices don't have 64 bit config fields.
+ * Block is an exception: first 8 bytes include
+ * a 64 bit capacity field.
+ */
+if (virtio_is_big_endian() != defined(HOST_WORDS_BIGENDIAN)
I thought think this is not valid C?
Paolo
+proxy-vdev-dev_id == VIRTIO_ID_BLOCK addr 8) {
+/* Swap first two words */
+addr ^= 0x4;
+}
val = virtio_config_readl(proxy-vdev, addr);
if (virtio_is_big_endian()) {
val = bswap32(val);
[Qemu-devel] [PATCH v2 RFC] virtio-pci: fix LE host/BE guest capacity for blk
When a BE guest reads capacity from an LE host virtio-blk device or vice
versa, it will get the dwords of the qword field swapped.
As virtio-blk is the only one with such a quirk,
and as non-pci transports don't do byte-swaps at all,
solve this with a bit of device-specific hackery in
virtio-pci.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
Changes from v1:
fixed some obvious bugs.
I don't seem to be able to boot any big-endian
guests ATM, so this is only compile-tested - sending
this out for early feedback/flames.
Testing reports also wellcome!
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 9668b2b..e7971cc 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -98,6 +98,12 @@
/* HACK for virtio to determine if it's running a big endian guest */
bool virtio_is_big_endian(void);
+#ifdef HOST_WORDS_BIGENDIAN
+#define VIRTIO_HOST_IS_BIG_ENDIAN true
+#else
+#define VIRTIO_HOST_IS_BIG_ENDIAN false
+#endif
+
static void virtio_pci_bus_new(VirtioBusState *bus, VirtIOPCIProxy *dev);
/* virtio device */
@@ -411,6 +417,15 @@ static uint64_t virtio_pci_config_read(void *opaque,
hwaddr addr,
}
break;
case 4:
+/* Most devices don't have 64 bit config fields.
+ * Block is an exception: first 8 bytes include
+ * a 64 bit capacity field.
+ */
+if (virtio_is_big_endian() != VIRTIO_HOST_IS_BIG_ENDIAN
+proxy-vdev-device_id == VIRTIO_ID_BLOCK addr 8) {
+/* Swap first two words */
+addr ^= 0x4;
+}
val = virtio_config_readl(proxy-vdev, addr);
if (virtio_is_big_endian()) {
val = bswap32(val);
[Qemu-devel] [PATCH] virtio-pci: drop unused wmb macro
The implementation is wrong for kvm, and it's unused anyway.
Drop it.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
hw/virtio/virtio-pci.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 87b78bc..f4db224 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -89,12 +89,6 @@
/* Flags track per-device state like workarounds for quirks in older guests. */
#define VIRTIO_PCI_FLAG_BUS_MASTER_BUG (1 0)
-/* QEMU doesn't strictly need write barriers since everything runs in
- * lock-step. We'll leave the calls to wmb() in though to make it obvious for
- * KVM or if kqemu gets SMP support.
- */
-#define wmb() do { } while (0)
-
/* HACK for virtio to determine if it's running a big endian guest */
bool virtio_is_big_endian(void);
--
MST
Re: [Qemu-devel] [PATCH] boot: fix path pattern of scsi device
On 05/28/13 10:06, Paolo Bonzini wrote: Il 28/05/2013 09:40, Amos Kong ha scritto: bootindex parameter of scsi device doesn't work, it causes by wrong pattern in seabios. qemu passes the following firmware dev_path to seabios: /pci@i0cf8/scsi@4/virtio-scsi-device/channel@0/disk@0,0 No, this is another unexpected change due to the virtio refactoring in QEMU. The right fix is in QEMU, by adding a get_fw_dev_path implementation in hw/virtio/virtio-bus.c. We fixed it already for migration paths, it should be easy to do the same for this. Please Cc qemu-sta...@nongnu.org when sending the QEMU patch. Thanks, Paolo Ahhh. I was super confused by this patch initially. Amos, when posting a patch to both lists, please add the project name to the bracketed bag-of-tags in the subject, like [SeaBIOS PATCH] boot: fix path pattern of scsi device I saw this message first on qemu-devel, and until I noticed src/boot.c I was kind of confused whom you want to adapt to whom, and in what direction Paolo argues against it. So, virtio refactoring in QEMU (care to name a commit or release?) changed the OpenFirmware device path exported for virtio-scsi devices under the boot order fw_cfg key. This patch intended to adapt SeaBIOS to recognize the new OFW devpath. Under this approach I would have to update QemuBootOrder.c in OVMF in parallel, so that it accepts both old and new style OFW devpaths for virtio-scsi. However Paolo says the new style OFW devpath should be fixed (eliminated) in qemu, and consumers shouldn't notice any change in the long term. And I won't have to change QemuBootOrder.c. Right? Thanks! Laszlo
[Qemu-devel] [PATCH] qdev: don't add typename to fw_dev_path when get_fw_dev_path isn't implemented
Currently we add typename to fw_dev_path if virtio-bus
doesn't have get_fw_dev_path implementation, the fw_dev_path
passed to seabios is not expected, the typename is redundant.
It causes that bootindex parameter of scsi device doesn't work.
This patch changes the qdev_get_fw_dev_path_helper() to add
nothing if device doesn't have get_fw_dev_path implementation.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Amos Kong ak...@redhat.com
---
hw/core/qdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 6985ad8..150255d 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -515,7 +515,7 @@ static int qdev_get_fw_dev_path_helper(DeviceState *dev,
char *p, int size)
l += snprintf(p + l, size - l, %s, d);
g_free(d);
} else {
-l += snprintf(p + l, size - l, %s,
object_get_typename(OBJECT(dev)));
+return l;
}
}
l += snprintf(p + l , size - l, /);
--
1.8.1.4
[Qemu-devel] [PATCH 1/2] Revert chardev: Get filename for new qapi backend
Does not handle chardevs created via chardev-add monitor command.
This reverts commit 2b220025993e76d4116781ca91a4fabc5ad9c722.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
qemu-char.c |2 --
1 file changed, 2 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index 4f8382e..f825294 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -3276,7 +3276,6 @@ CharDriverState *qemu_chr_new_from_opts(QemuOpts *opts,
ChardevReturn *ret = NULL;
const char *id = qemu_opts_id(opts);
const char *bid = NULL;
-char *filename = g_strdup(qemu_opt_get(opts, backend));
if (qemu_opt_get_bool(opts, mux, 0)) {
bid = g_strdup_printf(%s-base, id);
@@ -3309,7 +3308,6 @@ CharDriverState *qemu_chr_new_from_opts(QemuOpts *opts,
}
chr = qemu_chr_find(id);
-chr-filename = filename;
qapi_out:
qapi_free_ChardevBackend(backend);
--
1.7.9.7
[Qemu-devel] [PATCH 2/2] chardev: fix info chardev output
Fill unset CharDriverState-filename with the backend name, so
'info chardev' will return at least the chardev type. Don't
touch it in case the chardev init function filled it already,
like the socket+pty chardevs do for example.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
qemu-char.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/qemu-char.c b/qemu-char.c
index f825294..d04b429 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -3801,6 +3801,9 @@ ChardevReturn *qmp_chardev_add(const char *id,
ChardevBackend *backend,
chr-label = g_strdup(id);
chr-avail_connections =
(backend-kind == CHARDEV_BACKEND_KIND_MUX) ? MAX_MUX : 1;
+if (!chr-filename) {
+chr-filename = g_strdup(ChardevBackendKind_lookup[backend-kind]);
+}
QTAILQ_INSERT_TAIL(chardevs, chr, next);
return ret;
} else {
--
1.7.9.7
[Qemu-devel] [PULL 0/2] chardev: fix info chardev output
Hi, Tiny series, first reverting the broken patch from Lei Li, then fixing it for real. please pull, Gerd The following changes since commit 6a4e17711442849bf2cc731ccddef5a2a2d92d29: Remove Sun4c, Sun4d and a few CPUs (2013-05-26 11:37:58 +) are available in the git repository at: git://git.kraxel.org/qemu chardev.6 for you to fetch changes up to 60d95386abf1f5f37ded6a812d12ac458df2491b: chardev: fix info chardev output (2013-05-27 12:47:28 +0200) Gerd Hoffmann (2): Revert chardev: Get filename for new qapi backend chardev: fix info chardev output qemu-char.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
[Qemu-devel] [PULL 0/2] update seabios to release 1.7.2.2
Hi, This pull updates seabios to the 1.7.2.2 release tagged yesterday, bringing some fixes which unfortunaly missed the qemu 1.5 boat. please pull, Gerd The following changes since commit 6a4e17711442849bf2cc731ccddef5a2a2d92d29: Remove Sun4c, Sun4d and a few CPUs (2013-05-26 11:37:58 +) are available in the git repository at: git://git.kraxel.org/qemu seabios-1.7.2.2 for you to fetch changes up to 6683d7bc2759e9da8b5c4907a9de85d500933ffb: update seabios to release 1.7.2.2 (2013-05-28 12:19:02 +0200) Gerd Hoffmann (2): Revert roms: switch oldnoconfig to olddefconfig update seabios to release 1.7.2.2 pc-bios/bios.bin | Bin 131072 - 131072 bytes roms/configure-seabios.sh |2 +- roms/seabios |2 +- 3 files changed, 2 insertions(+), 2 deletions(-)
[Qemu-devel] [PATCH 2/2] update seabios to release 1.7.2.2
git shortlog from 1.7.2.1
Asias He (2):
virtio-scsi: Pack struct virtio_scsi_{req_cmd,resp_cmd}
virtio-scsi: Set _DRIVER_OK flag before scsi target scanning
Kevin O'Connor (1):
Cache boot-fail-wait to avoid romfile access after POST.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
pc-bios/bios.bin | Bin 131072 - 131072 bytes
roms/seabios |2 +-
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/pc-bios/bios.bin b/pc-bios/bios.bin
index
ec9eeb12c62a511f2e45bfc6fe3af90cc6da0d65..c2a19b8930540db854d3c98c6a271eadc2d12e98
100644
GIT binary patch
[ ... snipped to not spam the list ... ]
diff --git a/roms/seabios b/roms/seabios
index 88cb66e..d4f7d90 16
--- a/roms/seabios
+++ b/roms/seabios
@@ -1 +1 @@
-Subproject commit 88cb66ea5429068a80ef397b9e3adbb33116
+Subproject commit d4f7d90f47462b4e8836899adc5060fbde5253e9
--
1.7.9.7
[Qemu-devel] [PATCH 1/2] Revert roms: switch oldnoconfig to olddefconfig
This reverts commit a5519b42cfd6c00e9f8b31c5aad7682e7a9f1181. Breaks make bios in roms/ as the kconfig version in seabios doesn't support olddefconfig. Must have been be totally untested. Signed-off-by: Gerd Hoffmann kra...@redhat.com --- roms/configure-seabios.sh |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/roms/configure-seabios.sh b/roms/configure-seabios.sh index 4bb6c2b..98f59a2 100755 --- a/roms/configure-seabios.sh +++ b/roms/configure-seabios.sh @@ -2,4 +2,4 @@ config=$1 make -C seabios clean distclean cp $config seabios/.config -make -C seabios olddefconfig +make -C seabios oldnoconfig -- 1.7.9.7
Re: [Qemu-devel] [PATCH] qdev: don't add typename to fw_dev_path when get_fw_dev_path isn't implemented
Il 28/05/2013 12:25, Amos Kong ha scritto:
Currently we add typename to fw_dev_path if virtio-bus
doesn't have get_fw_dev_path implementation, the fw_dev_path
passed to seabios is not expected, the typename is redundant.
It causes that bootindex parameter of scsi device doesn't work.
This patch changes the qdev_get_fw_dev_path_helper() to add
nothing if device doesn't have get_fw_dev_path implementation.
This is not enough, because it would change behavior for other buses
that do not have get_fw_dev_path. You also need to add a default
implementation of the callback.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
You don't need my Signed-off-by. On the other hand, you should Cc
qemu-sta...@nongnu.org.
Paolo
Signed-off-by: Amos Kong ak...@redhat.com
---
hw/core/qdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 6985ad8..150255d 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -515,7 +515,7 @@ static int qdev_get_fw_dev_path_helper(DeviceState *dev,
char *p, int size)
l += snprintf(p + l, size - l, %s, d);
g_free(d);
} else {
-l += snprintf(p + l, size - l, %s,
object_get_typename(OBJECT(dev)));
+return l;
}
}
l += snprintf(p + l , size - l, /);
Re: [Qemu-devel] [PATCH] boot: fix path pattern of scsi device
On Tue, May 28, 2013 at 12:26:34PM +0200, Laszlo Ersek wrote: On 05/28/13 10:06, Paolo Bonzini wrote: Il 28/05/2013 09:40, Amos Kong ha scritto: bootindex parameter of scsi device doesn't work, it causes by wrong pattern in seabios. qemu passes the following firmware dev_path to seabios: /pci@i0cf8/scsi@4/virtio-scsi-device/channel@0/disk@0,0 No, this is another unexpected change due to the virtio refactoring in QEMU. The right fix is in QEMU, by adding a get_fw_dev_path implementation in hw/virtio/virtio-bus.c. We fixed it already for migration paths, it should be easy to do the same for this. Please Cc qemu-sta...@nongnu.org when sending the QEMU patch. Thanks, Paolo Ahhh. I was super confused by this patch initially. Amos, when posting a patch to both lists, please add the project name to the bracketed bag-of-tags in the subject, like [SeaBIOS PATCH] boot: fix path pattern of scsi device Sorry for the mistiness. I saw this message first on qemu-devel, and until I noticed src/boot.c I was kind of confused whom you want to adapt to whom, and in what direction Paolo argues against it. So, virtio refactoring in QEMU (care to name a commit or release?) changed the OpenFirmware device path exported for virtio-scsi devices under the boot order fw_cfg key. This patch intended to adapt SeaBIOS to recognize the new OFW devpath. Under this approach I would have to update QemuBootOrder.c in OVMF in parallel, so that it accepts both old and new style OFW devpaths for virtio-scsi. However Paolo says the new style OFW devpath should be fixed (eliminated) in qemu, and consumers shouldn't notice any change in the long term. And I won't have to change QemuBootOrder.c. Right? Just sent a qemu patch to fix this problem. We will keep original style devpath. Thanks! Laszlo -- Amos.
Re: [Qemu-devel] [SeaBIOS] [PULL 0/2] chardev: fix info chardev output
On 05/28/13 12:27, Gerd Hoffmann wrote: Hi, Tiny series, first reverting the broken patch from Lei Li, then fixing it for real. Oops, scratch that. Resent an old series due to 'git send-email 00*.patch' in the wrong directory. sorry, Gerd
Re: [Qemu-devel] [PATCH] makefile: detect corrupted elf files
On Sun, May 26, 2013 at 08:29:35PM +, Blue Swirl wrote:
On Sun, May 26, 2013 at 8:15 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, May 26, 2013 at 07:28:40PM +, Blue Swirl wrote:
On Sun, May 26, 2013 at 6:24 PM, Michael S. Tsirkin m...@redhat.com
wrote:
On Sun, May 26, 2013 at 06:20:17PM +, Blue Swirl wrote:
On Sun, May 26, 2013 at 1:40 PM, Michael S. Tsirkin m...@redhat.com
wrote:
On Sun, May 26, 2013 at 02:36:28PM +0100, Peter Maydell wrote:
On 26 May 2013 13:31, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, May 26, 2013 at 10:12:21AM +0100, Peter Maydell wrote:
I definitely think individual project makefiles are the wrong
place
to fix this. If create-as-temp-and-rename is useful functionality
it needs to go in the compiler so that everybody benefits.
This will not help users on existing systems.
Also it's not just compiler. We'd have to do it in linker,
asm, ... lots of work.
This is clearly less work than implementing it in the makefile
of every single open source project in the world (or even every
single open source project in Debian).
You seem to have removed the part that explained that
1. we run scripts in our makefiles so need to handle that anyway
2. we care about users on existing systems
A generic hook (default none, or maybe test -s) after object
production and before linkage should be enough but would scale to SHA
producing/verifying tools.
This means that we would need the fix in our makefiles even
if compiler and linker gain this feature.
Depends on the feature. If the object files have robust checksums
which are checked after output and before input, this should be
transparent to the build system.
You are wellcome to implement this in compiler/linker/etc if you
like
but we will still want to handle it in our makefile as well.
I specifically don't want it handled in our makefiles because
it's the wrong place to fix the problem and it will make
our build system more complicated.
+1
Also, what is the worst case scenario? The link fails and you have to
clean up and rebuild? An automated build system can't produce the
expected output if the build machine is unreliable?
It's a simple issue.
Each time I reboot during build, I have to make clean and rebuild.
This wastes my time so I looked for ways to save the time.
Compile under a stable kernel and test the bleeding edge kernel only
as KVM guest? Get a different box for testing or compiling? Run 'sync'
every time gcc finishes?
What's the question here?
The question is if any of the suggestions solves the problem?
Also how about something this: post boot, find -name '*.o' | xargs -iF
sh -c 'if test ! -s F; then rm F;fi'
On Linux, even easier:
find -name '*.o' -empty -exec rm '{}' ';'
Seems to be enough here. Thanks, I'll use this hack and
leave makefiles alone for now.
Don't you have bigger problems with file systems due to the crashes?
As it happens, no. Maybe because I'm using ext4.
Maybe I'm lucky.
On my system at least, it has no measureable cost,
likely also because size only looks at headers and metadata.
For example on OpenBSD, 'size' does not seem to come from binutils, so
there could be portability issues.
True, I'm not saying it's perfect.
If others are not interested, I can keep it out of tree.
I've had problems with disk close to full, so I'm semi-interested if
the solution does not slow down others and it's not too ugly.
I think the simplest way to do it is to change makefile to unlike, create
then rename. Then you are safe against abrupt killing or crashing make.
And with a journaled fs, if you also have e.g. linux ext4 and mount with
data=ordered, you are safe against power failures.
It shouldn't be hard to do and I don't expect this to have any
measureable speed impact. What do you think?
I'd prefer a more generic solution, like the hook. What you propose
wouldn't protect from the disk full scenario.
-- PMM
Re: [Qemu-devel] snabbswitch integration with QEMU for userspace ethernet I/O
On Tue, May 28, 2013 at 12:10 PM, Luke Gorrie luk...@gmail.com wrote: On 27 May 2013 11:34, Stefan Hajnoczi stefa...@redhat.com wrote: vhost_net is about connecting the a virtio-net speaking process to a tun-like device. The problem you are trying to solve is connecting a virtio-net speaking process to Snabb Switch. Yep! Either you need to replace vhost or you need a tun-like device interface. Replacing vhost would mean that your switch implements virtio-net, shares guest RAM with the guest, and shares the ioeventfd and irqfd which are used to signal with the guest. This would be a great solution from my perspective. This is the design that I am now struggling to find a good implementation strategy for. At that point your switch is similar to the virtio-net data plane work that Ping Fan Liu is working on but your switch is in a separate process rather than a thread. Thanks for the reference! I was not aware of this work and it sounds highly relevant. How does your switch talk to hardware? If you have userspace NIC drivers that bypass the Linux network stack then the approach I mentioned fits well. The switch talks to hardware using a built-in userspace (kernel bypass) device driver. BTW there is an effort to get low-latency networking integrated into Linux: http://thread.gmane.org/gmane.linux.kernel/1493276 Stefan
Re: [Qemu-devel] [PATCH v6 00/12] curl: fix curl read
After discussion off-list, I've gone back and retested versions 4, 5, and 6 of this patch. I'm using the test script previously attached. I'm using libguestfs (ada94eb9) curl (ba9a) qemu (6a4e177114) all the latest from git. I'm using a 6 GB Windows XP guest. The web server is remote, over quite slow wifi, and is running Apache 2.2.15 on RHEL 6. I ran each test 3 times. v4: Buffer I/O errors reported inside the appliance on each run. No segfault in qemu. v5: Buffer I/O errors reported inside the appliance on each run. No segfault in qemu. v6: Buffer I/O errors reported inside the appliance on each run. No segfault in qemu. no patch (curl driver in upstream qemu): No errors. Everything works. -- So I guess what has happened is NOT a regression from v5 - v6, but that something has changed in my environment which has stopped this patch from working. I'm continuing to investigate. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v
Re: [Qemu-devel] [PATCH RFC] virtio-pci: fix LE host/BE guest capacity for blk
On Tue, May 28, 2013 at 12:14:59PM +0200, Paolo Bonzini wrote:
Il 28/05/2013 12:11, Michael S. Tsirkin ha scritto:
When a BE guest reads capacity from an LE host virtio-blk device or vice
versa, it will get the dwords of the qword field swapped.
As virtio-blk is the only one with such a quirk,
and as non-pci transports don't do byte-swaps at all,
solve this with a bit of device-specific hackery in
virtio-pci.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
I don't seem to be able to boot any big-endian
guests ATM, so this is only compile-tested - sending
this out for early feedback/flames.
Testing reports also wellcome!
hw/virtio/virtio-pci.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 9668b2b..0e9ae4c 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -411,6 +411,15 @@ static uint64_t virtio_pci_config_read(void *opaque,
hwaddr addr,
}
break;
case 4:
+/* Most devices don't have 64 bit config fields.
+ * Block is an exception: first 8 bytes include
+ * a 64 bit capacity field.
+ */
+if (virtio_is_big_endian() != defined(HOST_WORDS_BIGENDIAN)
I thought think this is not valid C?
Paolo
Yes, v2 I just sent fixes this.
Thanks for paying attention.
+proxy-vdev-dev_id == VIRTIO_ID_BLOCK addr 8) {
+/* Swap first two words */
+addr ^= 0x4;
+}
val = virtio_config_readl(proxy-vdev, addr);
if (virtio_is_big_endian()) {
val = bswap32(val);
Re: [Qemu-devel] snabbswitch integration with QEMU for userspace ethernet I/O
Hi Anthony, On 27 May 2013 18:18, Anthony Liguori anth...@codemonkey.ws wrote: It would be very interesting to combine this with vmsplice/splice. Good point. This kernel-centric approach is a very promising one, though not the design we are exploring in the Snabb Switch project. Snabb Switch is instead very hardware-centric. That is: we see the world as CPU cores, DRAM banks, PCIe devices. We want to keep our inter-process communication as close to this model as possible, which is why Virtio is very appealing - it looks like a DMA-based interface between two pieces of hardware. In this sense the kernel is like a BIOS: something that got you up and running, and takes care of lots of ugly irrelevant details for you, but that you don't want to have the minimum possible interaction with. Some motivation explained in an old blog entry when deciding to take this route: http://blog.lukego.com/blog/2012/10/28/firmware-vs-software/
Re: [Qemu-devel] [PATCH 1/3] qemu_chr_new_from_opts: do not overwrite existing chr-filename
On Tue, 28 May 2013, Gerd Hoffmann wrote: On 05/27/13 20:13, Stefano Stabellini wrote: Set the new filename only if it hasn't been already set (for example by qemu_chr_open_pty). This fixes a regression that prevents Xen HVM domains from booting. It was introduced by: commit 2b220025993e76d4116781ca91a4fabc5ad9c722 Author: Lei Li li...@linux.vnet.ibm.com Date: Tue May 21 18:27:59 2013 +0800 FYI: just posted a pull req which reverts this one (you are cc'ed). Right, your two patches also solve the problem I was seeing. I'll drop the first patch of my series.
