Re: [Qemu-devel] [PATCH] MAINTAINERS: add block driver sub-maintainers
At Mon, 21 Oct 2013 14:26:15 +0100, Stefan Hajnoczi wrote: There are a number of contributors who maintain block drivers (image formats and protocols). They should be listed in the MAINTAINERS file so that get_maintainer.pl lists them. Note that commits are still merged through Kevin or Stefan's block tree but the block driver sub-maintainers are usually the ones to review patches. Acked-by: Kevin Wolf kw...@redhat.com Signed-off-by: Stefan Hajnoczi stefa...@redhat.com --- MAINTAINERS | 38 ++ 1 file changed, 38 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 77edacf..da18a23 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -857,3 +857,41 @@ Stable 0.10 L: qemu-sta...@nongnu.org T: git git://git.qemu-project.org/qemu-stable-0.10.git S: Orphan + +Block drivers +- +VMDK +M: Fam Zheng f...@redhat.com +S: Supported +F: block/vmdk.c + +RBD +M: Josh Durgin josh.dur...@dreamhost.com +S: Supported +F: block/rbd.c + +Sheepdog +M: MORITA Kazutaka morita.kazut...@lab.ntt.co.jp +S: Supported +F: block/sheepdog.c Acked-by: MORITA Kazutaka morita.kazut...@lab.ntt.co.jp
Re: [Qemu-devel] [PATCH] MAINTAINERS: add block driver sub-maintainers
Il 21/10/2013 14:26, Stefan Hajnoczi ha scritto: +iSCSI +M: Ronnie Sahlberg ronniesahlb...@gmail.com +M: Paolo Bonzini pbonz...@redhat.com +S: Supported +F: block/iscsi.c Acked-by: Paolo Bonzini pbonz...@redhat.com Paolo
Re: [Qemu-devel] [PATCH] rdma: rename 'x-rdma' = 'rdma'
Il 22/10/2013 21:20, Eric Blake ha scritto: -# @x-rdma-pin-all: Controls whether or not the entire VM memory footprint is +# @rdma-pin-all: Controls whether or not the entire VM memory footprint is # mlock()'d on demand or all at once. Refer to docs/rdma.txt for usage. # Disabled by default. Experimental: may (or may not) be renamed after # further testing is complete. (since 1.6) I'd also recommend tweaking this to say 'since 1.7', since the spelling 'rdma-pin-all' is new to this release. I would also leave this as experimental for now. Basically the point of the experimental designation was to ensure that RDMA protocol changes might not preserve backwards compatibility. The capability is a separate thing from the protocol, as it would likely apply to any migration-over-RDMA implementation Paolo
Re: [Qemu-devel] PSCI with mach-virt
Hi Peter,
I did compare with kvmtool and found that the below fix boots SMP in
mach-virt with qemu.
diff --git a/target-arm/kvm.c b/target-arm/kvm.c
index b92e00d..28b8e2b 100644
--- a/target-arm/kvm.c
+++ b/target-arm/kvm.c
@@ -82,6 +82,7 @@ int kvm_arch_init_vcpu(CPUState *cs)
init.target = KVM_ARM_TARGET_CORTEX_A15;
memset(init.features, 0, sizeof(init.features));
+init.features[0] = (!!(kvm_arch_vcpu_id(cs)) KVM_ARM_VCPU_POWER_OFF);
ret = kvm_vcpu_ioctl(cs, KVM_ARM_VCPU_INIT, init);
if (ret) {
return ret;
Thanks,
Giridhar
On 22 October 2013 10:00, Giridhar Maruthy giridhar.maru...@linaro.org wrote:
Thanks Peter, I will look into it.
Giridhar
On 21 October 2013 19:26, Peter Maydell peter.mayd...@linaro.org wrote:
On 21 October 2013 14:47, Giridhar Maruthy giridhar.maru...@linaro.org
wrote:
Hi,
I am using mach-virt in qemu on a kvm enabled host.
With 2 cpus, the guest fails to boot the second processor. Following
is the message.
CPU1: failed to boot: -22(-EINVAL)
The PSCI device nodes are anyway passed from virt.c file.
Is there anything extra that needs to be done to get 2 cpus working?
In theory it should work (it works for kvmtool and there is code
to support it in the qemu patches). However I haven't tested it
and it's quite possible it got accidentally broken in the course
of the various rebasings and rewritings the mach-virt patches
have gone through. Feel free to debug it :-)
thanks
-- PMM
Re: [Qemu-devel] [PATCH] MAINTAINERS: add block driver sub-maintainers
At Wed, 23 Oct 2013 15:19:47 +0900, MORITA Kazutaka wrote: + +Sheepdog +M: MORITA Kazutaka morita.kazut...@lab.ntt.co.jp +S: Supported +F: block/sheepdog.c Acked-by: MORITA Kazutaka morita.kazut...@lab.ntt.co.jp Is it okay to add Liu Yuan tailai...@taobao.com to the sheepdog maintainer too? He is a co-maintainer of the sheepdog project with me and very familiar with sheepdog internals. Thanks, Kazutaka
Re: [Qemu-devel] [PATCH_v2 9/9] target-openrisc: Correct carry flagcheck of l.addc and l.addic test casess
On Tue, Oct 22, 2013 at 8:15 PM, Sebastian Macke sebast...@macke.de wrote: On 22/10/2013 9:01 AM, Max Filippov wrote: On Tue, Oct 22, 2013 at 7:45 PM, Sebastian Macke sebast...@macke.de wrote: Hi Alex, I am using a cross-compiling toolchain. It's the easiest way as I have to compile the image for QEMU anyhow. http://opencores.org/or1k/OpenRISC_GNU_tool_chain Then it's just an make make test in the corresponding tests/tcg/openrisc folder. Inside the virtual machine it would be a little bit more complicated. You have to compile Linux with the initramfs containing the QEMU test sources. Another storage device is currently not supported by the OpenRISC QEMU emulator. It should be possible to use network, I did a quick check at the time of openrisc port submission, it used to work. This is true. Via a network file system it should be no problem. But this is a very complicated way to test the QEMU tcg part. The image containing gcc I am currently using you can download under www.simulationcorner.net/vmlinux Run it with qemu-system-or32 -m 128 -kernel vmlinux -nographic I can think of an easier way: try using linux user emulation instead of system emulation, it should make mostly little difference wrt TCG. It should be qemu-or32 linux-elf-file-to-run. -- Thanks. -- Max
Re: [Qemu-devel] [PATCH] MAINTAINERS: add block driver sub-maintainers
On Wed, Oct 23, 2013 at 03:51:37PM +0900, MORITA Kazutaka wrote: At Wed, 23 Oct 2013 15:19:47 +0900, MORITA Kazutaka wrote: + +Sheepdog +M: MORITA Kazutaka morita.kazut...@lab.ntt.co.jp +S: Supported +F: block/sheepdog.c Acked-by: MORITA Kazutaka morita.kazut...@lab.ntt.co.jp Is it okay to add Liu Yuan tailai...@taobao.com to the sheepdog maintainer too? He is a co-maintainer of the sheepdog project with me and very familiar with sheepdog internals. I'd like to appear to be 'Liu Yuan namei.u...@gmail.com' which is a long-term reachable mail address, if allowed to be on the list. Thanks Yuan
Re: [Qemu-devel] PSCI with mach-virt
On 23 October 2013 07:28, Giridhar Maruthy giridhar.maru...@linaro.org wrote:
I did compare with kvmtool and found that the below fix boots SMP in
mach-virt with qemu.
diff --git a/target-arm/kvm.c b/target-arm/kvm.c
index b92e00d..28b8e2b 100644
--- a/target-arm/kvm.c
+++ b/target-arm/kvm.c
@@ -82,6 +82,7 @@ int kvm_arch_init_vcpu(CPUState *cs)
init.target = KVM_ARM_TARGET_CORTEX_A15;
memset(init.features, 0, sizeof(init.features));
+init.features[0] = (!!(kvm_arch_vcpu_id(cs)) KVM_ARM_VCPU_POWER_OFF);
ret = kvm_vcpu_ioctl(cs, KVM_ARM_VCPU_INIT, init);
if (ret) {
return ret;
Thanks for looking into this. We probably need to tweak this
a bit because the feature bit is only valid if the kernel supports
the KVM_ARM_CAP_PSCI capability, and we only want to do
this if we're using mach-virt rather than vexpress-a15, but we
certainly need to do something to set the start powered down
feature for CPUs after zero if we're using PSCI.
-- PMM
Re: [Qemu-devel] [sheepdog] [PATCH 1/2] sheepdog: explicitly set copies as type uint8_t
At Wed, 16 Oct 2013 15:38:37 +0800,
Liu Yuan wrote:
'copies' is actually uint8_t since day one, but request headers and some
helper
functions parameterize it as uint32_t for unknown reasons and effectively
reserve 24 bytes for possible future use. This patch explicitly set the
correct
for copies and reserve the left bytes.
This is a preparation patch that allow passing copy_policy in request header.
Cc: Kevin Wolf kw...@redhat.com
Cc: Stefan Hajnoczi stefa...@redhat.com
Signed-off-by: Liu Yuan namei.u...@gmail.com
---
block/sheepdog.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/block/sheepdog.c b/block/sheepdog.c
index 5f81c93..ca4f98b 100644
--- a/block/sheepdog.c
+++ b/block/sheepdog.c
@@ -125,7 +125,8 @@ typedef struct SheepdogObjReq {
uint32_t data_length;
uint64_t oid;
uint64_t cow_oid;
-uint32_t copies;
+uint8_t copies;
+uint8_t reserved[3];
uint32_t rsvd;
uint64_t offset;
} SheepdogObjReq;
Having both 'reserved' and 'rsvd' looks confusing. I'd suggest
merging them into 'uint8_t reserved[7]'.
Thanks,
Kazutaka
Re: [Qemu-devel] [PATCH 04/16] slirp: Adding IPv6, ICMPv6 Echo and NDP autoconfiguration
Il 20/10/2013 15:56, Samuel Thibault ha scritto:
+#define rand_a_b(a, b)\
+(rand()%(int)(b-a)+a)
+#define NDP_Interval rand_a_b(NDP_MinRtrAdvInterval, NDP_MaxRtrAdvInterval)
+
+static void ra_timer_handler(void *opaque)
+{
+timer_mod(ra_timer, qemu_clock_get_s(QEMU_CLOCK_VIRTUAL) + NDP_Interval);
+ndp_send_ra((Slirp *)opaque);
+}
+
+void icmp6_init(Slirp *slirp)
+{
+srand(time(NULL));
+ra_timer = timer_new_s(QEMU_CLOCK_VIRTUAL, ra_timer_handler, slirp);
+timer_mod(ra_timer, qemu_clock_get_s(QEMU_CLOCK_VIRTUAL) + NDP_Interval);
+}
Should the granularity of the timer really be seconds? Or should you
use the existing milli/nanosecond interface and scale the interval, so
that you really get a uniformly distributed random value, even for very
small MaxRtrAdvInterval (e.g. for min=3, max=4 you won't get any other
value than 3 or 4, which is not really uniformly distributed).
Paolo
Re: [Qemu-devel] [PATCH for-1.7] configure: Explicitly set ARFLAGS so we can build with GNU Make 4.0
Il 22/10/2013 09:24, Peter Maydell ha scritto: Ken -- any chance you could test git master? I think it would be more interesting to make sure that 1.7 works with Make 4.0: I don't know if anybody will care enough to backport this patch to 1.6.x. Cc: qemu-sta...@nongnu.org Mike Roth now will. :) Paolo
Re: [Qemu-devel] [PATCH 6/6] qapi: add doc for QEvent
Take another think, I think I may use past tense through the doc,
but with more carefully meaning, such as:
the system has enter powerdown state.
If you agree with the tense, I'd like sent the reformed doc
in the following, before respin.
Indeed, which is why separating the docs from the refactoring made sense
in your series, so that we could hammer out good docs.
Hi, here is my draft for qapi-schema.json, please have a look.
Note:
1 it requires directly support of 'base', so I will sent additonal patch
support it by key word '_base' in 'data' contents.
2 some define not labeled with since 1.8', are code move.
3 reordered.
##
# @QEvent
#
# QEMU event types
#
# Since: 1.8
##
{ 'enum': 'QEvent',
'data': [
# system related
'SHUTDOWN',
'POWERDOWN',
'RESET',
'STOP',
'RESUME',
'SUSPEND',
'SUSPEND_DISK',
'WAKEUP',
# system virtual device related
'RTC_CHANGE',
'WATCHDOG',
'DEVICE_DELETED',
'DEVICE_TRAY_MOVED',
# block related
'BLOCK_IO_ERROR',
'BLOCK_IMAGE_CORRUPTED',
# block job related
'BLOCK_JOB_COMPLETED',
'BLOCK_JOB_CANCELLED',
'BLOCK_JOB_ERROR',
'BLOCK_JOB_READY',
# network related
'NIC_RX_FILTER_CHANGED',
# vnc display related
'VNC_CONNECTED',
'VNC_INITIALIZED',
'VNC_DISCONNECTED',
# spice display related
'SPICE_CONNECTED',
'SPICE_INITIALIZED',
'SPICE_DISCONNECTED',
'SPICE_MIGRATE_COMPLETED',
# guest related
'BALLOON_CHANGE',
'GUEST_PANICKED' ] }
##
# @EventTimestamp
#
# Reflect the time when event happens
#
# @seconds: the seconds have passed on host system
#
# @microsecnds: the microseconds have passed on host system
#
# Since: 1.8
##
{ 'type': 'EventTimestamp',
'data': { 'seconds': 'int', 'microsecnds': 'int' } }
##
# @EventBase
#
# Base type containing properties that are available for all kind of events
#
# @event: type of the event
#
# @timestamp: the time stamp of the event, which is got from host system
#
# Since: 1.8
##
{ 'type': 'EventBase',
'data': { 'event': 'QEvent', 'timestamp': 'EventTimestamp' } }
##
# @EventShutdown
#
# Emitted when the virtual machine shutdown, qemu terminates the
emulation and
# exit. If the command-line option -no-shutdown has been specified,
qemu will
# not exit, and a STOP event will eventually follow the SHUTDOWN event
#
# Since: 1.8
##
{ 'type': 'EventShutdown',
'data': { } }
##
# @EventPowerdown
#
# Emitted when the virtual machine is powered down, qemu tries to set the
# system power control system, such as ACPI related virtual chips
#
# Since: 1.8
##
{ 'type': 'EventPowerdown',
'data': { } }
##
# @EventReset
#
# Emitted when the virtual machine is reseted
#
# Since: 1.8
##
{ 'type': 'EventReset',
'data': { } }
##
# @EventStop
#
# Emitted when the virtual machine is stopped
#
# Since: 1.8
##
{ 'type': 'EventStop',
'data': { } }
##
# @EventResume
#
# Emitted when the virtual machine resumes execution
#
# Since: 1.8
##
{ 'type': 'EventResume',
'data': { } }
##
# @EventSuspend
#
# Emitted when guest enters S3 state
#
# Since: 1.8
##
{ 'type': 'EventSuspend',
'data': { } }
##
# @EventSuspendDisk
#
# Emitted when the guest makes a request to enter S4 state. Note QEMU shuts
# down (similar to @shutdown) when entering S4 state
#
# Since: 1.8
##
{ 'type': 'EventSuspendDisk',
'data': { } }
##
# @EventWakeup
#
# Emitted when the guest has woken up from S3 and is running
#
# Since: 1.8
##
{ 'type': 'EventWakeup',
'data': { } }
##
# @EventRtcChange
#
# Emitted when the guest changes the RTC time
#
# @offset: Offset between base RTC clock (as specified by -rtc base), and
# new RTC clock value
#
# Since: 1.8
##
{ 'type': 'EventRtcChange',
'data': {
'data': {
'offset': 'int'
} } }
##
# @ActionTypeOnWatchdogExpired
#
# An enumeration of the actions taken when the watchdog device's timer is
# expired
#
# @reset: system resets
#
# @shutdown: system shutdown, note that it is similar to @powerdown, which
#tries to set to system status and notify guest
#
# @poweroff: system poweroff, the emulator program exits
#
# @pause: system pauses, similar to @stop
#
# @pause: system enters debug state
#
# @none: nothing is done
#
# Since: 1.8
##
{ 'enum': 'ActionTypeOnWatchdogExpired',
'data': [ 'reset', 'shutdown', 'poweroff', 'pause', 'debug', 'none' ] }
##
# @EventWatchdog
#
# Emitted when the watchdog device's timer is expired
#
# @action: Action that has been taken
#
# Since: 1.8
##
{ 'type': 'Watchdog',
'data': {
'data': {
'action': 'ActionTypeOnWatchdogExpired'
} } }
##
# @EventDeviceDeleted
#
# Emitted whenever the device removal completion is acknowledged by the
guest.
# At this point, it's safe to reuse the specified
[Qemu-devel] qemu 1.6.1
Hi, My newly built qemu/win32 binary (v1.6.1) crashes in qemu-system-i386 and qemu-system-x86_64 when booting from an install CD. C:\Program Files\qemuqemu-system-x86_64 -boot d -vnc 0.0.0.0:20 -cdrom NetBSD-6.1.2-amd64.iso Assertion failed: qemu_in_coroutine(), file qemu-coroutine-lock.c, line 99 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. I noticed that qemu-system-sparc still booted OpenBSD/sparc 5.3 install CD correctly. No further info at this stage. Any ideas? - Michael
[Qemu-devel] [PATCH v2 0/2] sheepdog: make use of copy_policy
v2: - merge the reserved bits This patch set makes use of copy_policy in struct SheepdogInode in order to support recently introduced erasure coding volume in sheepdog. Thanks Yuan Liu Yuan (2): sheepdog: explicitly set copies as type uint8_t sheepdog: pass copy_policy in the request block/sheepdog.c | 30 +++--- 1 file changed, 19 insertions(+), 11 deletions(-) -- 1.7.9.5
[Qemu-devel] [PATCH v2 1/2] sheepdog: explicitly set copies as type uint8_t
'copies' is actually uint8_t since day one, but request headers and some helper
functions parameterize it as uint32_t for unknown reasons and effectively
reserve 24 bytes for possible future use. This patch explicitly set the correct
for copies and reserve the left bytes.
This is a preparation patch that allow passing copy_policy in request header.
Cc: Kevin Wolf kw...@redhat.com
Cc: Stefan Hajnoczi stefa...@redhat.com
Signed-off-by: Liu Yuan namei.u...@gmail.com
---
block/sheepdog.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/block/sheepdog.c b/block/sheepdog.c
index 5f81c93..b8a2985 100644
--- a/block/sheepdog.c
+++ b/block/sheepdog.c
@@ -125,8 +125,8 @@ typedef struct SheepdogObjReq {
uint32_t data_length;
uint64_t oid;
uint64_t cow_oid;
-uint32_t copies;
-uint32_t rsvd;
+uint8_t copies;
+uint8_t reserved[7];
uint64_t offset;
} SheepdogObjReq;
@@ -138,7 +138,8 @@ typedef struct SheepdogObjRsp {
uint32_t id;
uint32_t data_length;
uint32_t result;
-uint32_t copies;
+uint8_t copies;
+uint8_t reserved[3];
uint32_t pad[6];
} SheepdogObjRsp;
@@ -151,7 +152,8 @@ typedef struct SheepdogVdiReq {
uint32_t data_length;
uint64_t vdi_size;
uint32_t vdi_id;
-uint32_t copies;
+uint8_t copies;
+uint8_t reserved[3];
uint32_t snapid;
uint32_t pad[3];
} SheepdogVdiReq;
@@ -1081,7 +1083,7 @@ static int coroutine_fn add_aio_request(BDRVSheepdogState
*s, AIOReq *aio_req,
return 0;
}
-static int read_write_object(int fd, char *buf, uint64_t oid, int copies,
+static int read_write_object(int fd, char *buf, uint64_t oid, uint8_t copies,
unsigned int datalen, uint64_t offset,
bool write, bool create, uint32_t cache_flags)
{
@@ -1129,7 +1131,7 @@ static int read_write_object(int fd, char *buf, uint64_t
oid, int copies,
}
}
-static int read_object(int fd, char *buf, uint64_t oid, int copies,
+static int read_object(int fd, char *buf, uint64_t oid, uint8_t copies,
unsigned int datalen, uint64_t offset,
uint32_t cache_flags)
{
@@ -1137,7 +1139,7 @@ static int read_object(int fd, char *buf, uint64_t oid,
int copies,
false, cache_flags);
}
-static int write_object(int fd, char *buf, uint64_t oid, int copies,
+static int write_object(int fd, char *buf, uint64_t oid, uint8_t copies,
unsigned int datalen, uint64_t offset, bool create,
uint32_t cache_flags)
{
--
1.7.9.5
[Qemu-devel] [PATCH v2 2/2] sheepdog: pass copy_policy in the request
Currently copy_policy isn't used. Recent sheepdog supports erasure coding, which
make use of copy_policy internally, but require client explicitly passing
copy_policy from base inode to newly creately inode for snapshot related
operations.
If connected sheep daemon doesn't utilize copy_policy, passing it to sheep
daemon is just one extra null effect operation. So no compatibility problem.
With this patch, sheepdog can provide erasure coded volume for QEMU VM.
Cc: Kevin Wolf kw...@redhat.com
Cc: Stefan Hajnoczi stefa...@redhat.com
Signed-off-by: Liu Yuan namei.u...@gmail.com
---
block/sheepdog.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/block/sheepdog.c b/block/sheepdog.c
index b8a2985..9f0757b 100644
--- a/block/sheepdog.c
+++ b/block/sheepdog.c
@@ -126,7 +126,8 @@ typedef struct SheepdogObjReq {
uint64_t oid;
uint64_t cow_oid;
uint8_t copies;
-uint8_t reserved[7];
+uint8_t copy_policy;
+uint8_t reserved[6];
uint64_t offset;
} SheepdogObjReq;
@@ -139,7 +140,8 @@ typedef struct SheepdogObjRsp {
uint32_t data_length;
uint32_t result;
uint8_t copies;
-uint8_t reserved[3];
+uint8_t copy_policy;
+uint8_t reserved[2];
uint32_t pad[6];
} SheepdogObjRsp;
@@ -153,7 +155,8 @@ typedef struct SheepdogVdiReq {
uint64_t vdi_size;
uint32_t vdi_id;
uint8_t copies;
-uint8_t reserved[3];
+uint8_t copy_policy;
+uint8_t reserved[2];
uint32_t snapid;
uint32_t pad[3];
} SheepdogVdiReq;
@@ -1346,7 +1349,8 @@ out:
}
static int do_sd_create(BDRVSheepdogState *s, char *filename, int64_t vdi_size,
-uint32_t base_vid, uint32_t *vdi_id, int snapshot)
+uint32_t base_vid, uint32_t *vdi_id, int snapshot,
+uint8_t copy_policy)
{
SheepdogVdiReq hdr;
SheepdogVdiRsp *rsp = (SheepdogVdiRsp *)hdr;
@@ -1376,6 +1380,7 @@ static int do_sd_create(BDRVSheepdogState *s, char
*filename, int64_t vdi_size,
hdr.data_length = wlen;
hdr.vdi_size = vdi_size;
+hdr.copy_policy = copy_policy;
ret = do_req(fd, (SheepdogReq *)hdr, buf, wlen, rlen);
@@ -1528,7 +1533,8 @@ static int sd_create(const char *filename,
QEMUOptionParameter *options,
bdrv_unref(bs);
}
-ret = do_sd_create(s, vdi, vdi_size, base_vid, vid, 0);
+/* TODO: allow users to specify copy number */
+ret = do_sd_create(s, vdi, vdi_size, base_vid, vid, 0, 0);
if (!prealloc || ret) {
goto out;
}
@@ -1718,7 +1724,7 @@ static int sd_create_branch(BDRVSheepdogState *s)
*/
deleted = sd_delete(s);
ret = do_sd_create(s, s-name, s-inode.vdi_size, s-inode.vdi_id, vid,
- !deleted);
+ !deleted, s-inode.copy_policy);
if (ret) {
goto out;
}
@@ -2008,7 +2014,7 @@ static int sd_snapshot_create(BlockDriverState *bs,
QEMUSnapshotInfo *sn_info)
}
ret = do_sd_create(s, s-name, s-inode.vdi_size, s-inode.vdi_id,
new_vid,
- 1);
+ 1, s-inode.copy_policy);
if (ret 0) {
error_report(failed to create inode for snapshot. %s,
strerror(errno));
--
1.7.9.5
Re: [Qemu-devel] qemu 1.6.1
Il 23/10/2013 08:39, Michael W. Bombardieri ha scritto: Hi, My newly built qemu/win32 binary (v1.6.1) crashes in qemu-system-i386 and qemu-system-x86_64 when booting from an install CD. C:\Program Files\qemuqemu-system-x86_64 -boot d -vnc 0.0.0.0:20 -cdrom NetBSD-6.1.2-amd64.iso Assertion failed: qemu_in_coroutine(), file qemu-coroutine-lock.c, line 99 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. I noticed that qemu-system-sparc still booted OpenBSD/sparc 5.3 install CD correctly. No further info at this stage. Any ideas? It's a known problem that not everyone can reproduce. Please compile with --disable-coroutine-pool on the configure command line. Paolo
Re: [Qemu-devel] [PATCH 05/10] pci-host: Consistently set cannot_instantiate_with_device_add_yet
On 17 October 2013 14:54, arm...@redhat.com wrote: From: Markus Armbruster arm...@redhat.com Many PCI host bridges consist of a sysbus device and a PCI device. You need both for the thing to work. Arguably, these bridges should be modelled as a single, composite devices instead of pairs of seemingly independent devices you can only use together, but we're not there, yet. I disagree here -- we should be using the modularity that our device model provides, not arbitrarily squashing things together into single objects just because we've foolishly exposed to the end user direct command line access to create any random object whatsoever even if it doesn't make sense. Since the sysbus part can't be instantiated with device_add, yet, permitting it with the PCI part is useless. We shouldn't offer useless options to the user, so let's set cannot_instantiate_with_device_add_yet for them. It doesn't make sense to allow the user to create the on-PCI-bus representation of the host controller anyway even if they could device_add the host controller proper: creating the host controller will always automatically create the on-PCI-bus part. --- a/hw/mips/gt64xxx_pci.c +++ b/hw/mips/gt64xxx_pci.c @@ -1157,6 +1157,11 @@ static void gt64120_pci_class_init(ObjectClass *klass, void *data) k-device_id = PCI_DEVICE_ID_MARVELL_GT6412X; k-revision = 0x10; k-class_id = PCI_CLASS_BRIDGE_HOST; +/* + * PCI-facing part of the host bridge, not usable without the + * host-facing part, which can't be device_add'ed, yet. + */ +k-parent_class.cannot_instantiate_with_device_add_yet = true; Please don't directly access parent_class -- you should be using the proper QOM cast macros to get the DeviceClass pointer. thanks -- PMM
Re: [Qemu-devel] [PATCH 03/10] cpu: Document why cannot_instantiate_with_device_add_yet
On 17 October 2013 14:54, arm...@redhat.com wrote: From: Markus Armbruster arm...@redhat.com Signed-off-by: Markus Armbruster arm...@redhat.com Reviewed-by: Peter Maydell peter.mayd...@linaro.org -- PMM
Re: [Qemu-devel] [PATCH 04/10] apic: Document why cannot_instantiate_with_device_add_yet
On 17 October 2013 14:54, arm...@redhat.com wrote: From: Markus Armbruster arm...@redhat.com Signed-off-by: Markus Armbruster arm...@redhat.com Reviewed-by: Peter Maydell peter.mayd...@linaro.org -- PMM
Re: [Qemu-devel] [PATCH 06/10] ich9: Document why cannot_instantiate_with_device_add_yet
On 17 October 2013 14:54, arm...@redhat.com wrote: From: Markus Armbruster arm...@redhat.com An ICH9 southbridge contains several PCI devices, some of them with multiple functions. We model each function as a separate qdev. Two of them need some special wiring set up in pc_q35_init() to work: the LPC controller at 00:1f.0, and the SMBus controller at 00:1f.3. Signed-off-by: Markus Armbruster arm...@redhat.com Reviewed-by: Peter Maydell peter.mayd...@linaro.org -- PMM
Re: [Qemu-devel] [PATCH 08/10] vt82c686: Clean up use of cannot_instantiate_with_device_add_yet
On 17 October 2013 14:54, arm...@redhat.com wrote: From: Markus Armbruster arm...@redhat.com A VT82C686B southbridge has multiple functions. We model each function as a separate qdev. One of them need some special wiring set up in mips_fulong2e_init() to work: the ISA bridge at 05.0. The IDE controller at 05.1 (via-ide) has always had cannot_instantiate_with_device_add_yet set, but there is no obvious reason why device_add could not work for them. Drop it. Signed-off-by: Markus Armbruster arm...@redhat.com Reviewed-by: Peter Maydell peter.mayd...@linaro.org -- PMM
Re: [Qemu-devel] [PATCH 09/10] isa: Clean up use of cannot_instantiate_with_device_add_yet
On 17 October 2013 14:55, arm...@redhat.com wrote: From: Markus Armbruster arm...@redhat.com Drop it when there's no obvious reason why device_add could not work. Else keep and document why. * isa-fdc, port92, i8042, m48t59_isa, mc146818rtc, isa-pit, kvm-pit: drop (from the last two by dropping it from their abstract base pit-common) port92 needs its a20_out qemu_irq line wiring up, doesn't it? the pit devices have an output IRQ line that needs wiring up. -- PMM
Re: [Qemu-devel] [PATCH 01/10] qdev: Replace no_user by cannot_instantiate_with_device_add_yet
On 17 October 2013 14:54, arm...@redhat.com wrote: From: Markus Armbruster arm...@redhat.com In an ideal world, machines can be built by wiring devices together with configuration, not code. Unfortunately, that's not the world we live in right now. We still have quite a few devices that need to be wired up by code. If you try to device_add such a device, it'll fail in sometimes mysterious ways. If you're lucky, you get an unmysterious immediate crash. +/* + * Shall we hide this device model from -device / device_add? + * All devices should support instantiation with device_add, and + * this flag should not exist. But we're not there, yet. Some + * devices fail to instantiate with cryptic error messages. + * Others instantiate, but don't work. Exposing users to such + * behavior would be cruel; this flag serves to protect them. It + * should never be set without a comment explaining why it is set. + * TODO remove once we're there + */ +bool cannot_instantiate_with_device_add_yet; So reading this I'm still not entirely sure what the scope of this flag is intended to be. I can think of two possibilities: (1) the minimal definition: this device would actually crash or cause QEMU to break if you created it with device_add (2) a larger definition, which includes also devices which are completely useless if created with device_add because there's no way for the user to wire them up properly. I think most sysbus devices are going to be in (2) but not (1), because they should be fine to create and initialize, but they'll just be sitting completely pointlessly totally disconnected from the machine model. Definition (1) is a harder boundary and more straightforward to check against, but definition (2) is arguably a bit more useful for the end user. -- PMM
Re: [Qemu-devel] [PATCH 02/10] sysbus: Set cannot_instantiate_with_device_add_yet
On 17 October 2013 14:54, arm...@redhat.com wrote: From: Markus Armbruster arm...@redhat.com device_add plugs devices into suitable bus. For real buses, that actually connects the device. For sysbus, the connections need to be made separately, and device_add can't do that. The device would be left unconncected, and could not possibly work. unconnected Many, but not all sysbus devices alreasy set already cannot_instantiate_with_device_add_yet in their class init function. Set it in their abstract base's class init function sysbus_device_class_init(), and remove the now redundant assignments from device class init functions. So I think this change is probably OK (but see my comments on patch 1 about what our definition of the flag is supposed to be). But I'd like to see a list of the devices which this patch makes no-user which previously weren't. Then I could eyeball the list and check whether there's anything in it which shouldn't be. thanks -- PMM
Re: [Qemu-devel] [RFC PATCH v1: 11/12] mc: register MC qemu-file functions and expose MC tunable capability
Since more integer parameters would come in the future, so how about
set_migrate_parameter similar to set_migrate_capability?
It sets integer value, while set_migrate_capability sets bool value.
thanks,
On Mon, Oct 21, 2013 at 01:14:21AM +,
mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@us.ibm.com
The capability allows management software to throttle the MC frequency
during VM application transience.
The qemu-file savevm() functions inform the destination that the incoming
traffic is MC-specific traffic and not vanilla live-migration traffic.
Signed-off-by: Michael R. Hines mrhi...@us.ibm.com
---
hmp-commands.hx | 14 ++
hmp.c| 6 ++
hmp.h| 1 +
qapi-schema.json | 13 +
qmp-commands.hx | 23 +++
vl.c | 3 +++
6 files changed, 60 insertions(+)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index caae5ad..7db0597 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -960,6 +960,20 @@ Set maximum tolerated downtime (in seconds) for
migration.
ETEXI
{
+.name = migrate-set-mc-delay,
+.args_type = value:i,
+.params = value,
+.help = set maximum delay (in milliseconds) between
micro-checkpoints,
+.mhandler.cmd = hmp_migrate_set_mc_delay,
+},
+
+STEXI
+@item migrate_set_downtime @var{second}
+@findex migrate_set_downtime
+Set maximum tolerated downtime (in seconds) for migration.
+ETEXI
+
+{
.name = migrate_set_capability,
.args_type = capability:s,state:b,
.params = capability state,
diff --git a/hmp.c b/hmp.c
index 43896e9..8e89ac7 100644
--- a/hmp.c
+++ b/hmp.c
@@ -1026,6 +1026,12 @@ void hmp_migrate_set_downtime(Monitor *mon, const
QDict *qdict)
qmp_migrate_set_downtime(value, NULL);
}
+void hmp_migrate_set_mc_delay(Monitor *mon, const QDict *qdict)
+{
+int64_t value = qdict_get_int(qdict, value);
+qmp_migrate_set_mc_delay(value, NULL);
+}
+
void hmp_migrate_set_cache_size(Monitor *mon, const QDict *qdict)
{
int64_t value = qdict_get_int(qdict, value);
diff --git a/hmp.h b/hmp.h
index 54cf71f..b6548a3 100644
--- a/hmp.h
+++ b/hmp.h
@@ -60,6 +60,7 @@ void hmp_drive_mirror(Monitor *mon, const QDict *qdict);
void hmp_drive_backup(Monitor *mon, const QDict *qdict);
void hmp_migrate_cancel(Monitor *mon, const QDict *qdict);
void hmp_migrate_set_downtime(Monitor *mon, const QDict *qdict);
+void hmp_migrate_set_mc_delay(Monitor *mon, const QDict *qdict);
void hmp_migrate_set_speed(Monitor *mon, const QDict *qdict);
void hmp_migrate_set_capability(Monitor *mon, const QDict *qdict);
void hmp_migrate_set_cache_size(Monitor *mon, const QDict *qdict);
diff --git a/qapi-schema.json b/qapi-schema.json
index e0a430c..2ed8098 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2135,6 +2135,19 @@
{ 'command': 'migrate_set_downtime', 'data': {'value': 'number'} }
##
+# @migrate-set-mc-delay
+#
+# Set delay (in milliseconds) between micro checkpoints.
+#
+# @value: maximum delay in milliseconds
+#
+# Returns: nothing on success
+#
+# Since: 1.6
+##
+{ 'command': 'migrate-set-mc-delay', 'data': {'value': 'int'} }
+
+##
# @migrate_set_speed
#
# Set maximum speed for migration.
diff --git a/qmp-commands.hx b/qmp-commands.hx
index fba15cd..6d7ef2f 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -754,6 +754,29 @@ Example:
EQMP
{
+.name = migrate-set-mc-delay,
+.args_type = value:i,
+.mhandler.cmd_new = qmp_marshal_input_migrate_set_mc_delay,
+},
+
+SQMP
+migrate-set-mc-delay
+
+
+Set maximum delay (in milliseconds) between micro-checkpoints.
+
+Arguments:
+
+- value: maximum delay (json-int)
+
+Example:
+
+- { execute: migrate-set-mc-delay, arguments: { value: 100 } }
+- { return: {} }
+
+EQMP
+
+{
.name = client_migrate_info,
.args_type =
protocol:s,hostname:s,port:i?,tls-port:i?,cert-subject:s?,
.params = protocol hostname port tls-port cert-subject,
diff --git a/vl.c b/vl.c
index 74d52ab..fa23d66 100644
--- a/vl.c
+++ b/vl.c
@@ -29,6 +29,7 @@
#include sys/time.h
#include zlib.h
#include qemu/bitmap.h
+#include migration/qemu-file.h
/* Needed early for CONFIG_BSD etc. */
#include config-host.h
@@ -4192,6 +4193,8 @@ int main(int argc, char **argv, char **envp)
default_drive(default_sdcard, snapshot, IF_SD, 0, SD_OPTS);
register_savevm_live(NULL, ram, 0, 4, savevm_ram_handlers, NULL);
+register_savevm(NULL, mc, -1, MC_VERSION, mc_info_save,
+mc_info_load, NULL);
if (nb_numa_nodes 0) {
int i;
--
1.8.1.2
Re: [Qemu-devel] [RFC v3 0/2] use sizes.h macros for power-of-two sizes
On Tue, 24 Sep 2013 08:32:10 +0400 Antony Pavlov antonynpav...@gmail.com wrote: ping-ping On Fri, 13 Sep 2013 11:33:24 +0400 Antony Pavlov antonynpav...@gmail.com wrote: ping Changes since v2: * commit messages: drop ALL 'Reviewed-by' tags. Drop Aurelien Jarno's tag because the patchseries was completely reworked, so it need additional review. Changes since v1: * include/sizes.h - include/qemu/sizes.h * fix copyright header; * fix formatting: drop tabs; * use the BIT() macro, so it's easy-to-read the constants column; also the BIT() macro casts constant to UL; * rebase on updated master; * take into account the mips_malta: support up to 2GiB RAM commit. [RFC v3 1/2] include/qemu: introduce sizes.h [RFC v3 2/2] hw/mips: use sizes.h macros The sizes.h macros is a easy-to-read method of power-of-two memory sizes representation. The sizes.h macros are actively used in linux kernel and other projects, so let's use them in QEMU too. -- Best regards, Antony Pavlov -- -- Best regards, Antony Pavlov
Re: [Qemu-devel] [PATCH] MAINTAINERS: add block driver sub-maintainers
On Mon, Oct 21, 2013 at 02:26:15PM +0100, Stefan Hajnoczi wrote: There are a number of contributors who maintain block drivers (image formats and protocols). They should be listed in the MAINTAINERS file so that get_maintainer.pl lists them. Note that commits are still merged through Kevin or Stefan's block tree but the block driver sub-maintainers are usually the ones to review patches. Acked-by: Kevin Wolf kw...@redhat.com Signed-off-by: Stefan Hajnoczi stefa...@redhat.com --- MAINTAINERS | 38 ++ 1 file changed, 38 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 77edacf..da18a23 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -857,3 +857,41 @@ Stable 0.10 L: qemu-sta...@nongnu.org T: git git://git.qemu-project.org/qemu-stable-0.10.git S: Orphan + +Block drivers +- +VMDK +M: Fam Zheng f...@redhat.com +S: Supported +F: block/vmdk.c + +RBD +M: Josh Durgin josh.dur...@dreamhost.com +S: Supported +F: block/rbd.c + +Sheepdog +M: MORITA Kazutaka morita.kazut...@lab.ntt.co.jp +S: Supported +F: block/sheepdog.c + +VHDX +M: Jeff Cody jc...@redhat.com +S: Supported +F: block/vhdx.c This should probably be block/vhdx* instead With that, Acked-by: Jeff Cody jc...@redhat.com + +VDI +M: Stefan Weil s...@weilnetz.de +S: Maintained +F: block/vdi.c + +iSCSI +M: Ronnie Sahlberg ronniesahlb...@gmail.com +M: Paolo Bonzini pbonz...@redhat.com +S: Supported +F: block/iscsi.c + +SSH +M: Richard W.M. Jones rjo...@redhat.com +S: Supported +F: block/ssh.c -- 1.8.3.1
[Qemu-devel] [PATCH 3/3] Add migration stream analyzation script
This patch adds a python tool to the scripts directory that can read
a dumped migration stream which contains the debug_migration device
and construct a human readable JSON stream out of it.
It's very simple to use:
$ qemu-system-x86_64 -device debug_migration
(qemu) migrate exec:cat mig
$ ./scripts/analyze_migration.py -f mig
Signed-off-by: Alexander Graf ag...@suse.de
---
scripts/analyze-migration.py | 483 +++
1 file changed, 483 insertions(+)
create mode 100755 scripts/analyze-migration.py
diff --git a/scripts/analyze-migration.py b/scripts/analyze-migration.py
new file mode 100755
index 000..bf70749
--- /dev/null
+++ b/scripts/analyze-migration.py
@@ -0,0 +1,483 @@
+#!/usr/bin/env python
+#
+# Migration Stream Analyzer
+#
+# Copyright (c) 2013 Alexander Graf ag...@suse.de
+#
+# This library is free software; you can redistribute it and/or
+# modify it under the terms of the GNU Lesser General Public
+# License as published by the Free Software Foundation; either
+# version 2 of the License, or (at your option) any later version.
+#
+# This library is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+# Lesser General Public License for more details.
+#
+# You should have received a copy of the GNU Lesser General Public
+# License along with this library; if not, see http://www.gnu.org/licenses/.
+
+import numpy as np
+import json
+import os
+import argparse
+import collections
+import pprint
+
+class MigrationFile(object):
+def __init__(self, filename):
+self.filename = filename
+self.file = open(self.filename, rb)
+
+def read64(self):
+return np.asscalar(np.fromfile(self.file, count=1, dtype='i8')[0])
+
+def read32(self):
+return np.asscalar(np.fromfile(self.file, count=1, dtype='i4')[0])
+
+def read8(self):
+return np.asscalar(np.fromfile(self.file, count=1, dtype='i1')[0])
+
+def readstr(self, len = None):
+if len is None:
+len = self.read8()
+if len == 0:
+return
+return np.fromfile(self.file, count=1, dtype=('S%d' % len))[0]
+
+def readvar(self, size = None):
+if size is None:
+size = self.read8()
+if size == 0:
+return
+value = self.file.read(size)
+if len(value) != size:
+raise Exception(Unexpected end of %s at 0x%x % (self.filename,
self.file.tell()))
+return value
+
+# Search the current file from the current position onwards for a JSON
+# migration descriptor. Returns the JSON string blob.
+def read_migration_debug_json(self):
+pos = self.file.tell()
+data = self.file.read()
+dbgpos = data.find(Debug Migration)
+if dbgpos == -1:
+raise Exception(No Debug Migration device found)
+
+# The full file read closed the file as well, reopen it where we were
+self.file = open(self.filename, rb)
+self.file.seek(pos, 0)
+
+# We assume that our JSON blob starts after the Debug Migration magic
+# and is null terminated.
+return data[(dbgpos + 16):].split('\0',1)[0]
+
+def close(self):
+self.file.close()
+
+
+class RamSection(object):
+RAM_SAVE_FLAG_COMPRESS = 0x02
+RAM_SAVE_FLAG_MEM_SIZE = 0x04
+RAM_SAVE_FLAG_PAGE = 0x08
+RAM_SAVE_FLAG_EOS = 0x10
+RAM_SAVE_FLAG_CONTINUE = 0x20
+RAM_SAVE_FLAG_XBZRLE = 0x40
+RAM_SAVE_FLAG_HOOK = 0x80
+# This can be dynamic, but all targets we care about have 4k pages
+TARGET_PAGE_SIZE = 0x1000
+blocks = []
+
+def __init__(self, file, version_id, device, section_key):
+if version_id != 4:
+raise Exception(Unknown RAM version %d % version_id)
+
+self.file = file
+self.section_key = section_key
+
+def read(self):
+# Read all RAM sections
+while True:
+addr = self.file.read64()
+flags = addr 0xfff
+addr = 0xf000;
+
+if flags self.RAM_SAVE_FLAG_MEM_SIZE:
+while True:
+namelen = self.file.read8()
+# We assume that no RAM chunk is big enough to ever
+# hit the first byte of the address, so when we see
+# a zero here we know it has to be an address, not the
+# length of the next block.
+if namelen == 0:
+self.file.file.seek(-1, 1)
+break
+name = self.file.readstr(len = namelen)
+len = self.file.read64()
+self.blocks.append((name, len))
+flags = ~self.RAM_SAVE_FLAG_MEM_SIZE
+
+if flags self.RAM_SAVE_FLAG_COMPRESS:
+if flags
[Qemu-devel] [PATCH 0/3] Migration Debugging Helper Device
This patch set adds support for a simple migration debugging method. It adds a device that exports all metadata required to read a migration stream from an external program as part of the migration stream. The external program then does not need to have any knowledge of device internals of the target virtual machine. The patch set also adds a python script that serves as such an external program, allowing users to easily introspect the contents of a live migrated stream. This approach consciously does not modify any way QEMU operates. To QEMU, it is completely transparent. QEMU does not read that stream either, so you can not use it to recover from migration breakage within the code. For that, we should simply improve the migration protocol to be more future proof. This approach is about enabling offline introspection of migration stream data and structure, so that we have one more tool in our hands to see what goes wrong inside a virtual machine. Example decoded migration: http://csgraf.de/mig/mig.txt Presentation: https://www.youtube.com/watch?v=iq1x40Qsrew Slides: https://www.dropbox.com/s/otp2pk2n3g087zp/Live%20Migration.pdf Alexander Graf (3): Export savevm handlers outside of savevm.c Add migration debug device Add migration stream analyzation script hw/misc/Makefile.objs| 1 + hw/misc/debug_migration.c| 498 +++ include/qemu/savevm.h| 28 +++ savevm.c | 24 +-- scripts/analyze-migration.py | 483 + 5 files changed, 1012 insertions(+), 22 deletions(-) create mode 100644 hw/misc/debug_migration.c create mode 100644 include/qemu/savevm.h create mode 100755 scripts/analyze-migration.py -- 1.7.12.4
[Qemu-devel] [PATCH 1/3] Export savevm handlers outside of savevm.c
We need to be able to access savevm handlers from code that lives
outside of savevm.c. Extract its struct definitions and declaration
into a separate header file.
Signed-off-by: Alexander Graf ag...@suse.de
---
include/qemu/savevm.h | 28
savevm.c | 24 ++--
2 files changed, 30 insertions(+), 22 deletions(-)
create mode 100644 include/qemu/savevm.h
diff --git a/include/qemu/savevm.h b/include/qemu/savevm.h
new file mode 100644
index 000..5dae243
--- /dev/null
+++ b/include/qemu/savevm.h
@@ -0,0 +1,28 @@
+#ifndef QEMU_SAVEVM_H
+#define QEMU_SAVEVM_H
+
+typedef struct CompatEntry {
+char idstr[256];
+int instance_id;
+} CompatEntry;
+
+typedef struct SaveStateEntry {
+QTAILQ_ENTRY(SaveStateEntry) entry;
+char idstr[256];
+int instance_id;
+int alias_id;
+int version_id;
+int section_id;
+SaveVMHandlers *ops;
+const VMStateDescription *vmsd;
+void *opaque;
+CompatEntry *compat;
+int no_migrate;
+int is_ram;
+} SaveStateEntry;
+
+typedef QTAILQ_HEAD(EHCIQueueHead, EHCIQueue) EHCIQueueHead;
+typedef QTAILQ_HEAD(savevm_handlers, SaveStateEntry) SaveStateEntryHead;
+extern SaveStateEntryHead savevm_handlers;
+
+#endif /* QEMU_SAVEVM_H */
diff --git a/savevm.c b/savevm.c
index 2f631d4..eea45e1 100644
--- a/savevm.c
+++ b/savevm.c
@@ -1457,29 +1457,9 @@ const VMStateInfo vmstate_info_bitmap = {
.put = put_bitmap,
};
-typedef struct CompatEntry {
-char idstr[256];
-int instance_id;
-} CompatEntry;
-
-typedef struct SaveStateEntry {
-QTAILQ_ENTRY(SaveStateEntry) entry;
-char idstr[256];
-int instance_id;
-int alias_id;
-int version_id;
-int section_id;
-SaveVMHandlers *ops;
-const VMStateDescription *vmsd;
-void *opaque;
-CompatEntry *compat;
-int no_migrate;
-int is_ram;
-} SaveStateEntry;
-
+#include qemu/savevm.h
-static QTAILQ_HEAD(savevm_handlers, SaveStateEntry) savevm_handlers =
-QTAILQ_HEAD_INITIALIZER(savevm_handlers);
+SaveStateEntryHead savevm_handlers = QTAILQ_HEAD_INITIALIZER(savevm_handlers);
static int global_section_id;
static int calculate_new_instance_id(const char *idstr)
--
1.7.12.4
[Qemu-devel] [PATCH 2/3] Add migration debug device
This patch adds a pseudo device whose sole purpose is to encapsulate
a machine readable layout description of the vmstate stream layout inside
of the stream.
With this device enabled in the system while a migration is happening, we
have to chance to decypher the contents of the stream from an external
program without any knowledge of the device layout of the guest.
Signed-off-by: Alexander Graf ag...@suse.de
---
hw/misc/Makefile.objs | 1 +
hw/misc/debug_migration.c | 498 ++
2 files changed, 499 insertions(+)
create mode 100644 hw/misc/debug_migration.c
diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index 2578e29..4cfe8a4 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -41,3 +41,4 @@ obj-$(CONFIG_SLAVIO) += slavio_misc.o
obj-$(CONFIG_ZYNQ) += zynq_slcr.o
obj-$(CONFIG_PVPANIC) += pvpanic.o
+obj-y += debug_migration.o
diff --git a/hw/misc/debug_migration.c b/hw/misc/debug_migration.c
new file mode 100644
index 000..813041e
--- /dev/null
+++ b/hw/misc/debug_migration.c
@@ -0,0 +1,498 @@
+/*
+ * QEMU pseudo-device to expose migration details
+ *
+ * Copyright (c) 2013 Alexander Graf ag...@suse.de
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see http://www.gnu.org/licenses/.
+ */
+
+#include hw/hw.h
+#include qemu/savevm.h
+#include qapi/qmp/qstring.h
+
+#define TYPE_DEBUG_MIGRATION_DEVICE debug-migration
+
+typedef struct DebugMigration {
+DeviceState parent_obj;
+
+uint8_t magic[16];
+int32_t size;
+char *data;
+} DebugMigration;
+
+
+/ QJSON */
+
+typedef struct QJSON {
+QString *str;
+bool omit_comma;
+unsigned long self_size_offset;
+} QJSON;
+
+static void json_emit_element(QJSON *json, const char *name)
+{
+/* Check whether we need to print a , before an element */
+if (json-omit_comma) {
+json-omit_comma = false;
+} else {
+qstring_append(json-str, , );
+}
+
+if (name) {
+qstring_append(json-str, \);
+qstring_append(json-str, name);
+qstring_append(json-str, \ : );
+}
+}
+
+static void json_start_object(QJSON *json, const char *name)
+{
+json_emit_element(json, name);
+qstring_append(json-str, { );
+json-omit_comma = true;
+}
+
+static void json_end_object(QJSON *json)
+{
+qstring_append(json-str, });
+json-omit_comma = false;
+}
+
+static void json_start_array(QJSON *json, const char *name)
+{
+json_emit_element(json, name);
+qstring_append(json-str, [ );
+json-omit_comma = true;
+}
+
+static void json_end_array(QJSON *json)
+{
+qstring_append(json-str, ]);
+json-omit_comma = false;
+}
+
+static void json_prop_int(QJSON *json, const char *name, int64_t val)
+{
+json_emit_element(json, name);
+qstring_append_int(json-str, val);
+}
+
+static void json_prop_str(QJSON *json, const char *name, const char *str)
+{
+json_emit_element(json, name);
+qstring_append_chr(json-str, '');
+qstring_append(json-str, str);
+qstring_append_chr(json-str, '');
+}
+
+static QJSON *qjson_new(void)
+{
+QJSON *json = g_new(QJSON, 1);
+json-str = qstring_from_str({ );
+json-omit_comma = true;
+return json;
+}
+
+static void qjson_finish(QJSON *json)
+{
+json_end_object(json);
+}
+
+
+/ fake_file */
+
+
+static int fake_file_put_buffer(void *opaque, const uint8_t *json,
+int64_t pos, int size)
+{
+size_t *offset = (size_t *)opaque;
+*offset += size;
+return size;
+}
+
+const QEMUFileOps fake_file_ops = {
+.put_buffer = fake_file_put_buffer,
+};
+
+
+/ debug_migration */
+
+static void print_vmsd(QJSON *json, const VMStateDescription *vmsd,
+ void *opaque);
+static void print_vmsd_one(QJSON *json, const VMStateDescription *vmsd,
+ void *opaque, int version_id);
+static const VMStateDescription vmstate_debug_migration;
+
+
+static void print_non_vmstate(QJSON *json, SaveStateEntry *se)
+{
+QEMUFile *fakefile;
+size_t offset = 0;
+
+fakefile = qemu_fopen_ops(offset, fake_file_ops);
+
+offset = 0;
+se-ops-save_state(fakefile, se-opaque);
+qemu_fflush(fakefile);
+
+json_prop_int(json, size, offset);
+json_start_array(json, fields);
+
[Qemu-devel] CfP: Virtualisation and IaaS DevRoom at FOSDEM'14
https://groups.google.com/forum/#!forum/fosdem14-virt-and-iaas-devroom Call for Participation The scope for this devroom is open source, openly-developed projects in the areas of virtualisation and IaaS type clouds, ranging from low level to data center, up to cloud management platforms and cloud resource orchestration. Sessions should always target a developer audience. Bonus points for collaborative sessions that would be appealing to developers from multiple projects. We are particularly interested in the following themes: - low level virtualisation aspects - new features in classic and container-based virtualisation technologies - new use cases for virtualisation, such as virtualisation in mobile, automotive and embedded in general - other resource virtualisation technologies: networking, storage, … - deep technical dives into specific IaaS or virtualisation management projects features - relationship between IaaS projects and specific dependencies (not just virtualisation) - integration and development leveraging solutions from multiple projects Important dates Submission deadline: Sunday, December 1st, 2013 Acceptance notifications: Sunday, December 15th, 2013 Final schedule announcement: Friday January 10th, 2014 Devroom @ FOSDEM'14: February 1st 2nd, 2014 Practical Submissions should be 40 minutes, and consist of a 30 minute presentation with 10 minutes of QA or 40 minutes of discussions (e.g., requests for feedback, open discussions, etc.). Interactivity is encouraged, but optional. Talks are in English only. We do not provide travel assistance or reimbursement of travel expenses for accepted speakers. Submissions should be made via the FOSDEM submission page at https://penta.fosdem.org/submission/FOSDEM14 : - If necessary, create a Pentabarf account and activate it - In the “Person” section, provide First name, Last name (in the “General” tab), Email (in the “Contact” tab) and Bio (“Abstract” field in the “Description” tab) - Submit a proposal by clicking on “Create event - Important! Select the Virtualisation and IaaS track (on the “General” tab) - Provide the title of your talk (“Event title” in the “General” tab) - Provide a 250-word description of the subject of the talk and the intended audience (in the “Abstract” field of the “Description” tab) - Provide a rough outline of the talk or goals of the session (a short list of bullet points covering topics that will be discussed) in the “Full description” field in the “Description” tab Contact For questions w.r.t. the Virtualisation and IaaS DevRoom at FOSDEM'14, please contact the organizers via fosdem14-virt-and-iaas-devr...@googlegroups.com (or via https://groups.google.com/forum/#!forum/fosdem14-virt-and-iaas-devroom).
[Qemu-devel] [Bug 1243639] [NEW] qemu-1.5.3 segment fault with -vga qxl
Public bug reported: execute qemu-system-x86_64-enable-kvm -machine accel=kvm:tcg -m 1G -drive file=/dev/sda --full-screen -spice addr=127.0.0.1,port=5900 ,disable-ticketing -vga qxl on shell will get segment fault after a few seconds if I don't connect to it with spicec client immediately. IF excute spicec -h 127.0.0.1 -p 5900 immediately after the qemu-system-x86_64 execution, then no segment fault happens and it runs well. = GDB output: root@kali-john:~# gdb /usr/local/bin/qemu-system-x86_64 GNU gdb (GDB) 7.4.1-debian (gdb) run -enable-kvm -machine accel=kvm:tcg -m 1G -drive file=/dev/sda --full-screen -spice addr=127.0.0.1,port=5900,disable-ticketing -vga qxl [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. [New Thread 0x73737700 (LWP 14797)] [New Thread 0x72d54700 (LWP 14798)] [New Thread 0x70fff700 (LWP 14799)] Program received signal SIGSEGV, Segmentation fault. 0x7683ad70 in pixman_image_get_data () from /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (gdb) bt #0 0x7683ad70 in pixman_image_get_data () from /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 #1 0x5581060a in surface_data (s=0x566183a0) at /zh-download/QEMU/qemu-1.5.3/include/ui/console.h:235 #2 0x55818616 in vga_draw_graphic (s=0x5662c778, full_update=1) at /zh-download/QEMU/qemu-1.5.3/hw/display/vga.c:1788 #3 0x55818c6a in vga_update_display (opaque=0x5662c778) at /zh-download/QEMU/qemu-1.5.3/hw/display/vga.c:1917 #4 0x5580eb15 in qxl_hw_update (opaque=0x5662bd70) at /zh-download/QEMU/qemu-1.5.3/hw/display/qxl.c:1766 #5 0x557bd6bc in graphic_hw_update (con=0x56618d00) at ui/console.c:254 #6 0x557c8426 in qemu_spice_display_refresh (ssd=0x5662c418) at ui/spice-display.c:417 #7 0x5580eff0 in display_refresh (dcl=0x5662c420) at /zh-download/QEMU/qemu-1.5.3/hw/display/qxl.c:1886 #8 0x557c0cb1 in dpy_refresh (s=0x56618370) at ui/console.c:1436 #9 0x557bd3af in gui_update (opaque=0x56618370) at ui/console.c:192 #10 0x55797f20 in qemu_run_timers (clock=0x565b5a30) at qemu-timer.c:394 #11 0x55798183 in qemu_run_all_timers () at qemu-timer.c:453 #12 0x55760bb7 in main_loop_wait (nonblocking=0) at main-loop.c:470 #13 0x557cd19c in main_loop () at vl.c:2029 #14 0x557d43f2 in main (argc=13, argv=0x7fffe2b8, envp=0x7fffe328) at vl.c:4419 (gdb) == http://www.spice-space.org/download/releases/spice-0.12.4.tar.bz2 http://www.spice-space.org/download/releases/spice-protocol-0.12.6.tar.bz2 spice compiling ./configure --enable-smartcard=nomake qemu-1.5.3 compiling ./configure \ --disable-strip --enable-debug \ --target-list=x86_64-softmmu,x86_64-linux-user \ --disable-sdl --audio-drv-list=alsa --disable-vnc --disable-xen --disable-libiscsi \ --disable-seccomp --disable-glusterfs --disable-libssh2 --disable-smartcard-nss \ --disable-usb-redir --disable-brlapi --disable-curl --disable-bsd-user \ \ --enable-kvm --enable-spice --enable-system --enable-guest-agent --enable-vhost-net root@kali-john:~# qemu-system-x86_64 -version QEMU emulator version 1.5.3, Copyright (c) 2003-2008 Fabrice Bellard ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1243639 Title: qemu-1.5.3 segment fault with -vga qxl Status in QEMU: New Bug description: execute qemu-system-x86_64-enable-kvm -machine accel=kvm:tcg -m 1G -drive file=/dev/sda --full-screen -spice addr=127.0.0.1,port=5900,disable-ticketing -vga qxl on shell will get segment fault after a few seconds if I don't connect to it with spicec client immediately. IF excute spicec -h 127.0.0.1 -p 5900 immediately after the qemu-system-x86_64 execution, then no segment fault happens and it runs well. = GDB output: root@kali-john:~# gdb /usr/local/bin/qemu-system-x86_64 GNU gdb (GDB) 7.4.1-debian (gdb) run -enable-kvm -machine accel=kvm:tcg -m 1G -drive file=/dev/sda --full-screen -spice addr=127.0.0.1,port=5900,disable-ticketing -vga qxl [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. [New Thread 0x73737700 (LWP 14797)] [New Thread 0x72d54700 (LWP 14798)] [New Thread 0x70fff700 (LWP 14799)] Program received signal SIGSEGV, Segmentation fault. 0x7683ad70 in pixman_image_get_data () from /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (gdb) bt #0 0x7683ad70 in pixman_image_get_data () from /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 #1
[Qemu-devel] [Bug 1243639] Re: qemu-1.5.3 segment fault with -vga qxl
/usr/local/bin/qemu-system-x86_64 -enable-kvm -machine accel=kvm:tcg -m 1G -drive file=/dev/sda -vga qxl will give same error -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1243639 Title: qemu-1.5.3 segment fault with -vga qxl Status in QEMU: New Bug description: execute qemu-system-x86_64-enable-kvm -machine accel=kvm:tcg -m 1G -drive file=/dev/sda --full-screen -spice addr=127.0.0.1,port=5900,disable-ticketing -vga qxl on shell will get segment fault after a few seconds if I don't connect to it with spicec client immediately. IF excute spicec -h 127.0.0.1 -p 5900 immediately after the qemu-system-x86_64 execution, then no segment fault happens and it runs well. = GDB output: root@kali-john:~# gdb /usr/local/bin/qemu-system-x86_64 GNU gdb (GDB) 7.4.1-debian (gdb) run -enable-kvm -machine accel=kvm:tcg -m 1G -drive file=/dev/sda --full-screen -spice addr=127.0.0.1,port=5900,disable-ticketing -vga qxl [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. [New Thread 0x73737700 (LWP 14797)] [New Thread 0x72d54700 (LWP 14798)] [New Thread 0x70fff700 (LWP 14799)] Program received signal SIGSEGV, Segmentation fault. 0x7683ad70 in pixman_image_get_data () from /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (gdb) bt #0 0x7683ad70 in pixman_image_get_data () from /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 #1 0x5581060a in surface_data (s=0x566183a0) at /zh-download/QEMU/qemu-1.5.3/include/ui/console.h:235 #2 0x55818616 in vga_draw_graphic (s=0x5662c778, full_update=1) at /zh-download/QEMU/qemu-1.5.3/hw/display/vga.c:1788 #3 0x55818c6a in vga_update_display (opaque=0x5662c778) at /zh-download/QEMU/qemu-1.5.3/hw/display/vga.c:1917 #4 0x5580eb15 in qxl_hw_update (opaque=0x5662bd70) at /zh-download/QEMU/qemu-1.5.3/hw/display/qxl.c:1766 #5 0x557bd6bc in graphic_hw_update (con=0x56618d00) at ui/console.c:254 #6 0x557c8426 in qemu_spice_display_refresh (ssd=0x5662c418) at ui/spice-display.c:417 #7 0x5580eff0 in display_refresh (dcl=0x5662c420) at /zh-download/QEMU/qemu-1.5.3/hw/display/qxl.c:1886 #8 0x557c0cb1 in dpy_refresh (s=0x56618370) at ui/console.c:1436 #9 0x557bd3af in gui_update (opaque=0x56618370) at ui/console.c:192 #10 0x55797f20 in qemu_run_timers (clock=0x565b5a30) at qemu-timer.c:394 #11 0x55798183 in qemu_run_all_timers () at qemu-timer.c:453 #12 0x55760bb7 in main_loop_wait (nonblocking=0) at main-loop.c:470 #13 0x557cd19c in main_loop () at vl.c:2029 #14 0x557d43f2 in main (argc=13, argv=0x7fffe2b8, envp=0x7fffe328) at vl.c:4419 (gdb) == http://www.spice-space.org/download/releases/spice-0.12.4.tar.bz2 http://www.spice-space.org/download/releases/spice-protocol-0.12.6.tar.bz2 spice compiling ./configure --enable-smartcard=nomake qemu-1.5.3 compiling ./configure \ --disable-strip --enable-debug \ --target-list=x86_64-softmmu,x86_64-linux-user \ --disable-sdl --audio-drv-list=alsa --disable-vnc --disable-xen --disable-libiscsi \ --disable-seccomp --disable-glusterfs --disable-libssh2 --disable-smartcard-nss \ --disable-usb-redir --disable-brlapi --disable-curl --disable-bsd-user \ \ --enable-kvm --enable-spice --enable-system --enable-guest-agent --enable-vhost-net root@kali-john:~# qemu-system-x86_64 -version QEMU emulator version 1.5.3, Copyright (c) 2003-2008 Fabrice Bellard To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1243639/+subscriptions
[Qemu-devel] [Bug 1243639] Re: qemu-1.5.3 segment fault with -vga qxl
a funny thing: if I change the -drive file=/dev/sda to -drive file=/dev/sdb , it will not run into segment fault. The different between sda sdb is as following: linux is installed on /dev/sda and/dev/sdb is another physical hard driver. = When change /dev/sda to /dev/sdb , it works well as following: (gdb) run -enable-kvm -machine accel=kvm:tcg -m 1G -drive file=/dev/sdb --full-screen -spice addr=127.0.0.1,port=5900,disable-ticketing -vga qxl The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /usr/local/bin/qemu-system-x86_64 -enable-kvm -machine accel=kvm:tcg -m 1G -drive file=/dev/sdb --full-screen -spice addr=127.0.0.1,port=5900,disable-ticketing -vga qxl warning: Could not load shared library symbols for linux-vdso.so.1. Do you need set solib-search-path or set sysroot? [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. [New Thread 0x73737700 (LWP 15056)] [New Thread 0x72d54700 (LWP 15057)] [New Thread 0x70fff700 (LWP 15058)] [Thread 0x73737700 (LWP 15056) exited] --- No segment fault error any more !! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1243639 Title: qemu-1.5.3 segment fault with -vga qxl Status in QEMU: New Bug description: execute qemu-system-x86_64-enable-kvm -machine accel=kvm:tcg -m 1G -drive file=/dev/sda --full-screen -spice addr=127.0.0.1,port=5900,disable-ticketing -vga qxl on shell will get segment fault after a few seconds if I don't connect to it with spicec client immediately. IF excute spicec -h 127.0.0.1 -p 5900 immediately after the qemu-system-x86_64 execution, then no segment fault happens and it runs well. = GDB output: root@kali-john:~# gdb /usr/local/bin/qemu-system-x86_64 GNU gdb (GDB) 7.4.1-debian (gdb) run -enable-kvm -machine accel=kvm:tcg -m 1G -drive file=/dev/sda --full-screen -spice addr=127.0.0.1,port=5900,disable-ticketing -vga qxl [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. [New Thread 0x73737700 (LWP 14797)] [New Thread 0x72d54700 (LWP 14798)] [New Thread 0x70fff700 (LWP 14799)] Program received signal SIGSEGV, Segmentation fault. 0x7683ad70 in pixman_image_get_data () from /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (gdb) bt #0 0x7683ad70 in pixman_image_get_data () from /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 #1 0x5581060a in surface_data (s=0x566183a0) at /zh-download/QEMU/qemu-1.5.3/include/ui/console.h:235 #2 0x55818616 in vga_draw_graphic (s=0x5662c778, full_update=1) at /zh-download/QEMU/qemu-1.5.3/hw/display/vga.c:1788 #3 0x55818c6a in vga_update_display (opaque=0x5662c778) at /zh-download/QEMU/qemu-1.5.3/hw/display/vga.c:1917 #4 0x5580eb15 in qxl_hw_update (opaque=0x5662bd70) at /zh-download/QEMU/qemu-1.5.3/hw/display/qxl.c:1766 #5 0x557bd6bc in graphic_hw_update (con=0x56618d00) at ui/console.c:254 #6 0x557c8426 in qemu_spice_display_refresh (ssd=0x5662c418) at ui/spice-display.c:417 #7 0x5580eff0 in display_refresh (dcl=0x5662c420) at /zh-download/QEMU/qemu-1.5.3/hw/display/qxl.c:1886 #8 0x557c0cb1 in dpy_refresh (s=0x56618370) at ui/console.c:1436 #9 0x557bd3af in gui_update (opaque=0x56618370) at ui/console.c:192 #10 0x55797f20 in qemu_run_timers (clock=0x565b5a30) at qemu-timer.c:394 #11 0x55798183 in qemu_run_all_timers () at qemu-timer.c:453 #12 0x55760bb7 in main_loop_wait (nonblocking=0) at main-loop.c:470 #13 0x557cd19c in main_loop () at vl.c:2029 #14 0x557d43f2 in main (argc=13, argv=0x7fffe2b8, envp=0x7fffe328) at vl.c:4419 (gdb) == http://www.spice-space.org/download/releases/spice-0.12.4.tar.bz2 http://www.spice-space.org/download/releases/spice-protocol-0.12.6.tar.bz2 spice compiling ./configure --enable-smartcard=nomake qemu-1.5.3 compiling ./configure \ --disable-strip --enable-debug \ --target-list=x86_64-softmmu,x86_64-linux-user \ --disable-sdl --audio-drv-list=alsa --disable-vnc --disable-xen --disable-libiscsi \ --disable-seccomp --disable-glusterfs --disable-libssh2 --disable-smartcard-nss \ --disable-usb-redir --disable-brlapi --disable-curl --disable-bsd-user \ \ --enable-kvm --enable-spice --enable-system --enable-guest-agent --enable-vhost-net root@kali-john:~# qemu-system-x86_64 -version QEMU emulator version
Re: [Qemu-devel] About VM fork in QEMU
Live cloning is a disaster waiting to happen if not done in a very carefully controlled environment (I could maybe see it useful across two private networks for forensic analysis or running what-if scenarios, but never for provisioning enterprise-quality public-facing servers). Remember, if you ever expose both forks of a live clone to the same network at the same time, you have a security vulnerability if you did not manage to scrube the random pool of the two guests to be different, where the crypto behavior of the second guest can be guessed by observing the behavior of the first. But scrubbing memory correctly requires knowing EXACTLY where in memory the random pool is stored, which is highly guest-dependent, and may be spread across multiple guest locations. With offline disk images, the set of information to scrub is a bit easier, and in fact, 'virt-sysprep' from the libguestfs tools can do it for a number of guests, but virt-sysprep (rightfully) refuses to try to scrub a live image. Do your forked guests really have to run in parallel, or is it sufficient to serialize the running of one variation followed by the other variation? It's better to have them run in parallel since our project doesn't have any network stuff. However, running each variation sequentially is also sufficient for us. What we are concerned the most is whether we can get a snapshot in milliseconds because we don't really need to save the memory state to disk for future reversion. Could you let me know if it's possible for qemu or qemu-kvm with minor changes? As far as I know, the only way to run two guests that diverge from the same live state is to take a snapshot and then run two qemu instances that both point to that common state as their starting point, and I would personally never attempt it in parallel. Meanwhile, although you complained that snapshots are too heavyweight, it's really the only way I know to even begin to attempt live cloning with current qemu. Of course, being open source, you're welcome to submit a patch to add features to qemu to do a faster live clone. But be prepared for an uphill battle if you cannot prove that such a patch does not introduce security implications running improperly scrubbed forks in parallel. Thanks for letting me know about it. Yes, if only there's communication between the guest and outside world, live cloning can bring a bunch of security issues (e.g., IP address spoofing). But since in our scenario VM doesn't have any network stuff, we would be happy if only there's a quick-and-dirty way to implement it. Xinyang -- Xinyang GE Department of Computer Science Engineering The Pennsylvania State University Homepage: http://www.cse.psu.edu/~xxg113/
Re: [Qemu-devel] [PATCH for-1.7] seccomp: setting -sandbox on by default
On 10/22/2013 11:00 AM, Anthony Liguori wrote:
On Tue, Oct 22, 2013 at 12:21 PM, Eduardo Otubo
ot...@linux.vnet.ibm.com wrote:
Inverting the way sandbox handles arguments, making possible to have no
argument and still have '-sandbox on' enabled.
Signed-off-by: Eduardo Otubo ot...@linux.vnet.ibm.com
---
The option '-sandbox on' is now used by default by virt-test[0] -- it has been
merged into the 'next' branch and will be available in the next release,
meaning we have a back support for regression tests if anything breaks because
of some missing system call not listed in the whitelist.
This being said, I think it makes sense to have this option set to 'on' by
default in the next Qemu version. It's been a while since no missing syscall is
reported and at this point the whitelist seems to be pretty mature.
[0] -
https://github.com/autotest/virt-test/commit/50e1f7d47a94f4c770880cd8ec0f18365dcba714
This breaks hot_add of a network device that uses a script= argument, correct?
If so, this cannot be made default.
Anthony, I believe you're talking about the blacklist feature. This is
the old whitelist that is already upstream and it does not block any
network device to be hot plugged.
Regards,
Anthony Liguori
qemu-options.hx | 4 ++--
vl.c| 47 ---
2 files changed, 30 insertions(+), 21 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index 5dc8b75..315a86d 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2982,13 +2982,13 @@ Old param mode (ARM only).
ETEXI
DEF(sandbox, HAS_ARG, QEMU_OPTION_sandbox, \
--sandbox arg Enable seccomp mode 2 system call filter (default
'off').\n,
+-sandbox arg Enable seccomp mode 2 system call filter (default
'on').\n,
QEMU_ARCH_ALL)
STEXI
@item -sandbox @var{arg}
@findex -sandbox
Enable Seccomp mode 2 system call filter. 'on' will enable syscall filtering
and 'off' will
-disable it. The default is 'off'.
+disable it. The default is 'on'.
ETEXI
DEF(readconfig, HAS_ARG, QEMU_OPTION_readconfig,
diff --git a/vl.c b/vl.c
index b42ac67..ae3bdc9 100644
--- a/vl.c
+++ b/vl.c
@@ -529,6 +529,20 @@ static QemuOptsList qemu_msg_opts = {
},
};
+static QemuOpts *qemu_get_sandbox_opts(void)
+{
+QemuOptsList *list;
+QemuOpts *opts;
+
+list = qemu_find_opts(sandbox);
+assert(list);
+opts = qemu_opts_find(list, NULL);
+if (!opts) {
+opts = qemu_opts_create_nofail(list);
+}
+return opts;
+}
+
/**
* Get machine options
*
@@ -960,24 +974,9 @@ static int bt_parse(const char *opt)
return 1;
}
-static int parse_sandbox(QemuOpts *opts, void *opaque)
+static bool sandbox_enabled(bool default_usb)
{
-/* FIXME: change this to true for 1.3 */
-if (qemu_opt_get_bool(opts, enable, false)) {
-#ifdef CONFIG_SECCOMP
-if (seccomp_start() 0) {
-qerror_report(ERROR_CLASS_GENERIC_ERROR,
- failed to install seccomp syscall filter in the
kernel);
-return -1;
-}
-#else
-qerror_report(ERROR_CLASS_GENERIC_ERROR,
- sandboxing request but seccomp is not compiled into this
build);
-return -1;
-#endif
-}
-
-return 0;
+return qemu_opt_get_bool(qemu_get_sandbox_opts(), sandbox, default_usb);
}
bool usb_enabled(bool default_usb)
@@ -3806,8 +3805,18 @@ int main(int argc, char **argv, char **envp)
exit(1);
}
-if (qemu_opts_foreach(qemu_find_opts(sandbox), parse_sandbox, NULL, 0)) {
-exit(1);
+if (sandbox_enabled(true)) {
+#ifdef CONFIG_SECCOMP
+if (seccomp_start() 0) {
+qerror_report(ERROR_CLASS_GENERIC_ERROR,
+ failed to install seccomp syscall filter in the
kernel);
+return -1;
+}
+#else
+qerror_report(ERROR_CLASS_GENERIC_ERROR,
+ sandboxing request but seccomp is not compiled into this
build);
+return -1;
+#endif
}
#ifndef _WIN32
--
1.8.3.1
--
Eduardo Otubo
IBM Linux Technology Center
Re: [Qemu-devel] [PATCH v7] powerpc: add PVR mask support
Am 27.09.2013 09:05, schrieb Alexey Kardashevskiy: IBM POWERPC processors encode PVR as a CPU family in higher 16 bits and a CPU version in lower 16 bits. Since there is no significant change in behavior between versions, there is no point to add every single CPU version in QEMU's CPU list. Also, new CPU versions of already supported CPU won't break the existing code. This adds PVR value/mask support for KVM, i.e. for -cpu host option. As CPU family class name for POWER7 is POWER7-family, there is no need to touch aliases. Cc: Andreas Färber afaer...@suse.de Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru As promised to Paul, using the Hackathon timeslot to review this: Reviewed-by: Andreas Färber afaer...@suse.de and sorry for the delay. Regards, 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] [RFC PATCH v2 1/6] hw: arm_gic: Fix gic_set_irq handling
On Mon, Oct 14, 2013 at 03:24:43PM +0100, Peter Maydell wrote:
On 26 September 2013 22:03, Christoffer Dall
christoffer.d...@linaro.org wrote:
For some reason only edge-triggered or enabled level-triggered
interrupts would set the pending state of a raised IRQ. This is not in
compliance with the specs, which indicate that the pending state is
separate from the enabled state, which only controls if a pending
interrupt is actually forwarded to the CPU interface.
Therefore, simply always set the pending state on a rising edge, but
only clear the pending state of falling edge if the interrupt is level
triggered.
@@ -128,11 +128,12 @@ static void gic_set_irq(void *opaque, int irq, int
level)
if (level) {
GIC_SET_LEVEL(irq, cm);
-if (GIC_TEST_TRIGGER(irq) || GIC_TEST_ENABLED(irq, cm)) {
-DPRINTF(Set %d pending mask %x\n, irq, target);
-GIC_SET_PENDING(irq, target);
-}
+DPRINTF(Set %d pending mask %x\n, irq, target);
+GIC_SET_PENDING(irq, target);
} else {
+if (!GIC_TEST_TRIGGER(irq)) {
+GIC_CLEAR_PENDING(irq, target);
+}
GIC_CLEAR_LEVEL(irq, cm);
}
gic_update(s);
The old logic is definitely wrong here, but this still isn't
quite right. See the GIC v2 spec, section 4.3.8 GICD_ICPENDRn
and specifically the circuit diagram in Figure 4.10.
For a level triggered interrupt we mustn't clear the pending
state on a 1-0 transition of the input if it was latched
by the guest writing to GICD_ISPENDR.
In other words, the internal state of the GIC (ie the state
of the latch) and the value in the ICPENDR/ISPENDR register
on read aren't the same thing, and the bug in our current
GIC model is that we're trying to use the .pending field
for both purposes at the same time.
So I think that's a comment that belongs more in the category of all the
things that are broken with the GICv2 emulation and should be separate
fixes. I don't believe Linux uses this and the in-kernel GIC emulation
also doesn't keep track of this state, but the following patch should
address the issue. Do you want me to fold such two patches into one?
-Christoffer
[Qemu-devel] [PATCH] arm_gic: Keep track of GICD_CPENDR and GICD_SPENDR
If software writes to the ISPENDR and sets the pending state of a
level-triggered interrupt, the falling edge of the hardware input must
not clear the pending state. Conversely, if software writes to the
ICPENDR, the pending state of a level-triggered interrupt should only be
cleared if the hardware input is not asserted.
This requires an extra state variable to keep track of software writes.
Signed-off-by: Christoffer Dall christoffer.d...@linaro.org
---
hw/intc/arm_gic.c| 20 +---
hw/intc/arm_gic_common.c | 5 +++--
hw/intc/gic_internal.h | 4
3 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/hw/intc/arm_gic.c b/hw/intc/arm_gic.c
index d1ddac1..db54061 100644
--- a/hw/intc/arm_gic.c
+++ b/hw/intc/arm_gic.c
@@ -101,6 +101,12 @@ static void gic_clear_pending(GICState *s, int irq, int
cm, uint8_t src)
{
unsigned cpu;
+/* If a level-triggered interrupt has been set to pending through the
+ * GICD_SPENDR, then a falling edge does not clear the pending state.
+ */
+if (GIC_TEST_SW_PENDING(irq, cm))
+return;
+
GIC_CLEAR_PENDING(irq, cm);
if (irq GIC_NR_SGIS) {
cpu = (unsigned)ffs(cm) - 1;
@@ -177,8 +183,9 @@ uint32_t gic_acknowledge_irq(GICState *s, int cpu)
s-last_active[new_irq][cpu] = s-running_irq[cpu];
/* Clear pending flags for both level and edge triggered interrupts.
Level triggered IRQs will be reasserted once they become inactive. */
-gic_clear_pending(s, new_irq, GIC_TEST_MODEL(new_irq) ? ALL_CPU_MASK : cm,
- GIC_SGI_SRC(new_irq, cpu));
+cm = GIC_TEST_MODEL(new_irq) ? ALL_CPU_MASK : cm;
+GIC_CLEAR_SW_PENDING(new_irq, cm);
+gic_clear_pending(s, new_irq, cm, GIC_SGI_SRC(new_irq, cpu));
gic_set_running_irq(s, cpu, new_irq);
DPRINTF(ACK %d\n, new_irq);
return new_irq;
@@ -445,16 +452,23 @@ static void gic_dist_writeb(void *opaque, hwaddr offset,
for (i = 0; i 8; i++) {
if (value (1 i)) {
GIC_SET_PENDING(irq + i, GIC_TARGET(irq + i));
+if (!GIC_TEST_TRIGGER(irq + i)) {
+GIC_SET_SW_PENDING(irq + i, GIC_TARGET(irq + i));
+}
}
}
} else if (offset 0x300) {
+int cm = (1 cpu);
/* Interrupt Clear Pending. */
irq = (offset - 0x280) * 8 + GIC_BASE_IRQ;
if (irq = s-num_irq)
goto bad_reg;
for (i = 0; i 8; i++, irq++) {
if (irq GIC_NR_SGIS value (1 i)) {
-gic_clear_pending(s, irq, 1 cpu, 0);
+GIC_CLEAR_SW_PENDING(irq, cm);
+if (GIC_TEST_TRIGGER(irq + i) || !GIC_TEST_LEVEL(irq, cm)) {
+GIC_CLEAR_PENDING(irq, cm);
+}
}
}
} else if (offset 0x400) {
diff --git a/hw/intc/arm_gic_common.c b/hw/intc/arm_gic_common.c
index 1d3b738..7f0615f 100644
--- a/hw/intc/arm_gic_common.c
+++ b/hw/intc/arm_gic_common.c
@@ -43,11 +43,12 @@ static int gic_post_load(void *opaque, int version_id)
static const VMStateDescription vmstate_gic_irq_state = {
.name = arm_gic_irq_state,
-.version_id = 1,
-.minimum_version_id = 1,
+.version_id = 2,
+.minimum_version_id = 2,
.fields = (VMStateField[]) {
VMSTATE_UINT8(enabled, gic_irq_state),
VMSTATE_UINT8(pending, gic_irq_state),
+VMSTATE_UINT8(sw_pending, gic_irq_state),
VMSTATE_UINT8(active, gic_irq_state),
VMSTATE_UINT8(level, gic_irq_state),
VMSTATE_BOOL(model, gic_irq_state),
diff --git a/hw/intc/gic_internal.h b/hw/intc/gic_internal.h
index f9133b9..173c607 100644
--- a/hw/intc/gic_internal.h
+++ b/hw/intc/gic_internal.h
@@ -43,6 +43,9 @@
#define GIC_SET_PENDING(irq, cm) s-irq_state[irq].pending |= (cm)
#define GIC_CLEAR_PENDING(irq, cm) s-irq_state[irq].pending = ~(cm)
#define GIC_TEST_PENDING(irq, cm) ((s-irq_state[irq].pending (cm)) != 0)
+#define GIC_SET_SW_PENDING(irq, cm) s-irq_state[irq].sw_pending |= (cm)
+#define GIC_CLEAR_SW_PENDING(irq, cm) s-irq_state[irq].sw_pending = ~(cm)
+#define GIC_TEST_SW_PENDING(irq, cm) ((s-irq_state[irq].sw_pending (cm)) !=
0)
#define GIC_SET_ACTIVE(irq, cm) s-irq_state[irq].active |= (cm)
#define GIC_CLEAR_ACTIVE(irq, cm) s-irq_state[irq].active = ~(cm)
#define GIC_TEST_ACTIVE(irq, cm) ((s-irq_state[irq].active (cm)) != 0)
@@ -65,6 +68,7 @@ typedef struct gic_irq_state {
/* The enable bits are only banked for per-cpu interrupts. */
uint8_t enabled;
uint8_t pending;
+uint8_t sw_pending; /* keep track of GICD_ISPENDR and GICD_ICPENDR writes
*/
uint8_t active;
uint8_t level;
bool model; /* 0 = N:N, 1 = 1:N */
--
1.8.1.2
Re: [Qemu-devel] [RFC PATCH v2 3/6] hw: arm_gic: Keep track of SGI sources
On Mon, Oct 14, 2013 at 05:33:38PM +0100, Peter Maydell wrote:
On 14 October 2013 16:36, Peter Maydell peter.mayd...@linaro.org wrote:
[...]
Tangentially, I notice that we don't correctly handle
the PENDING bit for level triggered interrupts, since
we do:
/* Clear pending flags for both level and edge triggered interrupts.
Level triggered IRQs will be reasserted once they become inactive. */
gic_clear_pending(s, new_irq, GIC_TEST_MODEL(new_irq) ? ALL_CPU_MASK : cm,
GIC_SGI_SRC(new_irq, cpu));
in gic_acknowledge_irq(). This is wrong, because section
3.2.4 is clear for a level triggered interrupt that if the
interrupt signal remains asserted (which it usually will be)
then we go from Pending to Active+Pending (whereas our
current implementation goes from Pending to Active and
then resets Pending later in gic_complete_irq()).
Yes, I will send this patch to address this as part of the revised series:
diff --git a/hw/intc/arm_gic.c b/hw/intc/arm_gic.c
index bf1eb02..fce66c6 100644
--- a/hw/intc/arm_gic.c
+++ b/hw/intc/arm_gic.c
@@ -175,10 +180,15 @@ uint32_t gic_acknowledge_irq(GICState *s, int cpu)
return 1023;
}
s-last_active[new_irq][cpu] = s-running_irq[cpu];
-/* Clear pending flags for both level and edge triggered interrupts.
- Level triggered IRQs will be reasserted once they become inactive. */
-gic_clear_pending(s, new_irq, GIC_TEST_MODEL(new_irq) ? ALL_CPU_MASK : cm,
- GIC_SGI_SRC(new_irq, cpu));
+/* Clear pending flags for edge-triggered and non-asserted level-triggered
+ * interrupts.
+ */
+cm = GIC_TEST_MODEL(new_irq) ? ALL_CPU_MASK : cm;
+if (GIC_TEST_TRIGGER(new_irq) || !GIC_TEST_LEVEL(new_irq, cm)) {
+gic_clear_pending(s, new_irq, cm, GIC_SGI_SRC(new_irq, cpu));
+}
+
gic_set_running_irq(s, cpu, new_irq);
DPRINTF(ACK %d\n, new_irq);
return new_irq;
--
Christoffer
Re: [Qemu-devel] [PATCH] qcow2: Restore total_sectors value in save_vmstate
On 2013-10-21 22:36, Eric Blake wrote: On 10/20/2013 07:28 PM, Max Reitz wrote: Since df2a6f29a5, bdrv_co_do_writev increases the total_sectors value of a growable block devices on writes after the current end. This leads to the virtual disk apparently growing in qcow2_save_vmstate, which in turn affects the disk size captured by the internal snapshot taken directly afterwards through e.g. the HMP savevm command. Such a grown snapshot cannot be loaded after reopening the qcow2 image, since its disk size differs from the actual virtual disk size (writing a VM state does not actually increase the virtual disk size). Fix this by restoring total_sectors at the end of qcow2_save_vmstate. Signed-off-by: Max Reitz mre...@redhat.com --- block/qcow2.c | 5 + 1 file changed, 5 insertions(+) @@ -1946,6 +1947,10 @@ static int qcow2_save_vmstate(BlockDriverState *bs, QEMUIOVector *qiov, bs-growable = 1; ret = bdrv_pwritev(bs, qcow2_vm_state_offset(s) + pos, qiov); bs-growable = growable; +// bdrv_co_do_writev will have increased the total_sectors value to include +// the VM state - the VM state is however not an actual part of the block +// device, therefore, we need to restore the old value. +bs-total_sectors = total_sectors; It looks like // comments aren't forbidden, but also uncommon; I don't know if /**/ would be better. At any rate: Ah, right, sorry, I forgot. Max
Re: [Qemu-devel] [PATCH] qcow2: Unset zero_beyond_eof in save_vmstate
On 2013-10-21 22:37, Eric Blake wrote: On 10/20/2013 08:52 PM, Max Reitz wrote: Saving the VM state is done using bdrv_pwrite. This function may perform a read-modify-write, which in this case results in data being read from beyond the end of the virtual disk. Since we are actually trying to access an area which is not a part of the virtual disk, zero_beyond_eof has to be set to false before performing the partial write, otherwise the VM state may become corrupted. Signed-off-by: Max Reitz mre...@redhat.com --- Follow-up to (depends on): - qcow2: Restore total_sectors value in save_vmstate Reviewed-by: Eric Blake ebl...@redhat.com Do you have test cases that demonstrate the corruption pre-patch? I could write a test case for the other patch, but for this one it would probably be rather difficult. What I did to bisect the bug was just starting a VM over and over while saving a snapshot at some time during boot-up and trying to load that snapshot again. Sometimes, qemu itself would report a corrupted VM state, but most of the time, the guest simply hang or paniced. This is something I can detect interactively, but I don't know if I could write a test for this (at least not for hanging). Max
[Qemu-devel] [PATCH] qemu-iotests: Test for loading VM state from qcow2
Add a test for saving a VM state from a qcow2 image and loading it back
(with having restarted qemu in between); this should work without any
problems.
Signed-off-by: Max Reitz mre...@redhat.com
---
Follow-up to (depends on):
- qcow2: Restore total_sectors value in save_vmstate
- qcow2: Unset zero_beyond_eof in save_vmstate
---
tests/qemu-iotests/068 | 65
tests/qemu-iotests/group | 1 +
2 files changed, 66 insertions(+)
create mode 100755 tests/qemu-iotests/068
diff --git a/tests/qemu-iotests/068 b/tests/qemu-iotests/068
new file mode 100755
index 000..b72e555
--- /dev/null
+++ b/tests/qemu-iotests/068
@@ -0,0 +1,65 @@
+#!/bin/bash
+#
+# Test case for loading a saved VM state from a qcow2 image
+#
+# Copyright (C) 2013 Red Hat, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see http://www.gnu.org/licenses/.
+#
+
+# creator
+owner=mre...@redhat.com
+
+seq=$(basename $0)
+echo QA output created by $seq
+
+here=$PWD
+tmp=/tmp/$$
+status=1 # failure is the default!
+
+_cleanup()
+{
+ _cleanup_test_img
+}
+trap _cleanup; exit \$status 0 1 2 3 15
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+
+# This tests qocw2-specific low-level functionality
+_supported_fmt qcow2
+_supported_proto generic
+_supported_os Linux
+
+IMGOPTS=compat=1.1
+IMG_SIZE=128K
+
+echo
+echo === Saving and reloading a VM state to/from a qcow2 image ===
+echo
+_make_test_img $IMG_SIZE
+# Give qemu some time to boot before saving the VM state
+bash -c 'sleep 1; echo -e savevm 0\nquit' |\
+$QEMU -nographic -monitor stdio -serial none -hda $TEST_IMG |\
+_filter_qemu
+# Now try to continue from that VM state (this should just work)
+echo quit |\
+$QEMU -nographic -monitor stdio -serial none -hda $TEST_IMG -loadvm 0 |\
+_filter_qemu
+
+# success, all done
+echo *** done
+rm -f $seq.full
+status=0
diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
index 13c5500..3ca9cba 100644
--- a/tests/qemu-iotests/group
+++ b/tests/qemu-iotests/group
@@ -73,3 +73,4 @@
065 rw auto
066 rw auto
067 rw auto
+068 rw auto
--
1.8.3.1
Re: [Qemu-devel] [PATCH] qcow2: Unset zero_beyond_eof in save_vmstate
On 2013-10-21 22:37, Eric Blake wrote: On 10/20/2013 08:52 PM, Max Reitz wrote: Saving the VM state is done using bdrv_pwrite. This function may perform a read-modify-write, which in this case results in data being read from beyond the end of the virtual disk. Since we are actually trying to access an area which is not a part of the virtual disk, zero_beyond_eof has to be set to false before performing the partial write, otherwise the VM state may become corrupted. Signed-off-by: Max Reitz mre...@redhat.com --- Follow-up to (depends on): - qcow2: Restore total_sectors value in save_vmstate Reviewed-by: Eric Blake ebl...@redhat.com Do you have test cases that demonstrate the corruption pre-patch? Okay, so it is possible to test for this after all; I've just sent a follow-up adding such a test. Thanks for pointing that out. ;-) Max
[Qemu-devel] [PATCH] qcow2: Flush image after creation
Opening the qcow2 image with BDRV_O_NO_FLUSH prevents any flushes during
the image creation. This means that the image has not yet been flushed
to disk when qemu-img create exits. This flush is delayed until the next
operation on the image involving opening it without BDRV_O_NO_FLUSH and
closing (or directly flushing) it. For large images and/or images with a
small cluster size and preallocated metadata, this flush may take a
significant amount of time and may occur unexpectedly.
Reopening the image without BDRV_O_NO_FLUSH right before the end of
qcow2_create2() results in preponing the potentially costly flush into
the image creation, which is expected to take some time (whereas
successive image operations may be not).
Signed-off-by: Max Reitz mre...@redhat.com
---
block/qcow2.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index c1abaff..8b98c3a 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -1584,7 +1584,15 @@ static int qcow2_create2(const char *filename, int64_t
total_size,
}
}
-ret = 0;
+bdrv_close(bs);
+
+/* Reopen the image without BDRV_O_NO_FLUSH to flush it before returning */
+ret = bdrv_open(bs, filename, NULL,
+BDRV_O_RDWR | BDRV_O_CACHE_WB, drv, local_err);
+if (error_is_set(local_err)) {
+error_propagate(errp, local_err);
+}
+
out:
bdrv_unref(bs);
return ret;
--
1.8.3.1
Re: [Qemu-devel] qemu 1.6.1
Am 23.10.2013 11:00, schrieb Paolo Bonzini: Il 23/10/2013 08:39, Michael W. Bombardieri ha scritto: Hi, My newly built qemu/win32 binary (v1.6.1) crashes in qemu-system-i386 and qemu-system-x86_64 when booting from an install CD. C:\Program Files\qemuqemu-system-x86_64 -boot d -vnc 0.0.0.0:20 -cdrom NetBSD-6.1.2-amd64.iso Assertion failed: qemu_in_coroutine(), file qemu-coroutine-lock.c, line 99 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. I noticed that qemu-system-sparc still booted OpenBSD/sparc 5.3 install CD correctly. No further info at this stage. Any ideas? It's a known problem that not everyone can reproduce. Please compile with --disable-coroutine-pool on the configure command line. Paolo This patch also helps (at least for me, tested native and on Linux / Wine): http://repo.or.cz/w/qemu/ar7.git/commit/c777d5d62a729fd8b19847aaa0aad3d7a1f73f47 It looks like a compiler problem related to thread local storage (variable current). I recently got several bug reports from a Windows user and included patches to fix them in my personal tree http://repo.or.cz/w/qemu/ar7.git. The binaries on qemu.weilnetz.de are based on that tree. Stefan
[Qemu-devel] [PATCH v6 0/5] add initial support for Canon DIGIC SoC
[PATCH v6 1/5] hw/arm: add very initial support for Canon DIGIC SoC [PATCH v6 2/5] hw/arm/digic: prepare DIGIC-based boards support [PATCH v6 3/5] hw/arm/digic: add timer support [PATCH v6 4/5] hw/arm/digic: add UART support [PATCH v6 5/5] hw/arm/digic: add NOR ROM support Changes since v5: 1. rebase over latest master 2. digic_timer: add a reset function 3. digic_timer: add a VMStateDescription 4. digic_timer: fix whitespaces 5. digic_boards: fix whitespaces 6. move misplaced DIGIC_ROM* definitions to the hw/arm/digic: add NOR ROM support patch Changes since v4: 1. digic.h: parent_obj: change type Object - DeviceState 2. digic-uart: drop reg array 3. digic_boards: fix K8P3215UQB comment 4. Makefile: place digic stuff in own line 5. drop cpu-qom.h inclusion 6. digic.h: add private/public labels 7. digic.h: fix guard macro 8. move base address macros to digic.c 9. fix header comments Changes since v3: 1. fix typos and formatting 2. digic-timer: drop DPRINTF 3. digic-timer: fix DIGIC4_TIMER_BASE() macro 4. digic.c: fix max timer device string Changes since v2: 1. rebase over latest master; * pass available size to object_initialize(). 2. digic-uart: qemu_log: use LOG_UNIMP instead LOG_GUEST_ERROR; 3. digic-boards: update rom image load code: introduce digic_load_rom(). Changes since v1: 0. drop the add ARM946E-S CPU patch; 1. convert to QOM, split DIGIC SoC code and board code (thanks to Andreas Fa:rber, Peter Maydell and Peter Crosthwaite); 2. fix digic-uart (many thanks to Peter Crosthwaite for his comments); 3. digic-boards: digic4_add_k8p3215uqb_rom(): update rom image load code: use the '-bios' option. DIGIC is Canon Inc.'s name for a family of SoC for digital cameras and camcorders. See http://en.wikipedia.org/wiki/DIGIC for details. There is no publicly available specification for DIGIC chips. All information about DIGIC chip internals is based on reverse engineering efforts made by CHDK (http://chdk.wikia.com) and Magic Lantern (http://www.magiclantern.fm) projects contributors. Also this patch series adds initial support for Canon PowerShot A1100 IS compact camera (it is my only camera with connected UART interface). As the DIGIC-based cameras differences mostly are unsignificant (e.g. RAM-size, ROM type and size, GPIO usage) the other compact and DSLR cameras support can be easely added. This DIGIC support patch series is inspired by EOS QEMU from Magic Lantern project. The main differences: * EOS QEMU uses home-brew all-in-one monolith design; this patch series uses conventional qemu object-centric design; * EOS QEMU tries provide simplest emulation for most controllers inside SoC to run Magic Lantern firmware; this patch series provide more complete support only for core devices to run barebox bootloader. ** EOS QEMU does not support timer counting (this patch series emulate 1 MHz counting); ** EOS QEMU support DIGIC UART only for output character to stderr; (this patch series emulate introduces full blown UART interface); ** EOS QEMU has incomplete ROM support; (this patch series uses conventional qemu pflash). This initial DIGIC support can't be used to run the original camera firmware, but it can successfully run experimental version of barebox bootloader (see http://www.barebox.org). The last sources of barebox for PowerShot A1100 can be obtained here: https://github.com/frantony/barebox/tree/next.digic.20130829 The precompiled ROM image usable with qemu can be obtained here: https://github.com/frantony/barebox/blob/next.digic.20130829/canon-a1100-rom1.bin This ROM image (after dancing bit encoding) can be run on real Canon A1100 camera. The short build instruction for __previous__ DIGIC barebox version (it can be used with more recent sources too) can be obtained here: http://lists.infradead.org/pipermail/barebox/2013-August/016007.html
[Qemu-devel] [PATCH v6 1/5] hw/arm: add very initial support for Canon DIGIC SoC
DIGIC is Canon Inc.'s name for a family of SoC
for digital cameras and camcorders.
There is no publicly available specification for
DIGIC chips. All information about DIGIC chip
internals is based on reverse engineering efforts
made by CHDK (http://chdk.wikia.com) and
Magic Lantern (http://www.magiclantern.fm) projects
contributors.
Signed-off-by: Antony Pavlov antonynpav...@gmail.com
Reviewed-by: Andreas Färber afaer...@suse.de
---
default-configs/arm-softmmu.mak | 1 +
hw/arm/Makefile.objs| 1 +
hw/arm/digic.c | 65 +
include/hw/arm/digic.h | 35 ++
4 files changed, 102 insertions(+)
create mode 100644 hw/arm/digic.c
create mode 100644 include/hw/arm/digic.h
diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index d13bc2b..6be1ee9 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -62,6 +62,7 @@ CONFIG_FRAMEBUFFER=y
CONFIG_XILINX_SPIPS=y
CONFIG_A9SCU=y
+CONFIG_DIGIC=y
CONFIG_MARVELL_88W8618=y
CONFIG_OMAP=y
CONFIG_TSC210X=y
diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index 3671b42..eb548dd 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -4,4 +4,5 @@ obj-y += omap_sx1.o palm.o realview.o spitz.o stellaris.o
obj-y += tosa.o versatilepb.o vexpress.o xilinx_zynq.o z2.o
obj-y += armv7m.o exynos4210.o pxa2xx.o pxa2xx_gpio.o pxa2xx_pic.o
+obj-$(CONFIG_DIGIC) += digic.o
obj-y += omap1.o omap2.o strongarm.o
diff --git a/hw/arm/digic.c b/hw/arm/digic.c
new file mode 100644
index 000..0d38872
--- /dev/null
+++ b/hw/arm/digic.c
@@ -0,0 +1,65 @@
+/*
+ * QEMU model of the Canon DIGIC SoC.
+ *
+ * Copyright (C) 2013 Antony Pavlov antonynpav...@gmail.com
+ *
+ * This model is based on reverse engineering efforts
+ * made by CHDK (http://chdk.wikia.com) and
+ * Magic Lantern (http://www.magiclantern.fm) projects
+ * contributors.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include hw/arm/digic.h
+
+static void digic_init(Object *obj)
+{
+DigicState *s = DIGIC(obj);
+
+object_initialize(s-cpu, sizeof(s-cpu), arm946- TYPE_ARM_CPU);
+object_property_add_child(obj, cpu, OBJECT(s-cpu), NULL);
+}
+
+static void digic_realize(DeviceState *dev, Error **errp)
+{
+DigicState *s = DIGIC(dev);
+Error *err = NULL;
+
+object_property_set_bool(OBJECT(s-cpu), true, realized, err);
+if (err != NULL) {
+error_propagate(errp, err);
+return;
+}
+}
+
+static void digic_class_init(ObjectClass *oc, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(oc);
+
+dc-realize = digic_realize;
+}
+
+static const TypeInfo digic_type_info = {
+.name = TYPE_DIGIC,
+.parent = TYPE_DEVICE,
+.instance_size = sizeof(DigicState),
+.instance_init = digic_init,
+.class_init = digic_class_init,
+};
+
+static void digic_register_types(void)
+{
+type_register_static(digic_type_info);
+}
+
+type_init(digic_register_types)
diff --git a/include/hw/arm/digic.h b/include/hw/arm/digic.h
new file mode 100644
index 000..b7d16fb
--- /dev/null
+++ b/include/hw/arm/digic.h
@@ -0,0 +1,35 @@
+/*
+ * Misc Canon DIGIC declarations.
+ *
+ * Copyright (C) 2013 Antony Pavlov antonynpav...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef HW_ARM_DIGIC_H
+#define HW_ARM_DIGIC_H
+
+#include cpu.h
+
+#define TYPE_DIGIC digic
+
+#define DIGIC(obj) OBJECT_CHECK(DigicState, (obj), TYPE_DIGIC)
+
+typedef struct DigicState {
+/* private */
+DeviceState parent_obj;
+/* public */
+
+ARMCPU cpu;
+} DigicState;
+
+#endif /* HW_ARM_DIGIC_H */
--
1.8.4.rc3
[Qemu-devel] [PATCH v6 2/5] hw/arm/digic: prepare DIGIC-based boards support
Also this patch adds initial support for Canon
PowerShot A1100 IS compact camera.
Signed-off-by: Antony Pavlov antonynpav...@gmail.com
---
hw/arm/Makefile.objs | 1 +
hw/arm/digic_boards.c | 88 +++
2 files changed, 89 insertions(+)
create mode 100644 hw/arm/digic_boards.c
diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index eb548dd..69a8de5 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -1,4 +1,5 @@
obj-y += boot.o collie.o exynos4_boards.o gumstix.o highbank.o
+obj-$(CONFIG_DIGIC) += digic_boards.o
obj-y += integratorcp.o kzm.o mainstone.o musicpal.o nseries.o
obj-y += omap_sx1.o palm.o realview.o spitz.o stellaris.o
obj-y += tosa.o versatilepb.o vexpress.o xilinx_zynq.o z2.o
diff --git a/hw/arm/digic_boards.c b/hw/arm/digic_boards.c
new file mode 100644
index 000..77cfc81
--- /dev/null
+++ b/hw/arm/digic_boards.c
@@ -0,0 +1,88 @@
+/*
+ * QEMU model of the Canon DIGIC boards (cameras indeed :).
+ *
+ * Copyright (C) 2013 Antony Pavlov antonynpav...@gmail.com
+ *
+ * This model is based on reverse engineering efforts
+ * made by CHDK (http://chdk.wikia.com) and
+ * Magic Lantern (http://www.magiclantern.fm) projects
+ * contributors.
+ *
+ * See docs here:
+ * http://magiclantern.wikia.com/wiki/Register_Map
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include hw/boards.h
+#include exec/address-spaces.h
+#include hw/arm/digic.h
+
+typedef struct DigicBoardState {
+DigicState *digic;
+MemoryRegion ram;
+} DigicBoardState;
+
+typedef struct DigicBoard {
+hwaddr ram_size;
+hwaddr start_addr;
+} DigicBoard;
+
+static void digic4_board_setup_ram(DigicBoardState *s, hwaddr ram_size)
+{
+memory_region_init_ram(s-ram, NULL, ram, ram_size);
+memory_region_add_subregion(get_system_memory(), 0, s-ram);
+vmstate_register_ram_global(s-ram);
+}
+
+static void digic4_board_init(DigicBoard *board)
+{
+Error *err = NULL;
+
+DigicBoardState *s = g_new(DigicBoardState, 1);
+
+s-digic = DIGIC(object_new(TYPE_DIGIC));
+object_property_set_bool(OBJECT(s-digic), true, realized, err);
+if (err != NULL) {
+fprintf(stderr, Couldn't realize DIGIC SoC: %s\n,
+error_get_pretty(err));
+exit(1);
+}
+
+digic4_board_setup_ram(s, board-ram_size);
+
+s-digic-cpu.env.regs[15] = board-start_addr;
+}
+
+static DigicBoard digic4_board_canon_a1100 = {
+.ram_size = 64 * 1024 * 1024,
+/* CHDK recommends this address for ROM disassembly */
+.start_addr = 0xffc0,
+};
+
+static void canon_a1100_init(QEMUMachineInitArgs *args)
+{
+digic4_board_init(digic4_board_canon_a1100);
+}
+
+static QEMUMachine canon_a1100 = {
+.name = canon-a1100,
+.desc = Canon PowerShot A1100 IS,
+.init = canon_a1100_init,
+};
+
+static void digic_register_machines(void)
+{
+qemu_register_machine(canon_a1100);
+}
+
+machine_init(digic_register_machines)
--
1.8.4.rc3
[Qemu-devel] [PATCH v6 5/5] hw/arm/digic: add NOR ROM support
Signed-off-by: Antony Pavlov antonynpav...@gmail.com
---
hw/arm/digic_boards.c | 71 +++
1 file changed, 71 insertions(+)
diff --git a/hw/arm/digic_boards.c b/hw/arm/digic_boards.c
index 77cfc81..bf6e015 100644
--- a/hw/arm/digic_boards.c
+++ b/hw/arm/digic_boards.c
@@ -26,6 +26,13 @@
#include hw/boards.h
#include exec/address-spaces.h
#include hw/arm/digic.h
+#include hw/block/flash.h
+#include hw/loader.h
+#include sysemu/sysemu.h
+
+#define DIGIC4_ROM0_BASE 0xf000
+#define DIGIC4_ROM1_BASE 0xf800
+#define DIGIC4_ROM_MAX_SIZE 0x0800
typedef struct DigicBoardState {
DigicState *digic;
@@ -34,6 +41,10 @@ typedef struct DigicBoardState {
typedef struct DigicBoard {
hwaddr ram_size;
+void (*add_rom0)(DigicBoardState *, hwaddr, const char *);
+const char *rom0_def_filename;
+void (*add_rom1)(DigicBoardState *, hwaddr, const char *);
+const char *rom1_def_filename;
hwaddr start_addr;
} DigicBoard;
@@ -60,11 +71,71 @@ static void digic4_board_init(DigicBoard *board)
digic4_board_setup_ram(s, board-ram_size);
+if (board-add_rom0) {
+board-add_rom0(s, DIGIC4_ROM0_BASE, board-rom0_def_filename);
+}
+
+if (board-add_rom1) {
+board-add_rom1(s, DIGIC4_ROM1_BASE, board-rom1_def_filename);
+}
+
s-digic-cpu.env.regs[15] = board-start_addr;
}
+static void digic_load_rom(DigicBoardState *s, hwaddr addr,
+ hwaddr max_size, const char *def_filename)
+{
+
+target_long rom_size;
+const char *filename;
+
+if (bios_name) {
+filename = bios_name;
+} else {
+filename = def_filename;
+}
+
+if (filename) {
+char *fn = qemu_find_file(QEMU_FILE_TYPE_BIOS, filename);
+
+if (!fn) {
+fprintf(stderr, Couldn't find rom image '%s'.\n, filename);
+exit(1);
+}
+
+rom_size = load_image_targphys(fn, addr, max_size);
+if (rom_size 0 || rom_size max_size) {
+fprintf(stderr, Couldn't load rom image '%s'\n, filename);
+exit(1);
+}
+}
+}
+
+/*
+ * Samsung K8P3215UQB
+ * 64M Bit (4Mx16) Page Mode / Multi-Bank NOR Flash Memory
+ */
+static void digic4_add_k8p3215uqb_rom(DigicBoardState *s, hwaddr addr,
+ const char *def_filename)
+{
+#define FLASH_K8P3215UQB_SIZE (4 * 1024 * 1024)
+#define FLASH_K8P3215UQB_SECTOR_SIZE (64 * 1024)
+
+pflash_cfi02_register(addr, NULL, pflash, FLASH_K8P3215UQB_SIZE,
+ NULL, FLASH_K8P3215UQB_SECTOR_SIZE,
+ FLASH_K8P3215UQB_SIZE / FLASH_K8P3215UQB_SECTOR_SIZE,
+ DIGIC4_ROM_MAX_SIZE / FLASH_K8P3215UQB_SIZE,
+ 4,
+ 0x00EC, 0x007E, 0x0003, 0x0001,
+ 0x0555, 0x2aa, 0);
+
+digic_load_rom(s, addr, FLASH_K8P3215UQB_SIZE, def_filename);
+}
+
static DigicBoard digic4_board_canon_a1100 = {
.ram_size = 64 * 1024 * 1024,
+.add_rom1 = digic4_add_k8p3215uqb_rom,
+.rom1_def_filename = canon-a1100-rom1.bin,
/* CHDK recommends this address for ROM disassembly */
.start_addr = 0xffc0,
};
--
1.8.4.rc3
[Qemu-devel] [PATCH v6 3/5] hw/arm/digic: add timer support
Signed-off-by: Antony Pavlov antonynpav...@gmail.com
---
hw/arm/digic.c | 28 ++
hw/timer/Makefile.objs | 1 +
hw/timer/digic-timer.c | 140 +
hw/timer/digic-timer.h | 36 +
include/hw/arm/digic.h | 6 +++
5 files changed, 211 insertions(+)
create mode 100644 hw/timer/digic-timer.c
create mode 100644 hw/timer/digic-timer.h
diff --git a/hw/arm/digic.c b/hw/arm/digic.c
index 0d38872..4a8e67a 100644
--- a/hw/arm/digic.c
+++ b/hw/arm/digic.c
@@ -22,24 +22,52 @@
#include hw/arm/digic.h
+#define DIGIC4_TIMER_BASE(n)(0xc021 + (n) * 0x100)
+
static void digic_init(Object *obj)
{
DigicState *s = DIGIC(obj);
+DeviceState *dev;
+int i;
object_initialize(s-cpu, sizeof(s-cpu), arm946- TYPE_ARM_CPU);
object_property_add_child(obj, cpu, OBJECT(s-cpu), NULL);
+
+for (i = 0; i DIGIC4_NB_TIMERS; i++) {
+#define DIGIC_TIMER_NAME_MLEN11
+char name[DIGIC_TIMER_NAME_MLEN];
+
+object_initialize(s-timer[i], sizeof(s-timer[i]), TYPE_DIGIC_TIMER);
+dev = DEVICE(s-timer[i]);
+qdev_set_parent_bus(dev, sysbus_get_default());
+snprintf(name, DIGIC_TIMER_NAME_MLEN, timer[%d], i);
+object_property_add_child(obj, name, OBJECT(s-timer[i]), NULL);
+}
}
static void digic_realize(DeviceState *dev, Error **errp)
{
DigicState *s = DIGIC(dev);
Error *err = NULL;
+SysBusDevice *sbd;
+int i;
object_property_set_bool(OBJECT(s-cpu), true, realized, err);
if (err != NULL) {
error_propagate(errp, err);
return;
}
+
+for (i = 0; i DIGIC4_NB_TIMERS; i++) {
+object_property_set_bool(OBJECT(s-timer[i]), true, realized, err);
+if (err != NULL) {
+error_propagate(errp, err);
+return;
+}
+
+sbd = SYS_BUS_DEVICE(s-timer[i]);
+sysbus_mmio_map(sbd, 0, DIGIC4_TIMER_BASE(i));
+}
}
static void digic_class_init(ObjectClass *oc, void *data)
diff --git a/hw/timer/Makefile.objs b/hw/timer/Makefile.objs
index eca5905..5479aee 100644
--- a/hw/timer/Makefile.objs
+++ b/hw/timer/Makefile.objs
@@ -25,5 +25,6 @@ obj-$(CONFIG_OMAP) += omap_synctimer.o
obj-$(CONFIG_PXA2XX) += pxa2xx_timer.o
obj-$(CONFIG_SH4) += sh_timer.o
obj-$(CONFIG_TUSB6010) += tusb6010.o
+obj-$(CONFIG_DIGIC) += digic-timer.o
obj-$(CONFIG_MC146818RTC) += mc146818rtc.o
diff --git a/hw/timer/digic-timer.c b/hw/timer/digic-timer.c
new file mode 100644
index 000..974e588
--- /dev/null
+++ b/hw/timer/digic-timer.c
@@ -0,0 +1,140 @@
+/*
+ * QEMU model of the Canon DIGIC timer block.
+ *
+ * Copyright (C) 2013 Antony Pavlov antonynpav...@gmail.com
+ *
+ * This model is based on reverse engineering efforts
+ * made by CHDK (http://chdk.wikia.com) and
+ * Magic Lantern (http://www.magiclantern.fm) projects
+ * contributors.
+ *
+ * See Timer/Clock Module docs here:
+ * http://magiclantern.wikia.com/wiki/Register_Map
+ *
+ * The QEMU model of the OSTimer in PKUnity SoC by Guan Xuetao
+ * is used as a template.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include hw/sysbus.h
+#include hw/ptimer.h
+#include qemu/main-loop.h
+
+#include hw/timer/digic-timer.h
+
+#define DIGIC_TIMER_CONTROL 0x00
+#define DIGIC_TIMER_VALUE 0x0c
+
+static const VMStateDescription vmstate_digic_timer = {
+.name = digic.timer,
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.fields = (VMStateField[]) {
+VMSTATE_PTIMER(ptimer, DigicTimerState),
+VMSTATE_END_OF_LIST()
+}
+};
+
+static uint64_t digic_timer_read(void *opaque, hwaddr offset, unsigned size)
+{
+DigicTimerState *s = opaque;
+uint32_t ret = 0;
+
+switch (offset) {
+case DIGIC_TIMER_VALUE:
+ret = (uint32_t)ptimer_get_count(s-ptimer);
+ret = 0x;
+break;
+default:
+qemu_log_mask(LOG_UNIMP,
+ digic-timer: read access to unknown register 0x
+ TARGET_FMT_plx, offset);
+}
+
+return ret;
+}
+
+static void digic_timer_write(void *opaque, hwaddr offset,
+ uint64_t value, unsigned size)
+{
+DigicTimerState *s = opaque;
+
+/* FIXME: without documentation every write just starts timer */
+ptimer_set_limit(s-ptimer, 0x, 1);
+ptimer_run(s-ptimer, 1);
+}
+
+static const MemoryRegionOps digic_timer_ops = {
+.read = digic_timer_read,
+.write = digic_timer_write,
+
[Qemu-devel] [PATCH v6 4/5] hw/arm/digic: add UART support
Signed-off-by: Antony Pavlov antonynpav...@gmail.com
Reviewed-by: Peter Maydell peter.mayd...@linaro.org
---
hw/arm/digic.c | 16
hw/char/Makefile.objs | 1 +
hw/char/digic-uart.c | 195 +
hw/char/digic-uart.h | 45
include/hw/arm/digic.h | 2 +
5 files changed, 259 insertions(+)
create mode 100644 hw/char/digic-uart.c
create mode 100644 hw/char/digic-uart.h
diff --git a/hw/arm/digic.c b/hw/arm/digic.c
index 4a8e67a..f2c7a8f 100644
--- a/hw/arm/digic.c
+++ b/hw/arm/digic.c
@@ -24,6 +24,8 @@
#define DIGIC4_TIMER_BASE(n)(0xc021 + (n) * 0x100)
+#define DIGIC_UART_BASE 0xc080
+
static void digic_init(Object *obj)
{
DigicState *s = DIGIC(obj);
@@ -43,6 +45,11 @@ static void digic_init(Object *obj)
snprintf(name, DIGIC_TIMER_NAME_MLEN, timer[%d], i);
object_property_add_child(obj, name, OBJECT(s-timer[i]), NULL);
}
+
+object_initialize(s-uart, sizeof(s-uart), TYPE_DIGIC_UART);
+dev = DEVICE(s-uart);
+qdev_set_parent_bus(dev, sysbus_get_default());
+object_property_add_child(obj, uart, OBJECT(s-uart), NULL);
}
static void digic_realize(DeviceState *dev, Error **errp)
@@ -68,6 +75,15 @@ static void digic_realize(DeviceState *dev, Error **errp)
sbd = SYS_BUS_DEVICE(s-timer[i]);
sysbus_mmio_map(sbd, 0, DIGIC4_TIMER_BASE(i));
}
+
+object_property_set_bool(OBJECT(s-uart), true, realized, err);
+if (err != NULL) {
+error_propagate(errp, err);
+return;
+}
+
+sbd = SYS_BUS_DEVICE(s-uart);
+sysbus_mmio_map(sbd, 0, DIGIC_UART_BASE);
}
static void digic_class_init(ObjectClass *oc, void *data)
diff --git a/hw/char/Makefile.objs b/hw/char/Makefile.objs
index cbd6a00..be2a7d9 100644
--- a/hw/char/Makefile.objs
+++ b/hw/char/Makefile.objs
@@ -14,6 +14,7 @@ obj-$(CONFIG_COLDFIRE) += mcf_uart.o
obj-$(CONFIG_OMAP) += omap_uart.o
obj-$(CONFIG_SH4) += sh_serial.o
obj-$(CONFIG_PSERIES) += spapr_vty.o
+obj-$(CONFIG_DIGIC) += digic-uart.o
common-obj-$(CONFIG_ETRAXFS) += etraxfs_ser.o
common-obj-$(CONFIG_ISA_DEBUG) += debugcon.o
diff --git a/hw/char/digic-uart.c b/hw/char/digic-uart.c
new file mode 100644
index 000..fd8e077
--- /dev/null
+++ b/hw/char/digic-uart.c
@@ -0,0 +1,195 @@
+/*
+ * QEMU model of the Canon DIGIC UART block.
+ *
+ * Copyright (C) 2013 Antony Pavlov antonynpav...@gmail.com
+ *
+ * This model is based on reverse engineering efforts
+ * made by CHDK (http://chdk.wikia.com) and
+ * Magic Lantern (http://www.magiclantern.fm) projects
+ * contributors.
+ *
+ * See Serial terminal docs here:
+ * http://magiclantern.wikia.com/wiki/Register_Map#Misc_Registers
+ *
+ * The QEMU model of the Milkymist UART block by Michael Walle
+ * is used as a template.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include hw/hw.h
+#include hw/sysbus.h
+#include sysemu/char.h
+
+#include hw/char/digic-uart.h
+
+enum {
+ST_RX_RDY = (1 0),
+ST_TX_RDY = (1 1),
+};
+
+static uint64_t digic_uart_read(void *opaque, hwaddr addr,
+unsigned size)
+{
+DigicUartState *s = opaque;
+uint64_t ret = 0;
+
+addr = 2;
+
+switch (addr) {
+case R_RX:
+s-reg_st = ~(ST_RX_RDY);
+ret = s-reg_rx;
+break;
+
+case R_ST:
+ret = s-reg_st;
+break;
+
+default:
+qemu_log_mask(LOG_UNIMP,
+ digic-uart: read access to unknown register 0x
+ TARGET_FMT_plx, addr 2);
+}
+
+return ret;
+}
+
+static void digic_uart_write(void *opaque, hwaddr addr, uint64_t value,
+ unsigned size)
+{
+DigicUartState *s = opaque;
+unsigned char ch = value;
+
+addr = 2;
+
+switch (addr) {
+case R_TX:
+if (s-chr) {
+qemu_chr_fe_write_all(s-chr, ch, 1);
+}
+break;
+
+case R_ST:
+/*
+ * Ignore write to R_ST.
+ *
+ * The point is that this register is actively used
+ * during receiving and transmitting symbols,
+ * but we don't know the function of most of bits.
+ *
+ * Ignoring writes to R_ST is only a simplification
+ * of the model. It has no perceptible side effects
+ * for existing guests.
+ */
+break;
+
+default:
+qemu_log_mask(LOG_UNIMP,
+ digic-uart: write access to unknown register 0x
+
Re: [Qemu-devel] [PATCH 04/16] slirp: Adding IPv6, ICMPv6 Echo and NDP autoconfiguration
Paolo Bonzini, le Wed 23 Oct 2013 08:51:21 +0100, a écrit :
+void icmp6_init(Slirp *slirp)
+{
+srand(time(NULL));
+ra_timer = timer_new_s(QEMU_CLOCK_VIRTUAL, ra_timer_handler, slirp);
+timer_mod(ra_timer, qemu_clock_get_s(QEMU_CLOCK_VIRTUAL) +
NDP_Interval);
+}
Should the granularity of the timer really be seconds? Or should you
use the existing milli/nanosecond interface and scale the interval, so
that you really get a uniformly distributed random value, even for very
small MaxRtrAdvInterval (e.g. for min=3, max=4 you won't get any other
value than 3 or 4, which is not really uniformly distributed).
I don't think we need to care about fine granularity. We are not going
to run more than one RA anyway.
Actually, the RFC itself says that when the max value is less than 9,
the default for the min value would be equal to the max value, i.e. the
delay being always just the same.
Samuel
[Qemu-devel] [Bug 1243639] Re: qemu-1.5.3 segment fault with -vga qxl
sorry to mistake The truth is that t will NOT run into segment fault with /dev/sda but without -vga qxl The qemu the Host linux OS is iinstalled on /dev/sda -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1243639 Title: qemu-1.5.3 segment fault with -vga qxl Status in QEMU: New Bug description: execute qemu-system-x86_64-enable-kvm -machine accel=kvm:tcg -m 1G -drive file=/dev/sda --full-screen -spice addr=127.0.0.1,port=5900,disable-ticketing -vga qxl on shell will get segment fault after a few seconds if I don't connect to it with spicec client immediately. IF excute spicec -h 127.0.0.1 -p 5900 immediately after the qemu-system-x86_64 execution, then no segment fault happens and it runs well. = GDB output: root@kali-john:~# gdb /usr/local/bin/qemu-system-x86_64 GNU gdb (GDB) 7.4.1-debian (gdb) run -enable-kvm -machine accel=kvm:tcg -m 1G -drive file=/dev/sda --full-screen -spice addr=127.0.0.1,port=5900,disable-ticketing -vga qxl [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. [New Thread 0x73737700 (LWP 14797)] [New Thread 0x72d54700 (LWP 14798)] [New Thread 0x70fff700 (LWP 14799)] Program received signal SIGSEGV, Segmentation fault. 0x7683ad70 in pixman_image_get_data () from /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (gdb) bt #0 0x7683ad70 in pixman_image_get_data () from /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 #1 0x5581060a in surface_data (s=0x566183a0) at /zh-download/QEMU/qemu-1.5.3/include/ui/console.h:235 #2 0x55818616 in vga_draw_graphic (s=0x5662c778, full_update=1) at /zh-download/QEMU/qemu-1.5.3/hw/display/vga.c:1788 #3 0x55818c6a in vga_update_display (opaque=0x5662c778) at /zh-download/QEMU/qemu-1.5.3/hw/display/vga.c:1917 #4 0x5580eb15 in qxl_hw_update (opaque=0x5662bd70) at /zh-download/QEMU/qemu-1.5.3/hw/display/qxl.c:1766 #5 0x557bd6bc in graphic_hw_update (con=0x56618d00) at ui/console.c:254 #6 0x557c8426 in qemu_spice_display_refresh (ssd=0x5662c418) at ui/spice-display.c:417 #7 0x5580eff0 in display_refresh (dcl=0x5662c420) at /zh-download/QEMU/qemu-1.5.3/hw/display/qxl.c:1886 #8 0x557c0cb1 in dpy_refresh (s=0x56618370) at ui/console.c:1436 #9 0x557bd3af in gui_update (opaque=0x56618370) at ui/console.c:192 #10 0x55797f20 in qemu_run_timers (clock=0x565b5a30) at qemu-timer.c:394 #11 0x55798183 in qemu_run_all_timers () at qemu-timer.c:453 #12 0x55760bb7 in main_loop_wait (nonblocking=0) at main-loop.c:470 #13 0x557cd19c in main_loop () at vl.c:2029 #14 0x557d43f2 in main (argc=13, argv=0x7fffe2b8, envp=0x7fffe328) at vl.c:4419 (gdb) == http://www.spice-space.org/download/releases/spice-0.12.4.tar.bz2 http://www.spice-space.org/download/releases/spice-protocol-0.12.6.tar.bz2 spice compiling ./configure --enable-smartcard=nomake qemu-1.5.3 compiling ./configure \ --disable-strip --enable-debug \ --target-list=x86_64-softmmu,x86_64-linux-user \ --disable-sdl --audio-drv-list=alsa --disable-vnc --disable-xen --disable-libiscsi \ --disable-seccomp --disable-glusterfs --disable-libssh2 --disable-smartcard-nss \ --disable-usb-redir --disable-brlapi --disable-curl --disable-bsd-user \ \ --enable-kvm --enable-spice --enable-system --enable-guest-agent --enable-vhost-net root@kali-john:~# qemu-system-x86_64 -version QEMU emulator version 1.5.3, Copyright (c) 2003-2008 Fabrice Bellard To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1243639/+subscriptions
Re: [Qemu-devel] [PATCH 01/18] bsd-user: refresh freebsd system call numbers
On 16 October 2013 10:36, Stacey Son s...@freebsd.org wrote: Update FreeBSD system call numbers in freebsd/syscall_nr.h. Signed-off-by: Stacey Son s...@freebsd.org Reviewed-by: Ed Maste ema...@freebsd.org
[Qemu-devel] [Bug 1243639] Re: qemu-1.5.3 segment fault with -vga qxl
It will run into segment fault with /dev/sda but without -vga qxl The qemuthe Host linux OS is iinstalled on /dev/sda -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1243639 Title: qemu-1.5.3 segment fault with -vga qxl Status in QEMU: New Bug description: execute qemu-system-x86_64-enable-kvm -machine accel=kvm:tcg -m 1G -drive file=/dev/sda --full-screen -spice addr=127.0.0.1,port=5900,disable-ticketing -vga qxl on shell will get segment fault after a few seconds if I don't connect to it with spicec client immediately. IF excute spicec -h 127.0.0.1 -p 5900 immediately after the qemu-system-x86_64 execution, then no segment fault happens and it runs well. = GDB output: root@kali-john:~# gdb /usr/local/bin/qemu-system-x86_64 GNU gdb (GDB) 7.4.1-debian (gdb) run -enable-kvm -machine accel=kvm:tcg -m 1G -drive file=/dev/sda --full-screen -spice addr=127.0.0.1,port=5900,disable-ticketing -vga qxl [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. [New Thread 0x73737700 (LWP 14797)] [New Thread 0x72d54700 (LWP 14798)] [New Thread 0x70fff700 (LWP 14799)] Program received signal SIGSEGV, Segmentation fault. 0x7683ad70 in pixman_image_get_data () from /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (gdb) bt #0 0x7683ad70 in pixman_image_get_data () from /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 #1 0x5581060a in surface_data (s=0x566183a0) at /zh-download/QEMU/qemu-1.5.3/include/ui/console.h:235 #2 0x55818616 in vga_draw_graphic (s=0x5662c778, full_update=1) at /zh-download/QEMU/qemu-1.5.3/hw/display/vga.c:1788 #3 0x55818c6a in vga_update_display (opaque=0x5662c778) at /zh-download/QEMU/qemu-1.5.3/hw/display/vga.c:1917 #4 0x5580eb15 in qxl_hw_update (opaque=0x5662bd70) at /zh-download/QEMU/qemu-1.5.3/hw/display/qxl.c:1766 #5 0x557bd6bc in graphic_hw_update (con=0x56618d00) at ui/console.c:254 #6 0x557c8426 in qemu_spice_display_refresh (ssd=0x5662c418) at ui/spice-display.c:417 #7 0x5580eff0 in display_refresh (dcl=0x5662c420) at /zh-download/QEMU/qemu-1.5.3/hw/display/qxl.c:1886 #8 0x557c0cb1 in dpy_refresh (s=0x56618370) at ui/console.c:1436 #9 0x557bd3af in gui_update (opaque=0x56618370) at ui/console.c:192 #10 0x55797f20 in qemu_run_timers (clock=0x565b5a30) at qemu-timer.c:394 #11 0x55798183 in qemu_run_all_timers () at qemu-timer.c:453 #12 0x55760bb7 in main_loop_wait (nonblocking=0) at main-loop.c:470 #13 0x557cd19c in main_loop () at vl.c:2029 #14 0x557d43f2 in main (argc=13, argv=0x7fffe2b8, envp=0x7fffe328) at vl.c:4419 (gdb) == http://www.spice-space.org/download/releases/spice-0.12.4.tar.bz2 http://www.spice-space.org/download/releases/spice-protocol-0.12.6.tar.bz2 spice compiling ./configure --enable-smartcard=nomake qemu-1.5.3 compiling ./configure \ --disable-strip --enable-debug \ --target-list=x86_64-softmmu,x86_64-linux-user \ --disable-sdl --audio-drv-list=alsa --disable-vnc --disable-xen --disable-libiscsi \ --disable-seccomp --disable-glusterfs --disable-libssh2 --disable-smartcard-nss \ --disable-usb-redir --disable-brlapi --disable-curl --disable-bsd-user \ \ --enable-kvm --enable-spice --enable-system --enable-guest-agent --enable-vhost-net root@kali-john:~# qemu-system-x86_64 -version QEMU emulator version 1.5.3, Copyright (c) 2003-2008 Fabrice Bellard To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1243639/+subscriptions
Re: [Qemu-devel] pvpanic plans?
Hi All, I know it's been a long time since this thread. But qemu 1.7 is releasing, do you have any consensus on this? Thanks.
[Qemu-devel] About the host page cache inside the qemu
Hi all, I read the slides An Update Overview of the QEMU Storage Stack, which indicate that if caching mode=none, the host page cache is off and guest disk write cache is on. My question is where the implementation is inside the qemu. How to control the io to a virtual disk image( a raw disk on top of the ext4 in the host filesysytem) My understanding is the ios from qemu are sent to the host linux system call, the virtual disk is basically a normal file in the host filesystem, how the qemu can perform the ios to this file bypassing the host page cache. Thanks a lot! Yaodong
[Qemu-devel] [PATCH] vnc: Fix qemu crash on vnc client disconnection
Hi, I encount a qemu crash when the vnc client disconnection, and I got the next log: qemu: qemu_mutex_lock: Invalid argument and the backtrace listed: Core was generated by `/mnt/sdd/gonglei/kvm/qemu-unstable/x86_64-softmmu/qemu-system-x86_64 -name suse'. Program terminated with signal 6, Aborted. #0 0x7fab8498ed95 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x7fab8498ed95 in raise () from /lib64/libc.so.6 #1 0x7fab849902ab in abort () from /lib64/libc.so.6 #2 0x7fab87c22915 in error_exit (err=22, msg=0x7fab87c97a70 __func__.4762 qemu_mutex_lock) at util/qemu-thread-posix.c:28 #3 0x7fab87c22a19 in qemu_mutex_lock (mutex=0x7fab8858e688) at util/qemu-thread-posix.c:59 #4 0x7fab87ae52ea in vnc_lock_output (vs=0x7fab885823f0) at ui/vnc-jobs.h:63 #5 0x7fab87ae5217 in vnc_jobs_consume_buffer (vs=0x7fab885823f0) at ui/vnc-jobs.c:166 #6 0x7fab87ae51dd in vnc_jobs_join (vs=0x7fab885823f0) at ui/vnc-jobs.c:159 #7 0x7fab87aea776 in vnc_update_client_sync (vs=0x7fab885823f0, has_dirty=1) at ui/vnc.c:880 #8 0x7fab87aea007 in vnc_dpy_copy (dcl=0x7fab8088f048, src_x=746, src_y=578, dst_x=772, dst_y=578, w=22, h=22) at ui/vnc.c:753 #9 0x7fab87ac8df6 in dpy_gfx_copy (con=0x7fab885cdb40, src_x=746, src_y=578, dst_x=772, dst_y=578, w=22, h=22) at ui/console.c:1455 #10 0x7fab87ac9fd7 in qemu_console_copy (con=0x7fab885cdb40, src_x=746, src_y=578, dst_x=772, dst_y=578, w=22, h=22) at ui/console.c:1837 #11 0x7fab8799bd91 in cirrus_do_copy (s=0x7fab885ff450, dst=1228339, src=1228287, w=22, h=22) at hw/display/cirrus_vga.c:738 #12 0x7fab8799bf03 in cirrus_bitblt_videotovideo_copy (s=0x7fab885ff450) at hw/display/cirrus_vga.c:757 #13 0x7fab8799c48c in cirrus_bitblt_videotovideo (s=0x7fab885ff450) at hw/display/cirrus_vga.c:879 #14 0x7fab8799cc00 in cirrus_bitblt_start (s=0x7fab885ff450) at hw/display/cirrus_vga.c:1020 #15 0x7fab8799cfbb in cirrus_write_bitblt (s=0x7fab885ff450, reg_value=2) at hw/display/cirrus_vga.c:1041 #16 0x7fab8799dedb in cirrus_vga_write_gr (s=0x7fab885ff450, reg_index=49, reg_value=2) at hw/display/cirrus_vga.c:1536 #17 0x7fab8799e721 in cirrus_mmio_blt_write (s=0x7fab885ff450, address=64, value=2 '\002') at hw/display/cirrus_vga.c:1890 #18 0x7fab879a068d in cirrus_mmio_write (opaque=0x7fab885ff450, addr=320, val=2, size=1) at hw/display/cirrus_vga.c:2670 #19 0x7fab87b77921 in memory_region_write_accessor (mr=0x7fab8860fe90, addr=320, value=0x7fab818d5cc8, size=1, shift=0, mask= 255) at /mnt/sdd/gonglei/kvm/qemu-unstable/memory.c:440 #20 0x7fab87b77a5d in access_with_adjusted_size (addr=320, value=0x7fab818d5cc8, size=4, access_size_min=1, access_size_max=1, access=0x7fab87b77898 memory_region_write_accessor, mr=0x7fab8860fe90) at /mnt/sdd/gonglei/kvm/qemu-unstable/memory.c:477 #21 0x7fab87b7a8c0 in memory_region_dispatch_write (mr=0x7fab8860fe90, addr=320, data=18446744073709551362, size=4) at /mnt/sdd/gonglei/kvm/qemu-unstable/memory.c:984 #22 0x7fab87b7e176 in io_mem_write (mr=0x7fab8860fe90, addr=320, val=18446744073709551362, size=4) at /mnt/sdd/gonglei/kvm/qemu-unstable/memory.c:1748 #23 0x7fab87b0e91e in address_space_rw (as=0x7fab8848b960 address_space_memory, addr=4273832256, buf= 0x7fab87830028 Address 0x7fab87830028 out of bounds, len=4, is_write=true) at /mnt/sdd/gonglei/kvm/qemu-unstable/exec.c:1963 #24 0x7fab87b0eec0 in cpu_physical_memory_rw (addr=4273832256, buf=0x7fab87830028 Address 0x7fab87830028 out of bounds, len= 4, is_write=1) at /mnt/sdd/gonglei/kvm/qemu-unstable/exec.c:2042 #25 0x7fab87b74b47 in kvm_cpu_exec (cpu=0x7fab88520c20) at /mnt/sdd/gonglei/kvm/qemu-unstable/kvm-all.c:1673 #26 0x7fab87b022e9 in qemu_kvm_cpu_thread_fn (arg=0x7fab88520c20) at /mnt/sdd/gonglei/kvm/qemu-unstable/cpus.c:785 #27 0x7fab85b07f05 in start_thread () from /lib64/libpthread.so.0 #28 0x7fab84a3353d in clone () from /lib64/libc.so.6 When Vnc client was disconnected, the vs-csock will be set to -1 in function vnc_disconnect_start. And on the next loop, in case of the function transfer: vnc_dpy_copy--vnc_update_client_sync--vnc_update_client--vnc_disconnect_finish(vs) and vnc_dpy_copy--vnc_update_client_sync-- vnc_jobs_consume_buffer--vnc_lock_output(vs)-- qemu_mutex_lock(vs-output_mutex); because the vs has been freed, the qemu_mutex_lock(vs-output_mutex) will cause qemu abort. The patch fixed the bug: when the vs object be freed, function vnc_update_client return -1, and vnc_update_client_sync do not deal with the situation avoid that qemu abort. Signed-off-by: Gonglei arei.gong...@huawei.com --- ui/vnc.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/ui/vnc.c b/ui/vnc.c index 5601cc3..2177704 100644 --- a/ui/vnc.c +++ b/ui/vnc.c @@ -876,7 +876,8 @@ static int find_and_clear_dirty_height(struct VncState *vs, static int vnc_update_client_sync(VncState *vs, int
Re: [Qemu-devel] [Qemu-discuss] About the host page cache inside the qemu
On Thu, Oct 24, 2013 at 11:36 AM, Yaodong Yang yaodong.ya...@icloud.comwrote:
Hi all,
I read the slides An Update Overview of the QEMU Storage Stack, which
indicate that if caching mode=none, the host page cache is off and guest
disk write cache is on. My question is where the implementation is inside
the qemu. How to control the io to a virtual disk image( a raw disk on top
of the ext4 in the host filesysytem)
My understanding is the ios from qemu are sent to the host linux system
call, the virtual disk is basically a normal file in the host filesystem,
how the qemu can perform the ios to this file bypassing the host page cache.
From the file block/raw-posix.c
static void raw_parse_flags(int bdrv_flags, int *open_flags)
{
/* Use O_DSYNC for write-through caching, no flags for write-back
caching,
* and O_DIRECT for no caching. */
if ((bdrv_flags BDRV_O_NOCACHE)) {
*open_flags |= O_DIRECT;
}
}
You can take a look at manpage for open, which says:
O_DIRECT (Since Linux 2.4.10)
Try to minimize cache effects of the I/O to and from this file.
In general this will degrade performance, but it is useful in special
situations, such as
when applications do their own caching. File I/O is done
directly to/from user space buffers. The I/O is synchronous, that is, at
the completion of a
read(2) or write(2), data is guaranteed to have been transferred.
See NOTES below for further discussion.
A semantically similar (but deprecated) interface for block
devices is described in raw(8).
Thanks a lot!
Yaodong
--
Best Regards,
Dunrong Huang
Homepage: http://mathslinux.org
