Re: [Qemu-devel] [PATCH] `qdev_free` when unplug a pci device
At 03/01/2011 03:13 PM, Isaku Yamahata Write: > On Tue, Mar 01, 2011 at 02:58:44PM +0800, Wen Congyang wrote: >> At 03/01/2011 12:11 PM, Isaku Yamahata Write: >>> Hi. >>> >>> I don't suppose that just introducing pending bits solve the issue. >>> Your test only use single hot plug/unplug. How about mixing of multiple >>> hot plug/unplug with different slots. >> >> The qemu uses the same thread to deal with monitor command and I/O request >> from guest OS. So I think mixing of multiple hot plug/unplug with different >> slots can also work fine. >> >>> Zeroing up/down on piix4_device_hotplug() is the culprit. >>> >>> State machine of (up, down) would be needed. >>> (up, down) of each slots should be changed following >>> something like >> >> Why we need this feature? We access s->pci0_status only in main thread and >> do not accesss it when we deal with signal, so there is no competition to >> access it. > > We are talking about losing interrupt and events, aren't we? > Not race caused by threads. I am sorry, I do not understand what you are talk about. > The issue is, Qemu injected sci interrupt into guest, > but before the guest completes to handled it, > users/qemu can start to inject the next sci event triggered by hot > plug/unplug. > Thus qemu loses sci interrupt and up/down status. Yes, you are right. But I still do not understand why introducing pending bits can not solve the issue? Thanks Wen Congyang > > thanks >> >>> >>> - on power-on (0, 0) >>> - on hot plug (0, 0) -> (1, 0) >>>if other combination -> error >>> - on hot unpug (1, 0) or (0, 0) -> (0, 1) >>>(0, 0) is for cold plugged devices. >>>(1, 0) is for hot plugged devices. >>>if other combination -> error >>> - on pciej_write(write on PCI_EJ_BASE) >>>(0, 1) -> (0, 0) and qdev_free() >>>if other combination -> ignore >>> >>> When enabling sci, those bits are checked and raise sci if necessary. >>> >>> Any comments on this? >>> Anyway the current pci hotplug-related commands are somewhat broken, >>> and needs clean up with multifunction hotplug support which is >>> on my todo list. >>> >>> thanks >>> >>> On Mon, Feb 28, 2011 at 10:52:40AM +0800, Wen Congyang wrote: Hi Markus Armbruster At 02/23/2011 04:30 PM, Markus Armbruster Write: > Isaku Yamahata writes: > > > I don't think this patch is correct. Let me explain. > > Device hot unplug is *not* guaranteed to succeed. > > For some buses, such as USB, it always succeeds immediately, i.e. when > the device_del monitor command finishes, the device is gone. Live is > good. > > But for PCI, device_del merely initiates the ACPI unplug rain dance. It > doesn't wait for the dance to complete. Why? The dance can take an > unpredictable amount of time, including forever. > > Problem: Subsequent device_add can fail if it reuses the qdev ID or PCI > slot, and the unplug has not yet completed (race condition), or it > failed. Yes, Virginia, PCI hotplug *can* fail. > > When unplug succeeds, the qdev is automatically destroyed. > pciej_write() does that for PIIX4. Looks like pcie_cap_slot_event() > does it for PCIE. I got a similar problem. When I unplug a pci device by hand, it works as expected, and I can hotplug it again. But when I use a srcipt to do the same thing, sometimes it failed. I think I may find another bug. Steps to reproduce this bug: 1. cat ./test-e1000.sh # RHEL6RC is domain name #! /bin/bash while true; do virsh attach-interface RHEL6RC network default --mac 52:54:00:1f:db:c7 --model e1000 if [[ $? -ne 0 ]]; then break fi virsh detach-interface RHEL6RC network --mac 52:54:00:1f:db:c7 if [[ $? -ne 0 ]]; then break fi sleep 5 done 2. ./test-e1000.sh Interface attached successfully Interface detached successfully Interface attached successfully Interface detached successfully error: Failed to attach interface error: operation failed: adding e1000,netdev=hostnet1,id=net1,mac=52:54:00:1f:db:c7,bus=pci.0,addr=0x8 device failed: Duplicate ID 'net1' for device I use ftrace to trace whether sci interrupt is passed to guest OS, here is log: # cat trace | grep 'irq=9' -0 [000] 118342.634772: irq_handler_entry: irq=9 name=acpi -0 [000] 118342.634831: irq_handler_exit: irq=9 ret=handled -0 [000] 118342.693216: irq_handler_entry: irq=9 name=acpi -0 [000] 118342.693254: irq_handler_exit: irq=9 ret=handled -0 [000] 118
[Qemu-devel] RE: Printed Roll-up Banners USD7 Only (GIGAPrint Overseas)
Dear He? Justus GIGAPrint Ltd. | 11/F, Fu Hop Fty Bldg, 209-211 Wai Yip St, Kwun Tong, Kowloon, HK | 23892088 您收到這郵件是由於我們相信其中的訊息與您相關。如欲取消接收所有關於本機構的產品或服務的訊息請按 http://vps.web-123.com/webm/tracer/u.php?g=8447.532556.690247798 You are receiving this message because we believed that it is relevant to you. If you do not wish to receive any materials regarding our products or services from us, please click http://vps.web-123.com/webm/tracer/u.php?g=8447.532556.690247798
Re: [Qemu-devel] [PATCH] `qdev_free` when unplug a pci device
On Tue, Mar 01, 2011 at 02:58:44PM +0800, Wen Congyang wrote: > At 03/01/2011 12:11 PM, Isaku Yamahata Write: > > Hi. > > > > I don't suppose that just introducing pending bits solve the issue. > > Your test only use single hot plug/unplug. How about mixing of multiple > > hot plug/unplug with different slots. > > The qemu uses the same thread to deal with monitor command and I/O request > from guest OS. So I think mixing of multiple hot plug/unplug with different > slots can also work fine. > > > Zeroing up/down on piix4_device_hotplug() is the culprit. > > > > State machine of (up, down) would be needed. > > (up, down) of each slots should be changed following > > something like > > Why we need this feature? We access s->pci0_status only in main thread and > do not accesss it when we deal with signal, so there is no competition to > access it. We are talking about losing interrupt and events, aren't we? Not race caused by threads. The issue is, Qemu injected sci interrupt into guest, but before the guest completes to handled it, users/qemu can start to inject the next sci event triggered by hot plug/unplug. Thus qemu loses sci interrupt and up/down status. thanks > > > > > - on power-on (0, 0) > > - on hot plug (0, 0) -> (1, 0) > >if other combination -> error > > - on hot unpug (1, 0) or (0, 0) -> (0, 1) > >(0, 0) is for cold plugged devices. > >(1, 0) is for hot plugged devices. > >if other combination -> error > > - on pciej_write(write on PCI_EJ_BASE) > >(0, 1) -> (0, 0) and qdev_free() > >if other combination -> ignore > > > > When enabling sci, those bits are checked and raise sci if necessary. > > > > Any comments on this? > > Anyway the current pci hotplug-related commands are somewhat broken, > > and needs clean up with multifunction hotplug support which is > > on my todo list. > > > > thanks > > > > On Mon, Feb 28, 2011 at 10:52:40AM +0800, Wen Congyang wrote: > >> Hi Markus Armbruster > >> > >> At 02/23/2011 04:30 PM, Markus Armbruster Write: > >>> Isaku Yamahata writes: > >>> > >> > >> > >> > >>> > >>> I don't think this patch is correct. Let me explain. > >>> > >>> Device hot unplug is *not* guaranteed to succeed. > >>> > >>> For some buses, such as USB, it always succeeds immediately, i.e. when > >>> the device_del monitor command finishes, the device is gone. Live is > >>> good. > >>> > >>> But for PCI, device_del merely initiates the ACPI unplug rain dance. It > >>> doesn't wait for the dance to complete. Why? The dance can take an > >>> unpredictable amount of time, including forever. > >>> > >>> Problem: Subsequent device_add can fail if it reuses the qdev ID or PCI > >>> slot, and the unplug has not yet completed (race condition), or it > >>> failed. Yes, Virginia, PCI hotplug *can* fail. > >>> > >>> When unplug succeeds, the qdev is automatically destroyed. > >>> pciej_write() does that for PIIX4. Looks like pcie_cap_slot_event() > >>> does it for PCIE. > >> > >> I got a similar problem. When I unplug a pci device by hand, it works > >> as expected, and I can hotplug it again. But when I use a srcipt to > >> do the same thing, sometimes it failed. I think I may find another bug. > >> > >> Steps to reproduce this bug: > >> 1. cat ./test-e1000.sh # RHEL6RC is domain name > >>#! /bin/bash > >> > >>while true; do > >>virsh attach-interface RHEL6RC network default --mac > >> 52:54:00:1f:db:c7 --model e1000 > >>if [[ $? -ne 0 ]]; then > >>break > >>fi > >>virsh detach-interface RHEL6RC network --mac 52:54:00:1f:db:c7 > >>if [[ $? -ne 0 ]]; then > >>break > >>fi > >>sleep 5 > >>done > >> > >> 2. ./test-e1000.sh > >>Interface attached successfully > >> > >>Interface detached successfully > >> > >>Interface attached successfully > >> > >>Interface detached successfully > >> > >>error: Failed to attach interface > >>error: operation failed: adding > >> e1000,netdev=hostnet1,id=net1,mac=52:54:00:1f:db:c7,bus=pci.0,addr=0x8 > >> device failed: Duplicate ID 'net1' for device > >> > >> > >> I use ftrace to trace whether sci interrupt is passed to guest OS, here is > >> log: > >> # cat trace | grep 'irq=9' > >> -0 [000] 118342.634772: irq_handler_entry: irq=9 > >> name=acpi > >> -0 [000] 118342.634831: irq_handler_exit: irq=9 > >> ret=handled > >> -0 [000] 118342.693216: irq_handler_entry: irq=9 > >> name=acpi > >> -0 [000] 118342.693254: irq_handler_exit: irq=9 > >> ret=handled > >> -0 [000] 118347.737689: irq_handler_entry: irq=9 > >> name=acpi > >> -0 [000] 118347.737738: irq_handler_exit: irq=9 > >> ret=handled > >> According to the log, we only receive 3 sci interrupt, and one is lost. > >> > >> I enable piix4's debug and 1 l
[Qemu-devel] [PATCH v2] migration: allow setting MIG_STATE_CANCEL even if s->state != MIG_STATE_ACTIVE.
After migration failure, even a user commands migrate_cancel, it keeps
saying:
Migration status: failed
This patch checks s->state == MIG_STATE_CANCEL instead of s->state !=
MIG_STATE_ACTIVE. With this patch the message above would be:
Migration status: cancelled
Please note that the following patches are prerequisite.
http://www.mail-archive.com/qemu-devel@nongnu.org/msg56448.html
http://www.mail-archive.com/qemu-devel@nongnu.org/msg56446.html
Signed-off-by: Yoshiaki Tamura
---
migration.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/migration.c b/migration.c
index 14a125f..0e551e2 100644
--- a/migration.c
+++ b/migration.c
@@ -406,16 +406,19 @@ void migrate_fd_cancel(MigrationState *mig_state)
{
FdMigrationState *s = migrate_to_fms(mig_state);
-if (s->state != MIG_STATE_ACTIVE)
+if (s->state == MIG_STATE_CANCELLED) {
return;
+}
DPRINTF("cancelling migration\n");
s->state = MIG_STATE_CANCELLED;
notifier_list_notify(&migration_state_notifiers);
-qemu_savevm_state_cancel(s->mon, s->file);
-migrate_fd_cleanup(s);
+if (s->file) {
+qemu_savevm_state_cancel(s->mon, s->file);
+migrate_fd_cleanup(s);
+}
}
void migrate_fd_release(MigrationState *mig_state)
--
1.7.1.2
Re: [Qemu-devel] [PATCH] `qdev_free` when unplug a pci device
At 03/01/2011 12:11 PM, Isaku Yamahata Write:
> Hi.
>
> I don't suppose that just introducing pending bits solve the issue.
> Your test only use single hot plug/unplug. How about mixing of multiple
> hot plug/unplug with different slots.
The qemu uses the same thread to deal with monitor command and I/O request
from guest OS. So I think mixing of multiple hot plug/unplug with different
slots can also work fine.
> Zeroing up/down on piix4_device_hotplug() is the culprit.
>
> State machine of (up, down) would be needed.
> (up, down) of each slots should be changed following
> something like
Why we need this feature? We access s->pci0_status only in main thread and
do not accesss it when we deal with signal, so there is no competition to
access it.
>
> - on power-on (0, 0)
> - on hot plug (0, 0) -> (1, 0)
>if other combination -> error
> - on hot unpug (1, 0) or (0, 0) -> (0, 1)
>(0, 0) is for cold plugged devices.
>(1, 0) is for hot plugged devices.
>if other combination -> error
> - on pciej_write(write on PCI_EJ_BASE)
>(0, 1) -> (0, 0) and qdev_free()
>if other combination -> ignore
>
> When enabling sci, those bits are checked and raise sci if necessary.
>
> Any comments on this?
> Anyway the current pci hotplug-related commands are somewhat broken,
> and needs clean up with multifunction hotplug support which is
> on my todo list.
>
> thanks
>
> On Mon, Feb 28, 2011 at 10:52:40AM +0800, Wen Congyang wrote:
>> Hi Markus Armbruster
>>
>> At 02/23/2011 04:30 PM, Markus Armbruster Write:
>>> Isaku Yamahata writes:
>>>
>>
>>
>>
>>>
>>> I don't think this patch is correct. Let me explain.
>>>
>>> Device hot unplug is *not* guaranteed to succeed.
>>>
>>> For some buses, such as USB, it always succeeds immediately, i.e. when
>>> the device_del monitor command finishes, the device is gone. Live is
>>> good.
>>>
>>> But for PCI, device_del merely initiates the ACPI unplug rain dance. It
>>> doesn't wait for the dance to complete. Why? The dance can take an
>>> unpredictable amount of time, including forever.
>>>
>>> Problem: Subsequent device_add can fail if it reuses the qdev ID or PCI
>>> slot, and the unplug has not yet completed (race condition), or it
>>> failed. Yes, Virginia, PCI hotplug *can* fail.
>>>
>>> When unplug succeeds, the qdev is automatically destroyed.
>>> pciej_write() does that for PIIX4. Looks like pcie_cap_slot_event()
>>> does it for PCIE.
>>
>> I got a similar problem. When I unplug a pci device by hand, it works
>> as expected, and I can hotplug it again. But when I use a srcipt to
>> do the same thing, sometimes it failed. I think I may find another bug.
>>
>> Steps to reproduce this bug:
>> 1. cat ./test-e1000.sh # RHEL6RC is domain name
>>#! /bin/bash
>>
>>while true; do
>>virsh attach-interface RHEL6RC network default --mac
>> 52:54:00:1f:db:c7 --model e1000
>>if [[ $? -ne 0 ]]; then
>>break
>>fi
>>virsh detach-interface RHEL6RC network --mac 52:54:00:1f:db:c7
>>if [[ $? -ne 0 ]]; then
>>break
>>fi
>>sleep 5
>>done
>>
>> 2. ./test-e1000.sh
>>Interface attached successfully
>>
>>Interface detached successfully
>>
>>Interface attached successfully
>>
>>Interface detached successfully
>>
>>error: Failed to attach interface
>>error: operation failed: adding
>> e1000,netdev=hostnet1,id=net1,mac=52:54:00:1f:db:c7,bus=pci.0,addr=0x8
>> device failed: Duplicate ID 'net1' for device
>>
>>
>> I use ftrace to trace whether sci interrupt is passed to guest OS, here is
>> log:
>> # cat trace | grep 'irq=9'
>> -0 [000] 118342.634772: irq_handler_entry: irq=9
>> name=acpi
>> -0 [000] 118342.634831: irq_handler_exit: irq=9
>> ret=handled
>> -0 [000] 118342.693216: irq_handler_entry: irq=9
>> name=acpi
>> -0 [000] 118342.693254: irq_handler_exit: irq=9
>> ret=handled
>> -0 [000] 118347.737689: irq_handler_entry: irq=9
>> name=acpi
>> -0 [000] 118347.737738: irq_handler_exit: irq=9
>> ret=handled
>> According to the log, we only receive 3 sci interrupt, and one is lost.
>>
>> I enable piix4's debug and 1 line printf into piix4_device_hotplug:
>> printf("slot: %d, up: %d, down: %d, state: %d\n", slot,
>> s->pci0_status.up, s->pci0_status.down, state);
>> here is the log:
>>
>> PM: mapping to 0xb000
>> PM readw port=0x0004 val=0x
>> ...
>> gpe write afe2 <== 0
>> gpe write afe0 <== 255
>> gpe write afe3 <== 0
>> gpe write afe1 <== 255
>> PM readw port=0x val=0x0001
>> PM readw port=0x0002 val=0x
>> gpe read afe0 == 0
>> gpe read afe2 == 0
>> gpe read afe1 == 0
>> gpe read afe3 == 0
>> PM writew port=0x val=0x0020
>> PM readw port=0x0002 val=0x
>> PM writew port=0x0002 val=0x0020
>> PM readw port=0x0002 v
[Qemu-devel] [PATCH -V2 2/6] hw/9pfs: Add file descriptor reclaim support
Signed-off-by: Aneesh Kumar K.V
---
hw/9pfs/virtio-9p.c | 99 --
1 files changed, 95 insertions(+), 4 deletions(-)
diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
index a9f52c6..811ac38 100644
--- a/hw/9pfs/virtio-9p.c
+++ b/hw/9pfs/virtio-9p.c
@@ -20,6 +20,7 @@
#include "virtio-9p-xattr.h"
int debug_9p_pdu;
+static void v9fs_reclaim_fd(V9fsState *s);
enum {
Oread = 0x00,
@@ -107,7 +108,12 @@ static int v9fs_do_closedir(V9fsState *s, DIR *dir)
static int v9fs_do_open(V9fsState *s, V9fsString *path, int flags)
{
-return s->ops->open(&s->ctx, path->data, flags);
+int fd;
+fd = s->ops->open(&s->ctx, path->data, flags);
+if (fd > P9_FD_RECLAIM_THRES) {
+v9fs_reclaim_fd(s);
+}
+return fd;
}
static DIR *v9fs_do_opendir(V9fsState *s, V9fsString *path)
@@ -188,6 +194,7 @@ static int v9fs_do_fstat(V9fsState *s, int fd, struct stat
*stbuf)
static int v9fs_do_open2(V9fsState *s, char *fullname, uid_t uid, gid_t gid,
int flags, int mode)
{
+int fd;
FsCred cred;
cred_init(&cred);
@@ -196,7 +203,11 @@ static int v9fs_do_open2(V9fsState *s, char *fullname,
uid_t uid, gid_t gid,
cred.fc_mode = mode & 0;
flags = flags;
-return s->ops->open2(&s->ctx, fullname, flags, &cred);
+fd = s->ops->open2(&s->ctx, fullname, flags, &cred);
+if (fd > P9_FD_RECLAIM_THRES) {
+v9fs_reclaim_fd(s);
+}
+return fd;
}
static int v9fs_do_symlink(V9fsState *s, V9fsFidState *fidp,
@@ -434,6 +445,23 @@ static V9fsFidState *lookup_fid(V9fsState *s, int32_t fid)
for (f = s->fid_list; f; f = f->next) {
if (f->fid == fid) {
+/*
+ * check whether we need to reopen the
+ * file. We might have closed the fd
+ * while trying to free up some file
+ * descriptors.
+ */
+if (f->fsmap.fid_type == P9_FID_FILE) {
+/* FIXME!! should we remember the open flags ?*/
+if (f->fsmap.fs.fd == -1) {
+f->fsmap.fs.fd = v9fs_do_open(s, &f->fsmap.path, O_RDWR);
+}
+}
+/*
+ * Mark the fid as referenced so that the LRU
+ * reclaim won't close the file descriptor
+ */
+f->fsmap.flags |= FID_REFERENCED;
return f;
}
}
@@ -461,6 +489,62 @@ static V9fsFidState *alloc_fid(V9fsState *s, int32_t fid)
return f;
}
+static void v9fs_reclaim_fd(V9fsState *s)
+{
+int reclaim_count = 0;
+V9fsFidState *f;
+
+for (f = s->fid_list; f; f = f->next) {
+/*
+ * Unlink fids cannot be reclaimed. Check
+ * for them and skip them
+ */
+if (f->fsmap.flags & FID_NON_RECLAIMABLE) {
+continue;
+}
+/*
+ * if it is a recently referenced fid
+ * we leave the fid untouched and clear the
+ * reference bit. We come back to it later
+ * in the next iteration. (a simple LRU without
+ * moving list elements around)
+ */
+if (f->fsmap.flags & FID_REFERENCED) {
+f->fsmap.flags &= ~FID_REFERENCED;
+continue;
+}
+/*
+ * reclaim fd, by closing the file descriptors
+ */
+if (f->fsmap.fid_type == P9_FID_FILE) {
+if (f->fsmap.fs.fd != -1) {
+v9fs_do_close(s, f->fsmap.fs.fd);
+f->fsmap.fs.fd = -1;
+reclaim_count++;
+}
+}
+if (reclaim_count >= P9_FD_RECLAIM_THRES/2) {
+break;
+}
+}
+}
+
+static void v9fs_mark_fids_unreclaim(V9fsState *s, V9fsString *str)
+{
+V9fsFidState *fidp;
+for (fidp = s->fid_list; fidp; fidp = fidp->next) {
+if (!strcmp(fidp->fsmap.path.data, str->data)) {
+/* Mark the fid non reclaimable. */
+fidp->fsmap.flags |= FID_NON_RECLAIMABLE;
+/* reopen the file if already closed */
+if (fidp->fsmap.fs.fd == -1) {
+fidp->fsmap.fs.fd = v9fs_do_open(s, &fidp->fsmap.path, O_RDWR);
+}
+}
+}
+}
+
+
static int v9fs_xattr_fid_clunk(V9fsState *s, V9fsFidState *fidp)
{
int retval = 0;
@@ -516,7 +600,10 @@ static int free_fid(V9fsState *s, int32_t fid)
*fidpp = fidp->next;
if (fidp->fsmap.fid_type == P9_FID_FILE) {
-v9fs_do_close(s, fidp->fsmap.fs.fd);
+/* I we reclaimed the fd no need to close */
+if (fidp->fsmap.fs.fd != -1) {
+v9fs_do_close(s, fidp->fsmap.fs.fd);
+}
} else if (fidp->fsmap.fid_type == P9_FID_DIR) {
v9fs_do_closedir(s, fidp->fsmap.fs.dir);
} else if (fidp->fsmap.fid_type == P9_FID_XATTR) {
@@ -2719,7 +2806,11 @@ static void v9fs_remove(V9fsState *s, V9fsPDU *pdu)
err = -EINVAL;
goto out;
}
-
+/*
+ * IF the file is unlinked,
Re: [Qemu-devel] [PATCH (resend, rebase) 3/3] virtio-serial: Enable ioeventfd
On (Mon) 28 Feb 2011 [15:28:49], Stefan Hajnoczi wrote: > On Mon, Feb 28, 2011 at 11:12 AM, Amit Shah wrote: > > Enable ioeventfd for virtio-serial devices by default. Commit > > 25db9ebe15125deb32958c6df74996f745edf1f9 lists the benefits of using > > ioeventfd. > > > > Copying a file from guest to host over a virtio-serial channel didn't > > show much difference in time or io_exit rate. > > The cost of enabling ioeventfd is one eventfd file descriptor and KVM > in-kernel device slot per virtqueue. The current maximum number per > VM is 200, this is a kernel limit in > include/linux/kvm_host.h:NR_IOBUS_DEVS. > > Do you really want to use ioeventfd for virtio-serial? Perhaps this > is more useful for high-frequency device interfaces. I guess virtio-serial is being used heavily -- by almost all guest agents nowadays. The primary use-case, though, is not for high-bandwidth communication. This setting could be default off, it didn't show any difference in my test run, but depends on what people who use it see and think. Amit
[Qemu-devel] [PATCH -V2 5/6] hw/9pfs: Add open flag to fid
We use this flag when we reopen the file. We need
to track open flag because if the open request have
flags like O_SYNC, we want to open the file with same flag
in host too
Signed-off-by: Aneesh Kumar K.V
---
hw/9pfs/virtio-9p.c | 52 +-
hw/9pfs/virtio-9p.h |1 +
2 files changed, 43 insertions(+), 10 deletions(-)
diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
index 882f4f3..a4c5905 100644
--- a/hw/9pfs/virtio-9p.c
+++ b/hw/9pfs/virtio-9p.c
@@ -22,6 +22,8 @@
int debug_9p_pdu;
static void v9fs_reclaim_fd(V9fsState *s);
+#define PASS_OPEN_FLAG (O_SYNC | O_DSYNC | O_RSYNC | \
+O_EXCL)
enum {
Oread = 0x00,
Owrite = 0x01,
@@ -68,6 +70,24 @@ static int omode_to_uflags(int8_t mode)
return ret;
}
+static int get_dotl_openflags(int oflags)
+{
+int flags;
+/*
+ * Since we can share the fd between multiple fids,
+ * open the file in read write mode
+ */
+flags = O_RDWR;
+/*
+ * If the client asked for any of the below flags we
+ * should open the file with same open flag
+ */
+if (oflags & PASS_OPEN_FLAG) {
+flags |= oflags & PASS_OPEN_FLAG;
+}
+return flags;
+}
+
void cred_init(FsCred *credp)
{
credp->fc_uid = -1;
@@ -452,9 +472,9 @@ static V9fsFidState *lookup_fid(V9fsState *s, int32_t fid)
* descriptors.
*/
if (f->fsmap.fid_type == P9_FID_FILE) {
-/* FIXME!! should we remember the open flags ?*/
if (f->fsmap.fs.fd == -1) {
-f->fsmap.fs.fd = v9fs_do_open(s, &f->fsmap.path, O_RDWR);
+f->fsmap.fs.fd = v9fs_do_open(s, &f->fsmap.path,
+ f->fsmap.open_flags);
}
}
/*
@@ -1811,14 +1831,19 @@ static void v9fs_open_post_lstat(V9fsState *s,
V9fsOpenState *vs, int err)
v9fs_open_post_opendir(s, vs, err);
} else {
if (s->proto_version == V9FS_PROTO_2000L) {
-flags = vs->mode;
-flags &= ~(O_NOCTTY | O_ASYNC | O_CREAT);
-/* Ignore direct disk access hint until the server supports it. */
-flags &= ~O_DIRECT;
+flags = get_dotl_openflags(vs->mode);
} else {
flags = omode_to_uflags(vs->mode);
}
vs->fidp->fsmap.fs.fd = v9fs_do_open(s, &vs->fidp->fsmap.path, flags);
+vs->fidp->fsmap.open_flags = flags;
+if (flags & O_EXCL) {
+/*
+ * We let the host file system do O_EXCL check
+ * We should not reclaim such fd
+ */
+vs->fidp->fsmap.flags |= FID_NON_RECLAIMABLE;
+}
v9fs_open_post_open(s, vs, err);
}
return;
@@ -1937,11 +1962,17 @@ static void v9fs_lcreate(V9fsState *s, V9fsPDU *pdu)
v9fs_string_sprintf(&vs->fullname, "%s/%s", vs->fidp->fsmap.path.data,
vs->name.data);
-/* Ignore direct disk access hint until the server supports it. */
-flags &= ~O_DIRECT;
-
+flags = get_dotl_openflags(flags);
vs->fidp->fsmap.fs.fd = v9fs_do_open2(s, vs->fullname.data, vs->fidp->uid,
-gid, flags, mode);
+ gid, flags | O_CREAT, mode);
+vs->fidp->fsmap.open_flags = flags;
+if (flags & O_EXCL) {
+/*
+ * We let the host file system do O_EXCL check
+ * We should not reclaim such fd
+ */
+vs->fidp->fsmap.flags |= FID_NON_RECLAIMABLE;
+}
v9fs_lcreate_post_do_open2(s, vs, err);
return;
@@ -2653,6 +2684,7 @@ static void v9fs_create_post_lstat(V9fsState *s,
V9fsCreateState *vs, int err)
-1,
omode_to_uflags(vs->mode)|O_CREAT,
vs->perm);
+vs->fidp->fsmap.open_flags = omode_to_uflags(vs->mode);
v9fs_create_post_open2(s, vs, err);
}
diff --git a/hw/9pfs/virtio-9p.h b/hw/9pfs/virtio-9p.h
index 23c14d8..ca6bded 100644
--- a/hw/9pfs/virtio-9p.h
+++ b/hw/9pfs/virtio-9p.h
@@ -196,6 +196,7 @@ typedef struct V9fsfidmap {
DIR *dir;
V9fsXattr xattr;
} fs;
+int open_flags;
int fid_type;
V9fsString path;
int flags;
--
1.7.1
[Qemu-devel] [PATCH -V2 1/6] hw/9pfs: Add V9fsfidmap in preparation for adding fd reclaim
Signed-off-by: Aneesh Kumar K.V
---
hw/9pfs/virtio-9p.c | 327 ++-
hw/9pfs/virtio-9p.h | 22 +++-
2 files changed, 184 insertions(+), 165 deletions(-)
diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
index 27e7750..a9f52c6 100644
--- a/hw/9pfs/virtio-9p.c
+++ b/hw/9pfs/virtio-9p.c
@@ -453,7 +453,7 @@ static V9fsFidState *alloc_fid(V9fsState *s, int32_t fid)
f = qemu_mallocz(sizeof(V9fsFidState));
f->fid = fid;
-f->fid_type = P9_FID_NONE;
+f->fsmap.fid_type = P9_FID_NONE;
f->next = s->fid_list;
s->fid_list = f;
@@ -465,7 +465,7 @@ static int v9fs_xattr_fid_clunk(V9fsState *s, V9fsFidState
*fidp)
{
int retval = 0;
-if (fidp->fs.xattr.copied_len == -1) {
+if (fidp->fsmap.fs.xattr.copied_len == -1) {
/* getxattr/listxattr fid */
goto free_value;
}
@@ -473,24 +473,26 @@ static int v9fs_xattr_fid_clunk(V9fsState *s,
V9fsFidState *fidp)
* if this is fid for setxattr. clunk should
* result in setxattr localcall
*/
-if (fidp->fs.xattr.len != fidp->fs.xattr.copied_len) {
+if (fidp->fsmap.fs.xattr.len != fidp->fsmap.fs.xattr.copied_len) {
/* clunk after partial write */
retval = -EINVAL;
goto free_out;
}
-if (fidp->fs.xattr.len) {
-retval = v9fs_do_lsetxattr(s, &fidp->path, &fidp->fs.xattr.name,
- fidp->fs.xattr.value,
- fidp->fs.xattr.len,
- fidp->fs.xattr.flags);
+if (fidp->fsmap.fs.xattr.len) {
+retval = v9fs_do_lsetxattr(s, &fidp->fsmap.path,
+ &fidp->fsmap.fs.xattr.name,
+ fidp->fsmap.fs.xattr.value,
+ fidp->fsmap.fs.xattr.len,
+ fidp->fsmap.fs.xattr.flags);
} else {
-retval = v9fs_do_lremovexattr(s, &fidp->path, &fidp->fs.xattr.name);
+retval = v9fs_do_lremovexattr(s, &fidp->fsmap.path,
+ &fidp->fsmap.fs.xattr.name);
}
free_out:
-v9fs_string_free(&fidp->fs.xattr.name);
+v9fs_string_free(&fidp->fsmap.fs.xattr.name);
free_value:
-if (fidp->fs.xattr.value) {
-qemu_free(fidp->fs.xattr.value);
+if (fidp->fsmap.fs.xattr.value) {
+qemu_free(fidp->fsmap.fs.xattr.value);
}
return retval;
}
@@ -513,14 +515,14 @@ static int free_fid(V9fsState *s, int32_t fid)
fidp = *fidpp;
*fidpp = fidp->next;
-if (fidp->fid_type == P9_FID_FILE) {
-v9fs_do_close(s, fidp->fs.fd);
-} else if (fidp->fid_type == P9_FID_DIR) {
-v9fs_do_closedir(s, fidp->fs.dir);
-} else if (fidp->fid_type == P9_FID_XATTR) {
+if (fidp->fsmap.fid_type == P9_FID_FILE) {
+v9fs_do_close(s, fidp->fsmap.fs.fd);
+} else if (fidp->fsmap.fid_type == P9_FID_DIR) {
+v9fs_do_closedir(s, fidp->fsmap.fs.dir);
+} else if (fidp->fsmap.fid_type == P9_FID_XATTR) {
retval = v9fs_xattr_fid_clunk(s, fidp);
}
-v9fs_string_free(&fidp->path);
+v9fs_string_free(&fidp->fsmap.path);
qemu_free(fidp);
return retval;
@@ -573,7 +575,7 @@ static int fid_to_qid(V9fsState *s, V9fsFidState *fidp,
V9fsQID *qidp)
struct stat stbuf;
int err;
-err = v9fs_do_lstat(s, &fidp->path, &stbuf);
+err = v9fs_do_lstat(s, &fidp->fsmap.path, &stbuf);
if (err) {
return err;
}
@@ -1218,7 +1220,7 @@ static void v9fs_attach(V9fsState *s, V9fsPDU *pdu)
fidp->uid = n_uname;
-v9fs_string_sprintf(&fidp->path, "%s", "/");
+v9fs_string_sprintf(&fidp->fsmap.path, "%s", "/");
err = fid_to_qid(s, fidp, &qid);
if (err) {
err = -EINVAL;
@@ -1242,7 +1244,7 @@ static void v9fs_stat_post_lstat(V9fsState *s,
V9fsStatState *vs, int err)
goto out;
}
-err = stat_to_v9stat(s, &vs->fidp->path, &vs->stbuf, &vs->v9stat);
+err = stat_to_v9stat(s, &vs->fidp->fsmap.path, &vs->stbuf, &vs->v9stat);
if (err) {
goto out;
}
@@ -1275,7 +1277,7 @@ static void v9fs_stat(V9fsState *s, V9fsPDU *pdu)
goto out;
}
-err = v9fs_do_lstat(s, &vs->fidp->path, &vs->stbuf);
+err = v9fs_do_lstat(s, &vs->fidp->fsmap.path, &vs->stbuf);
v9fs_stat_post_lstat(s, vs, err);
return;
@@ -1327,7 +1329,7 @@ static void v9fs_getattr(V9fsState *s, V9fsPDU *pdu)
/* Currently we only support BASIC fields in stat, so there is no
* need to look at request_mask.
*/
-err = v9fs_do_lstat(s, &fidp->path, &vs->stbuf);
+err = v9fs_do_lstat(s, &fidp->fsmap.path, &vs->stbuf);
v9fs_getattr_post_lstat(s, vs, err);
return;
@@ -1370,7 +1372,7 @@ static void v9fs_setattr_post_chown(V9fsState *s,
V9fsSetattrState *vs, int err)
}
if (vs->v9iattr.valid & (ATTR_SIZE)) {
-err = v9fs_do_truncate(s, &vs->fidp->path, vs->v9iattr.size);
[Qemu-devel] [PATCH -V2 6/6] hw/9pfs: Add directory reclaim support
Signed-off-by: Aneesh Kumar K.V
---
hw/9pfs/virtio-9p.c | 21 +++--
1 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
index a4c5905..08c0399 100644
--- a/hw/9pfs/virtio-9p.c
+++ b/hw/9pfs/virtio-9p.c
@@ -138,7 +138,12 @@ static int v9fs_do_open(V9fsState *s, V9fsString *path,
int flags)
static DIR *v9fs_do_opendir(V9fsState *s, V9fsString *path)
{
-return s->ops->opendir(&s->ctx, path->data);
+DIR *dir;
+dir = s->ops->opendir(&s->ctx, path->data);
+if (dirfd(dir) > P9_FD_RECLAIM_THRES) {
+v9fs_reclaim_fd(s);
+}
+return dir;
}
static void v9fs_do_rewinddir(V9fsState *s, DIR *dir)
@@ -476,6 +481,10 @@ static V9fsFidState *lookup_fid(V9fsState *s, int32_t fid)
f->fsmap.fs.fd = v9fs_do_open(s, &f->fsmap.path,
f->fsmap.open_flags);
}
+} else if (f->fsmap.fid_type == P9_FID_DIR) {
+if (f->fsmap.fs.dir == NULL) {
+f->fsmap.fs.dir = v9fs_do_opendir(s, &f->fsmap.path);
+}
}
/*
* Mark the fid as referenced so that the LRU
@@ -542,6 +551,12 @@ static void v9fs_reclaim_fd(V9fsState *s)
f->fsmap.fs.fd = -1;
reclaim_count++;
}
+} else if (f->fsmap.fid_type == P9_FID_DIR) {
+if (f->fsmap.fs.dir != NULL) {
+v9fs_do_closedir(s, f->fsmap.fs.dir);
+f->fsmap.fs.dir = NULL;
+reclaim_count++;
+}
}
if (reclaim_count >= P9_FD_RECLAIM_THRES/2) {
break;
@@ -625,7 +640,9 @@ static int free_fid(V9fsState *s, int32_t fid)
v9fs_do_close(s, fidp->fsmap.fs.fd);
}
} else if (fidp->fsmap.fid_type == P9_FID_DIR) {
-v9fs_do_closedir(s, fidp->fsmap.fs.dir);
+if (fidp->fsmap.fs.dir != NULL) {
+v9fs_do_closedir(s, fidp->fsmap.fs.dir);
+}
} else if (fidp->fsmap.fid_type == P9_FID_XATTR) {
retval = v9fs_xattr_fid_clunk(s, fidp);
}
--
1.7.1
[Qemu-devel] [PATCH -V2 3/6] hw/9pfs: Use v9fs_do_close instead of close
we should use the local abstraction instead of
directly calling close.
Signed-off-by: Aneesh Kumar K.V
---
hw/9pfs/virtio-9p.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
index 811ac38..c4b0198 100644
--- a/hw/9pfs/virtio-9p.c
+++ b/hw/9pfs/virtio-9p.c
@@ -1873,7 +1873,7 @@ static void v9fs_post_lcreate(V9fsState *s,
V9fsLcreateState *vs, int err)
vs->fidp->fsmap.fid_type = P9_FID_NONE;
err = -errno;
if (vs->fidp->fsmap.fs.fd > 0) {
-close(vs->fidp->fsmap.fs.fd);
+v9fs_do_close(s, vs->fidp->fsmap.fs.fd);
}
}
@@ -2533,7 +2533,7 @@ static void v9fs_create_post_fstat(V9fsState *s,
V9fsCreateState *vs, int err)
{
if (err) {
vs->fidp->fsmap.fid_type = P9_FID_NONE;
-close(vs->fidp->fsmap.fs.fd);
+v9fs_do_close(s, vs->fidp->fsmap.fs.fd);
err = -errno;
}
v9fs_post_create(s, vs, err);
--
1.7.1
[Qemu-devel] [PATCH -V2 4/6] hw/9pfs: Implement syncfs
Signed-off-by: Aneesh Kumar K.V
---
hw/9pfs/virtio-9p.c | 31 +++
hw/9pfs/virtio-9p.h |2 ++
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
index c4b0198..882f4f3 100644
--- a/hw/9pfs/virtio-9p.c
+++ b/hw/9pfs/virtio-9p.c
@@ -1978,6 +1978,36 @@ static void v9fs_fsync(V9fsState *s, V9fsPDU *pdu)
v9fs_post_do_fsync(s, pdu, err);
}
+static void v9fs_post_do_syncfs(V9fsState *s, V9fsPDU *pdu, int err)
+{
+if (err == -1) {
+err = -errno;
+}
+complete_pdu(s, pdu, err);
+}
+
+static void v9fs_syncfs(V9fsState *s, V9fsPDU *pdu)
+{
+int err;
+int32_t fid;
+size_t offset = 7;
+V9fsFidState *fidp;
+
+pdu_unmarshal(pdu, offset, "d", &fid);
+fidp = lookup_fid(s, fid);
+if (fidp == NULL) {
+err = -ENOENT;
+v9fs_post_do_syncfs(s, pdu, err);
+return;
+}
+/*
+ * We don't have per file system syncfs
+ * So just return success
+ */
+err = 0;
+v9fs_post_do_syncfs(s, pdu, err);
+}
+
static void v9fs_clunk(V9fsState *s, V9fsPDU *pdu)
{
int32_t fid;
@@ -3676,6 +3706,7 @@ static pdu_handler_t *pdu_handlers[] = {
[P9_TWALK] = v9fs_walk,
[P9_TCLUNK] = v9fs_clunk,
[P9_TFSYNC] = v9fs_fsync,
+[P9_TSYNCFS] = v9fs_syncfs,
[P9_TOPEN] = v9fs_open,
[P9_TREAD] = v9fs_read,
#if 0
diff --git a/hw/9pfs/virtio-9p.h b/hw/9pfs/virtio-9p.h
index 2f49641..23c14d8 100644
--- a/hw/9pfs/virtio-9p.h
+++ b/hw/9pfs/virtio-9p.h
@@ -13,6 +13,8 @@
#define VIRTIO_9P_MOUNT_TAG 0
enum {
+P9_TSYNCFS = 0,
+P9_RSYNCFS,
P9_TLERROR = 6,
P9_RLERROR,
P9_TSTATFS = 8,
--
1.7.1
[Qemu-devel] Re: virtio-serial semantics for binary data and guest agents
On (Fri) 25 Feb 2011 [14:25:20], Michael Roth wrote: > On 02/24/2011 06:48 AM, Amit Shah wrote: > >On (Wed) 23 Feb 2011 [08:31:52], Michael Roth wrote: > >>On 02/22/2011 10:59 PM, Amit Shah wrote: > >>>On (Tue) 22 Feb 2011 [16:40:55], Michael Roth wrote: > If something in the guest is attempting to read/write from the > virtio-serial device, and nothing is connected to virtio-serial's > host character device (say, a socket) > > 1. writes will block until something connect()s, at which point the > write will succeed > > 2. reads will always return 0 until something connect()s, at which > point the reads will block until there's data > > This makes it difficult (impossible?) to implement the notion of > connect/disconnect or open/close over virtio-serial without layering > another protocol on top using hackish things like length-encoded > payloads or sentinel values to determine the end of one > RPC/request/response/session and the start of the next. > > For instance, if the host side disconnects, then reconnects before > we read(), we may never get the read()=0, and our FD remains valid. > Whereas with a tcp/unix socket our FD is no longer valid, and the > read()=0 is an event we can check for at any point after the other > end does a close/disconnect. > >>> > >>>There's SIGIO support, so host connect-disconnect notifications can be > >>>caught via the signal. > >> > >>I recall looking into this at some pointbut don't we get a SIGIO > >>for read/write-ability in general? > > > >I don't get you -- the virtio_console driver emits the SIGIO signal > >only when the host side connects or disconnects. See > > > >http://www.linux-kvm.org/page/Virtio-serial_API > > > >So whenever you receive a SIGIO, poll() in the signal handler for all > >fds of interest and whichever has POLLIN set is writable. Whichever > >has POLLHUP set is not. If you maintain previous state of the fd > >(before signal), you can figure out if something happened on the host > >side. > > > > I tried this on RHEL6+rhn updates but the O_ASYNC flag doesn't seem > to be supported. Has this been backported? Yes, it has been. > Either way, it seems we can still lose the disconnect event/poll > state change if the host reconnects before the signal is delivered. > So SIGIO in an application would need to be reserved for absolutely > 2 things: a host connect or disconnect (distinguishing between the 2 > may not be so important, we could treat either as the previous > session having been closed). Which limits the application to only > having 1 O_ASYNC FD open at a time. > > But even if we do that, it seems like there might still be a small > window where the application could read/write data intended for the > previous connection before the signal handler is invoked. Not too > sure on that point though. Assuming this isn't the case...it could > work. But what about windows guests? > > >>So you still need some way > >>differentiate, say, readability from a disconnect/EOF, and the > >>read()=0 that could determine this is still racing with host-side > >>reconnects. > > > >>>Also, nonblocking reads/writes will return -EPIPE if the host-side > >>>connection is not up. > >> > >>But we still essentially need to poll() for a host-side disconnected > >>state, which is still racy since they may reconnect before we've > >>done a read/write that would've generated the -EPIPE. It seems like > >>what we really need is for the FD to be invalid from that point > >>forward. > > > >This would go against (or abuse) a chardev interface. It would > >effectively treat a host-side port close as a hot-unplug event. > > > > Well, not a complete hot-unplug. The port would still be there, we'd > just need to re-open it after a read()=0 > > Personally I'm not necessarily advocating we change the default > behavior, but couldn't we support this as a separate mode? > > -device virtserialport,inv_fd_on_host_close=1 > > or something along that line? Yes, that would be reasonable. Maybe even a monitor command to switch the type? > >>Also, I focused more on the guest-side connect/disconnect detection, > >>but as Anthony mentioned I think the host side shares similar > >>limitations as well. AFAIK once we connect to the chardev that FD > >>remains valid until the connected process closes it, and so races > >>with the guest side on detecting connect/disconnect events in a > >>similar manner. For the host side it looks like virtio-console has > >>guest_close/guest_open callbacks already that we could potentially > >>use...seems like it's just a matter of tying them to the chardev... > >>basically having virtio-serial's guest_close() result in a close() > >>on the corresponding chardev connection's FD. > > > >Yes, this could be used. > > > >However, the problem with that will be that the chardev can't be > >opened again (AFAIR) and a new chardev will have to be used. > > > > Hmm...yea
Re: [Qemu-devel] [RFC PATCH -V1 1/4] hw/9pfs: Add file descriptor reclaim support
On Mon, 28 Feb 2011 17:44:56 -0800, "Venkateswararao Jujjuri (JV)" wrote: > On 2/5/2011 10:08 AM, Aneesh Kumar K.V wrote: > > This add file descriptor recliam to 9p server > > Please split it into two patches. > > 1. Introducing fsmap. > 2. Introducing the reclaim mechanism. Already did that in my local tree. I will post the new series as a followup This is what i have now hw/9pfs: Add V9fsfidmap in preparation for adding fd reclaim hw/9pfs: Add file descriptor reclaim support hw/9pfs: Use v9fs_do_close instead of close hw/9pfs: Implement syncfs hw/9pfs: Add open flag to fid hw/9pfs: Add directory reclaim support > > Concern: With this we will be traversing the whole fid list for many > operations > .. how is > the performance impact? > I haven't done any performance measurements yet -aneesh
Re: [Qemu-devel] [RFC PATCH -V1 3/4] hw/9pfs: Implement syncfs
On Mon, 28 Feb 2011 17:48:34 -0800, "Venkateswararao Jujjuri (JV)"
wrote:
> On 2/5/2011 10:08 AM, Aneesh Kumar K.V wrote:
> > Signed-off-by: Aneesh Kumar K.V
> > ---
> > hw/9pfs/virtio-9p.c | 31 +++
> > hw/9pfs/virtio-9p.h |2 ++
> > 2 files changed, 33 insertions(+), 0 deletions(-)
> >
> > diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
> > index 2d9ca11..1518e00 100644
> > --- a/hw/9pfs/virtio-9p.c
> > +++ b/hw/9pfs/virtio-9p.c
> > @@ -1978,6 +1978,36 @@ static void v9fs_fsync(V9fsState *s, V9fsPDU *pdu)
> > v9fs_post_do_fsync(s, pdu, err);
> > }
> >
> > +static void v9fs_post_do_syncfs(V9fsState *s, V9fsPDU *pdu, int err)
> > +{
> > +if (err == -1) {
> > +err = -errno;
> > +}
> > +complete_pdu(s, pdu, err);
> > +}
> > +
> > +static void v9fs_syncfs(V9fsState *s, V9fsPDU *pdu)
> > +{
> > +int err;
> > +int32_t fid;
> > +size_t offset = 7;
> > +V9fsFidState *fidp;
> > +
> > +pdu_unmarshal(pdu, offset, "d", &fid);
> > +fidp = lookup_fid(s, fid);
> > +if (fidp == NULL) {
> > +err = -ENOENT;
> > +v9fs_post_do_syncfs(s, pdu, err);
> > +return;
> > +}
> > +/*
> > + * We don't have per file system syncfs
> > + * So just return success
> > + */
> > +err = 0;
>
> How about
>
> err = 0
> if (fidp == NULL)
> err = -ENOENT
>
That err = 0 will go away once we get the below support in the kernel.
http://thread.gmane.org/gmane.linux.file-systems/44628
-aneesh
Re: [Qemu-devel] [RFC PATCH -V1 4/4] hw/9pfs: Add open flag to fid
On Mon, 28 Feb 2011 18:00:56 -0800, "Venkateswararao Jujjuri (JV)"
wrote:
> On 2/5/2011 10:08 AM, Aneesh Kumar K.V wrote:
> > We use this flag when we reopen the file. We need
> > to track open flag because if the open request have
> > flags like O_SYNC, we want to open the file with same flag
> > in host too
> >
> > Signed-off-by: Aneesh Kumar K.V
> > ---
> > hw/9pfs/virtio-9p.c | 57
> > ++-
> > hw/9pfs/virtio-9p.h |1 +
> > 2 files changed, 48 insertions(+), 10 deletions(-)
> >
> > diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
> > index 1518e00..cbdf705 100644
> > --- a/hw/9pfs/virtio-9p.c
> > +++ b/hw/9pfs/virtio-9p.c
> > @@ -22,6 +22,8 @@
> > int debug_9p_pdu;
> > static void v9fs_reclaim_fd(V9fsState *s);
> >
> > +#define PASS_OPEN_FLAG (O_SYNC | O_DSYNC | O_RSYNC | \
> > +O_EXCL)
> > enum {
> > Oread = 0x00,
> > Owrite = 0x01,
> > @@ -68,6 +70,24 @@ static int omode_to_uflags(int8_t mode)
> > return ret;
> > }
> >
> > +static int get_dotl_openflags(int oflags)
> > +{
> > +int flags;
> > +/*
> > + * Since we can share the fd between multiple fids,
> > + * open the file in read write mode
> > + */
> > +flags = O_RDWR;
> > +/*
> > + * If the client asked for any of the below flags we
> > + * should open the file with same open flag
> > + */
> > +if (oflags & PASS_OPEN_FLAG) {
> > +flags = oflags & PASS_OPEN_FLAG;
> Isn't it
>
> flags |= oflags & PASS_OPEN_FLAG; ?
Already fixed in my local tree.
> > +}
> > +return flags;
> > +}
> > +
> > void cred_init(FsCred *credp)
> > {
> > credp->fc_uid = -1;
> > @@ -452,9 +472,9 @@ static V9fsFidState *lookup_fid(V9fsState *s, int32_t
> > fid)
> > * descriptors.
> > */
> > if (f->fsmap.fid_type == P9_FID_FILE) {
> > -/* FIXME!! should we remember the open flags ?*/
> > if (f->fsmap.fs.fd == -1) {
> > -f->fsmap.fs.fd = v9fs_do_open(s, &f->fsmap.path,
> > O_RDWR);
> > +f->fsmap.fs.fd = v9fs_do_open(s, &f->fsmap.path,
> > + f->fsmap.open_flags);
> > }
> > }
> > /*
> > @@ -1811,14 +1831,19 @@ static void v9fs_open_post_lstat(V9fsState *s,
> > V9fsOpenState *vs, int err)
> > v9fs_open_post_opendir(s, vs, err);
> > } else {
> > if (s->proto_version == V9FS_PROTO_2000L) {
> > -flags = vs->mode;
> > -flags &= ~(O_NOCTTY | O_ASYNC | O_CREAT);
> > -/* Ignore direct disk access hint until the server supports
> > it. */
> > -flags &= ~O_DIRECT;
>
> This is more drastic change. So far we are ignoring only few flags..but with
> this we are allowing only few flags. Need to understand the impact of this on
> dotl protocol.
The goal is to make sure we use only those flags that make sense for the
host file system. That would enable us to share the fd between multiple
fids. We cannot share fd with different open flags.
>
> Also I would put this patch ahead of introducing fid reclaim patch.
>
> > +flags = get_dotl_openflags(vs->mode);
> > } else {
> > flags = omode_to_uflags(vs->mode);
> > }
> > vs->fidp->fsmap.fs.fd = v9fs_do_open(s, &vs->fidp->fsmap.path,
> > flags);
> > +vs->fidp->fsmap.open_flags = flags;
> > +if (flags & O_EXCL) {
> > +/*
> > + * We let the host file system do O_EXCL check
> > + * We should not reclaim such fd
> > + */
> > +vs->fidp->fsmap.flags |= FID_NON_RECLAIMABLE;
> > +}
> > v9fs_open_post_open(s, vs, err);
> > }
> > return;
> > @@ -1937,11 +1962,22 @@ static void v9fs_lcreate(V9fsState *s, V9fsPDU *pdu)
> > v9fs_string_sprintf(&vs->fullname, "%s/%s", vs->fidp->fsmap.path.data,
> > vs->name.data);
> >
> > -/* Ignore direct disk access hint until the server supports it. */
> > -flags &= ~O_DIRECT;
> > -
> > +flags = get_dotl_openflags(flags);
> > vs->fidp->fsmap.fs.fd = v9fs_do_open2(s, vs->fullname.data,
> > vs->fidp->uid,
> > -gid, flags, mode);
> > + gid, flags, mode);
> > +/*
> > + * We don't want to recreate the in reclaim path. So remove
> > + * create flag
> > + */
> > +flags &= ~O_CREAT;
> > +vs->fidp->fsmap.open_flags = flags;
> > +if (flags & O_EXCL) {
> > +/*
> > + * We let the host file system do O_EXCL check
> > + * We should not reclaim such fd
> > + */
> > +vs->fidp->fsmap.flags |= FID_NON_RECLAIMABLE;
> > +}
> You can move above two steps to here by...
> vs->fidp->fsmap.open_flags = flags & ~O_CREAT
> > v9fs_lcreate_post_do_open2(s, vs, err);
> > re
[Qemu-devel] [Bug 723871] Re: qemu-kvm-0.14.0 Aborts with -vga qxl
** Changed in: qemu Status: New => Confirmed ** Changed in: qemu Status: Confirmed => New ** Changed in: qemu Status: New => Confirmed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/723871 Title: qemu-kvm-0.14.0 Aborts with -vga qxl Status in QEMU: Confirmed Bug description: Host CPU is Core i7 Q820. KVM is from 2.6.35-gentoo-r5 kernel (x86_64). Host has spice-0.7.2 and spice-protocol-0.7.0. Guest is Windows XP SP3 with qxl driver 0.6.1, virtio-serial 1.1.6 and vdagent 0.6.3. qemu-kvm is started like so: qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid -drive file=/home/rick/qemu/hds/wxp.raw,if=virtio,media=disk,aio=native,snapshot=on -m 768 -name WinXP -net nic,model=virtio -net user -localtime -usb -vga qxl -device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -spice port=1234,disable-ticketing -monitor stdio and crashes with: qemu-system-x86_64: /home/rick/qemu/src/qemu-kvm-0.14.0/qemu-kvm.c:1724: kvm_mutex_unlock: Assertion `!cpu_single_env' failed. Aborted If I use -no-kvm, it works fine. If I use -vga std, it works fine. -enable-kvm and -vga qxl crashes.
[Qemu-devel] [Bug 726962] [NEW] darwin user i386 no such directory
Public bug reported: qemu-0.14.0/darwin-user/i386: No such file or directory I tried the current sources and the "stable". I am running mac os x 10.5.8 -- 64 bit on macbook pro. fusion works, virtualbox works, Q did on i386, but not 64 bit. I had "fink" installed, and changed /sw to be after /usr/local/bin so that I could put up the latest gmake to get around fink's problems. It won't compile with gcc42, so I am using XCode 4.0.1. What am I doing wrong? What did I miss? commit 417131fb9ad3f6dd7177a338cc5f143dec4d75f0 Author: Stefan Weil Date: Fri Feb 25 16:30:20 2011 -0600 ** 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/726962 Title: darwin user i386 no such directory Status in QEMU: New Bug description: qemu-0.14.0/darwin-user/i386: No such file or directory I tried the current sources and the "stable". I am running mac os x 10.5.8 -- 64 bit on macbook pro. fusion works, virtualbox works, Q did on i386, but not 64 bit. I had "fink" installed, and changed /sw to be after /usr/local/bin so that I could put up the latest gmake to get around fink's problems. It won't compile with gcc42, so I am using XCode 4.0.1. What am I doing wrong? What did I miss? commit 417131fb9ad3f6dd7177a338cc5f143dec4d75f0 Author: Stefan Weil Date: Fri Feb 25 16:30:20 2011 -0600
Re: [Qemu-devel] [PATCH] `qdev_free` when unplug a pci device
Hi.
I don't suppose that just introducing pending bits solve the issue.
Your test only use single hot plug/unplug. How about mixing of multiple
hot plug/unplug with different slots.
Zeroing up/down on piix4_device_hotplug() is the culprit.
State machine of (up, down) would be needed.
(up, down) of each slots should be changed following
something like
- on power-on (0, 0)
- on hot plug (0, 0) -> (1, 0)
if other combination -> error
- on hot unpug (1, 0) or (0, 0) -> (0, 1)
(0, 0) is for cold plugged devices.
(1, 0) is for hot plugged devices.
if other combination -> error
- on pciej_write(write on PCI_EJ_BASE)
(0, 1) -> (0, 0) and qdev_free()
if other combination -> ignore
When enabling sci, those bits are checked and raise sci if necessary.
Any comments on this?
Anyway the current pci hotplug-related commands are somewhat broken,
and needs clean up with multifunction hotplug support which is
on my todo list.
thanks
On Mon, Feb 28, 2011 at 10:52:40AM +0800, Wen Congyang wrote:
> Hi Markus Armbruster
>
> At 02/23/2011 04:30 PM, Markus Armbruster Write:
> > Isaku Yamahata writes:
> >
>
>
>
> >
> > I don't think this patch is correct. Let me explain.
> >
> > Device hot unplug is *not* guaranteed to succeed.
> >
> > For some buses, such as USB, it always succeeds immediately, i.e. when
> > the device_del monitor command finishes, the device is gone. Live is
> > good.
> >
> > But for PCI, device_del merely initiates the ACPI unplug rain dance. It
> > doesn't wait for the dance to complete. Why? The dance can take an
> > unpredictable amount of time, including forever.
> >
> > Problem: Subsequent device_add can fail if it reuses the qdev ID or PCI
> > slot, and the unplug has not yet completed (race condition), or it
> > failed. Yes, Virginia, PCI hotplug *can* fail.
> >
> > When unplug succeeds, the qdev is automatically destroyed.
> > pciej_write() does that for PIIX4. Looks like pcie_cap_slot_event()
> > does it for PCIE.
>
> I got a similar problem. When I unplug a pci device by hand, it works
> as expected, and I can hotplug it again. But when I use a srcipt to
> do the same thing, sometimes it failed. I think I may find another bug.
>
> Steps to reproduce this bug:
> 1. cat ./test-e1000.sh # RHEL6RC is domain name
>#! /bin/bash
>
>while true; do
>virsh attach-interface RHEL6RC network default --mac
> 52:54:00:1f:db:c7 --model e1000
>if [[ $? -ne 0 ]]; then
>break
>fi
>virsh detach-interface RHEL6RC network --mac 52:54:00:1f:db:c7
>if [[ $? -ne 0 ]]; then
>break
>fi
>sleep 5
>done
>
> 2. ./test-e1000.sh
>Interface attached successfully
>
>Interface detached successfully
>
>Interface attached successfully
>
>Interface detached successfully
>
>error: Failed to attach interface
>error: operation failed: adding
> e1000,netdev=hostnet1,id=net1,mac=52:54:00:1f:db:c7,bus=pci.0,addr=0x8 device
> failed: Duplicate ID 'net1' for device
>
>
> I use ftrace to trace whether sci interrupt is passed to guest OS, here is
> log:
> # cat trace | grep 'irq=9'
> -0 [000] 118342.634772: irq_handler_entry: irq=9 name=acpi
> -0 [000] 118342.634831: irq_handler_exit: irq=9
> ret=handled
> -0 [000] 118342.693216: irq_handler_entry: irq=9 name=acpi
> -0 [000] 118342.693254: irq_handler_exit: irq=9
> ret=handled
> -0 [000] 118347.737689: irq_handler_entry: irq=9 name=acpi
> -0 [000] 118347.737738: irq_handler_exit: irq=9
> ret=handled
> According to the log, we only receive 3 sci interrupt, and one is lost.
>
> I enable piix4's debug and 1 line printf into piix4_device_hotplug:
> printf("slot: %d, up: %d, down: %d, state: %d\n", slot,
> s->pci0_status.up, s->pci0_status.down, state);
> here is the log:
>
> PM: mapping to 0xb000
> PM readw port=0x0004 val=0x
> ...
> gpe write afe2 <== 0
> gpe write afe0 <== 255
> gpe write afe3 <== 0
> gpe write afe1 <== 255
> PM readw port=0x val=0x0001
> PM readw port=0x0002 val=0x
> gpe read afe0 == 0
> gpe read afe2 == 0
> gpe read afe1 == 0
> gpe read afe3 == 0
> PM writew port=0x val=0x0020
> PM readw port=0x0002 val=0x
> PM writew port=0x0002 val=0x0020
> PM readw port=0x0002 val=0x0020
> gpe write afe2 <== 255
> gpe write afe3 <== 255
> ...
> slot: 6, up: 0, down: 0, state: 1 < we attach interface the first time
> PM readw port=0x val=0x0001
> PM readw port=0x0002 val=0x0120
> gpe read afe0 == 2
> gpe read afe2 == ff
> gpe read afe2 == ff
> gpe write afe2 <== 253
> gpe read afe1 == 0
> gpe read afe3 == ff
> pcihotplug read ae00 == 40
> pcihotplug read ae04 == 0
> ...
> gpe write afe0 <== 2
> gpe write afe2 <== 255
> slot: 6, up: 64, down: 0, state: 0 <= we detach interface
Re: [Qemu-devel] Re: kvm crashes with spice while loading qxl
On Sunday 27 February 2011 13:03:14 Alon Levy wrote: > On Sat, Feb 26, 2011 at 01:29:01PM +0100, Jan Kiszka wrote: > > On 2011-02-26 12:43, xming wrote: > > > When trying to start X (and it loads qxl driver) the kvm process just > > > crashes. > > This is fixed by Gerd's attached patch (taken from rhel repository, don't > know why it wasn't pushed to qemu-kvm upstream). I'll send it to kvm list > as well (separate email). > This patch also fixed https://bugs.launchpad.net/bugs/723871 I created the bug report on launchpad, but I suppose it should be left open until the patch hits qemu-kvm? -Rick
Re: [Qemu-devel] [patch 2/3] Add support for live block copy
On Sat, Feb 26, 2011 at 07:45:44AM -0600, Anthony Liguori wrote: > >>>+- "filename": target image filename (json-string) > >>Is this a created image? Is this an image to create? > >A previously created image. > > > >>To future proof for blockdev, we should make this argument optional > >>and if it's not specified throw an error about missing argument. > >>This let's us introduce an optional blockdev argument such that we > >>can use a blockdev name. > >What you mean "blockdev"? > > -drive file=image.qcow2,if=none,id=foo > > 'foo' is a named blockdev. We don't have a way to add these through > the monitor (yet) but we will for 0.15. Fail to see the point of having a named blockdev to specify the target? > >>If I resume the > >>operation with the incremental flag set, will it Just Work? > >As in: > > > >- block_copy ide0-hd1 /mnt/aa.img > >- block_copy ide0-hd1 /mnt/aa.img -i > > > >? > > > >The second command will fail with QERR_BLOCKCOPY_IN_PROGRESS. > > No, as in: > > block_copy ide0-hd1 /mnt/aa.img > block_copy_cancel ide0-h1 > block_copy ide0-h1 /mnt/aa.img -i > > Does it pick up where it left off or does it start all over again? It starts all over again.
Re: [Qemu-devel] [RFC PATCH -V1 4/4] hw/9pfs: Add open flag to fid
On 2/5/2011 10:08 AM, Aneesh Kumar K.V wrote:
> We use this flag when we reopen the file. We need
> to track open flag because if the open request have
> flags like O_SYNC, we want to open the file with same flag
> in host too
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> hw/9pfs/virtio-9p.c | 57
> ++-
> hw/9pfs/virtio-9p.h |1 +
> 2 files changed, 48 insertions(+), 10 deletions(-)
>
> diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
> index 1518e00..cbdf705 100644
> --- a/hw/9pfs/virtio-9p.c
> +++ b/hw/9pfs/virtio-9p.c
> @@ -22,6 +22,8 @@
> int debug_9p_pdu;
> static void v9fs_reclaim_fd(V9fsState *s);
>
> +#define PASS_OPEN_FLAG (O_SYNC | O_DSYNC | O_RSYNC | \
> +O_EXCL)
> enum {
> Oread = 0x00,
> Owrite = 0x01,
> @@ -68,6 +70,24 @@ static int omode_to_uflags(int8_t mode)
> return ret;
> }
>
> +static int get_dotl_openflags(int oflags)
> +{
> +int flags;
> +/*
> + * Since we can share the fd between multiple fids,
> + * open the file in read write mode
> + */
> +flags = O_RDWR;
> +/*
> + * If the client asked for any of the below flags we
> + * should open the file with same open flag
> + */
> +if (oflags & PASS_OPEN_FLAG) {
> +flags = oflags & PASS_OPEN_FLAG;
Isn't it
flags |= oflags & PASS_OPEN_FLAG; ?
> +}
> +return flags;
> +}
> +
> void cred_init(FsCred *credp)
> {
> credp->fc_uid = -1;
> @@ -452,9 +472,9 @@ static V9fsFidState *lookup_fid(V9fsState *s, int32_t fid)
> * descriptors.
> */
> if (f->fsmap.fid_type == P9_FID_FILE) {
> -/* FIXME!! should we remember the open flags ?*/
> if (f->fsmap.fs.fd == -1) {
> -f->fsmap.fs.fd = v9fs_do_open(s, &f->fsmap.path, O_RDWR);
> +f->fsmap.fs.fd = v9fs_do_open(s, &f->fsmap.path,
> + f->fsmap.open_flags);
> }
> }
> /*
> @@ -1811,14 +1831,19 @@ static void v9fs_open_post_lstat(V9fsState *s,
> V9fsOpenState *vs, int err)
> v9fs_open_post_opendir(s, vs, err);
> } else {
> if (s->proto_version == V9FS_PROTO_2000L) {
> -flags = vs->mode;
> -flags &= ~(O_NOCTTY | O_ASYNC | O_CREAT);
> -/* Ignore direct disk access hint until the server supports it.
> */
> -flags &= ~O_DIRECT;
This is more drastic change. So far we are ignoring only few flags..but with
this we are allowing only few flags. Need to understand the impact of this on
dotl protocol.
Also I would put this patch ahead of introducing fid reclaim patch.
> +flags = get_dotl_openflags(vs->mode);
> } else {
> flags = omode_to_uflags(vs->mode);
> }
> vs->fidp->fsmap.fs.fd = v9fs_do_open(s, &vs->fidp->fsmap.path,
> flags);
> +vs->fidp->fsmap.open_flags = flags;
> +if (flags & O_EXCL) {
> +/*
> + * We let the host file system do O_EXCL check
> + * We should not reclaim such fd
> + */
> +vs->fidp->fsmap.flags |= FID_NON_RECLAIMABLE;
> +}
> v9fs_open_post_open(s, vs, err);
> }
> return;
> @@ -1937,11 +1962,22 @@ static void v9fs_lcreate(V9fsState *s, V9fsPDU *pdu)
> v9fs_string_sprintf(&vs->fullname, "%s/%s", vs->fidp->fsmap.path.data,
> vs->name.data);
>
> -/* Ignore direct disk access hint until the server supports it. */
> -flags &= ~O_DIRECT;
> -
> +flags = get_dotl_openflags(flags);
> vs->fidp->fsmap.fs.fd = v9fs_do_open2(s, vs->fullname.data,
> vs->fidp->uid,
> -gid, flags, mode);
> + gid, flags, mode);
> +/*
> + * We don't want to recreate the in reclaim path. So remove
> + * create flag
> + */
> +flags &= ~O_CREAT;
> +vs->fidp->fsmap.open_flags = flags;
> +if (flags & O_EXCL) {
> +/*
> + * We let the host file system do O_EXCL check
> + * We should not reclaim such fd
> + */
> +vs->fidp->fsmap.flags |= FID_NON_RECLAIMABLE;
> +}
You can move above two steps to here by...
vs->fidp->fsmap.open_flags = flags & ~O_CREAT
> v9fs_lcreate_post_do_open2(s, vs, err);
> return;
>
> @@ -2653,6 +2689,7 @@ static void v9fs_create_post_lstat(V9fsState *s,
> V9fsCreateState *vs, int err)
>-1,
>
> omode_to_uflags(vs->mode)|O_CREAT,
>vs->perm);
> +vs->fidp->fsmap.open_flags = omode_to_uflags(vs->mode);
why are we not doing ~O_CREAT here?
- JV
> v9fs_create_post_open2(s, vs, err);
> }
>
> diff --git a/hw/9pfs/virtio-9p.h b/hw/9pfs/virtio-9p.h
> index b2cd24b..c3cb75e 100644
> --
Re: [Qemu-devel] [RFC PATCH -V1 3/4] hw/9pfs: Implement syncfs
On 2/5/2011 10:08 AM, Aneesh Kumar K.V wrote:
> Signed-off-by: Aneesh Kumar K.V
> ---
> hw/9pfs/virtio-9p.c | 31 +++
> hw/9pfs/virtio-9p.h |2 ++
> 2 files changed, 33 insertions(+), 0 deletions(-)
>
> diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
> index 2d9ca11..1518e00 100644
> --- a/hw/9pfs/virtio-9p.c
> +++ b/hw/9pfs/virtio-9p.c
> @@ -1978,6 +1978,36 @@ static void v9fs_fsync(V9fsState *s, V9fsPDU *pdu)
> v9fs_post_do_fsync(s, pdu, err);
> }
>
> +static void v9fs_post_do_syncfs(V9fsState *s, V9fsPDU *pdu, int err)
> +{
> +if (err == -1) {
> +err = -errno;
> +}
> +complete_pdu(s, pdu, err);
> +}
> +
> +static void v9fs_syncfs(V9fsState *s, V9fsPDU *pdu)
> +{
> +int err;
> +int32_t fid;
> +size_t offset = 7;
> +V9fsFidState *fidp;
> +
> +pdu_unmarshal(pdu, offset, "d", &fid);
> +fidp = lookup_fid(s, fid);
> +if (fidp == NULL) {
> +err = -ENOENT;
> +v9fs_post_do_syncfs(s, pdu, err);
> +return;
> +}
> +/*
> + * We don't have per file system syncfs
> + * So just return success
> + */
> +err = 0;
How about
err = 0
if (fidp == NULL)
err = -ENOENT
> +v9fs_post_do_syncfs(s, pdu, err);
> +}
> +
> static void v9fs_clunk(V9fsState *s, V9fsPDU *pdu)
> {
> int32_t fid;
> @@ -3676,6 +3706,7 @@ static pdu_handler_t *pdu_handlers[] = {
> [P9_TWALK] = v9fs_walk,
> [P9_TCLUNK] = v9fs_clunk,
> [P9_TFSYNC] = v9fs_fsync,
> +[P9_TSYNCFS] = v9fs_syncfs,
> [P9_TOPEN] = v9fs_open,
> [P9_TREAD] = v9fs_read,
> #if 0
> diff --git a/hw/9pfs/virtio-9p.h b/hw/9pfs/virtio-9p.h
> index 82b4252..b2cd24b 100644
> --- a/hw/9pfs/virtio-9p.h
> +++ b/hw/9pfs/virtio-9p.h
> @@ -13,6 +13,8 @@
> #define VIRTIO_9P_MOUNT_TAG 0
>
> enum {
> +P9_TSYNCFS = 0,
> +P9_RSYNCFS,
> P9_TLERROR = 6,
> P9_RLERROR,
> P9_TSTATFS = 8,
[Qemu-devel] [PATCH v2] fix vnc regression
This patch fix the following two regressions:
1. we should use bitmap_set() and bitmap_clear() to replace vnc_set_bits().
2. The unit of bitmap_intersects()'third parameter is bit, not words.
But we pass the num of words to bitmap_intersects().
Changes from v1 to v2:
1. fix the third argument of bitmap_clear()
Signed-off-by: Wen Congyang
---
ui/vnc.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/ui/vnc.c b/ui/vnc.c
index 610f884..655aae6 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -1655,7 +1655,11 @@ static void framebuffer_update_request(VncState *vs, int
incremental,
if (!incremental) {
vs->force_update = 1;
for (i = 0; i < h; i++) {
-bitmap_set(vs->dirty[y_position + i], x_position / 16, w / 16);
+bitmap_set(vs->dirty[y_position + i], 0,
+ (ds_get_width(vs->ds) / 16));
+bitmap_clear(vs->dirty[y_position + i], (ds_get_width(vs->ds) /
16),
+ VNC_DIRTY_WORDS * BITS_PER_LONG -
+ (ds_get_width(vs->ds) / 16));
}
}
}
@@ -2406,7 +2410,8 @@ static int vnc_refresh_server_surface(VncDisplay *vd)
guest_row = vd->guest.ds->data;
server_row = vd->server->data;
for (y = 0; y < vd->guest.ds->height; y++) {
-if (bitmap_intersects(vd->guest.dirty[y], width_mask,
VNC_DIRTY_WORDS)) {
+if (bitmap_intersects(vd->guest.dirty[y], width_mask,
+VNC_DIRTY_WORDS * BITS_PER_LONG)) {
int x;
uint8_t *guest_ptr;
uint8_t *server_ptr;
--
1.7.1
Re: [Qemu-devel] [RFC PATCH -V1 1/4] hw/9pfs: Add file descriptor reclaim support
On 2/5/2011 10:08 AM, Aneesh Kumar K.V wrote:
> This add file descriptor recliam to 9p server
Please split it into two patches.
1. Introducing fsmap.
2. Introducing the reclaim mechanism.
Concern: With this we will be traversing the whole fid list for many operations
.. how is
the performance impact?
-Jv
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> hw/9pfs/virtio-9p.c | 424 +++---
> hw/9pfs/virtio-9p.h | 22 ++-
> 2 files changed, 278 insertions(+), 168 deletions(-)
>
> diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
> index 27e7750..86a32a4 100644
> --- a/hw/9pfs/virtio-9p.c
> +++ b/hw/9pfs/virtio-9p.c
> @@ -20,6 +20,7 @@
> #include "virtio-9p-xattr.h"
>
> int debug_9p_pdu;
> +static void v9fs_reclaim_fd(V9fsState *s);
>
> enum {
> Oread = 0x00,
> @@ -107,7 +108,12 @@ static int v9fs_do_closedir(V9fsState *s, DIR *dir)
>
> static int v9fs_do_open(V9fsState *s, V9fsString *path, int flags)
> {
> -return s->ops->open(&s->ctx, path->data, flags);
> +int fd;
> +fd = s->ops->open(&s->ctx, path->data, flags);
> +if (fd > P9_FD_RECLAIM_THRES) {
> +v9fs_reclaim_fd(s);
> +}
> +return fd;
> }
>
> static DIR *v9fs_do_opendir(V9fsState *s, V9fsString *path)
> @@ -188,6 +194,7 @@ static int v9fs_do_fstat(V9fsState *s, int fd, struct
> stat *stbuf)
> static int v9fs_do_open2(V9fsState *s, char *fullname, uid_t uid, gid_t gid,
> int flags, int mode)
> {
> +int fd;
> FsCred cred;
>
> cred_init(&cred);
> @@ -196,7 +203,11 @@ static int v9fs_do_open2(V9fsState *s, char *fullname,
> uid_t uid, gid_t gid,
> cred.fc_mode = mode & 0;
> flags = flags;
>
> -return s->ops->open2(&s->ctx, fullname, flags, &cred);
> +fd = s->ops->open2(&s->ctx, fullname, flags, &cred);
> +if (fd > P9_FD_RECLAIM_THRES) {
> +v9fs_reclaim_fd(s);
> +}
> +return fd;
> }
>
> static int v9fs_do_symlink(V9fsState *s, V9fsFidState *fidp,
> @@ -434,6 +445,23 @@ static V9fsFidState *lookup_fid(V9fsState *s, int32_t
> fid)
>
> for (f = s->fid_list; f; f = f->next) {
> if (f->fid == fid) {
> +/*
> + * check whether we need to reopen the
> + * file. We might have closed the fd
> + * while trying to free up some file
> + * descriptors.
> + */
> +if (f->fsmap.fid_type == P9_FID_FILE) {
> +/* FIXME!! should we remember the open flags ?*/
> +if (f->fsmap.fs.fd == -1) {
> +f->fsmap.fs.fd = v9fs_do_open(s, &f->fsmap.path, O_RDWR);
> +}
> +}
> +/*
> + * Mark the fid as referenced so that the LRU
> + * reclaim won't close the file descriptor
> + */
> +f->fsmap.flags |= FID_REFERENCED;
> return f;
> }
> }
> @@ -453,7 +481,7 @@ static V9fsFidState *alloc_fid(V9fsState *s, int32_t fid)
> f = qemu_mallocz(sizeof(V9fsFidState));
>
> f->fid = fid;
> -f->fid_type = P9_FID_NONE;
> +f->fsmap.fid_type = P9_FID_NONE;
>
> f->next = s->fid_list;
> s->fid_list = f;
> @@ -461,11 +489,67 @@ static V9fsFidState *alloc_fid(V9fsState *s, int32_t
> fid)
> return f;
> }
>
> +static void v9fs_reclaim_fd(V9fsState *s)
> +{
> +int reclaim_count = 0;
> +V9fsFidState *f;
> +
> +for (f = s->fid_list; f; f = f->next) {
> +/*
> + * Unlink fids cannot be reclaimed. Check
> + * for them and skip them
> + */
> +if (f->fsmap.flags & FID_NON_RECLAIMABLE) {
> +continue;
> +}
> +/*
> + * if it is a recently referenced fid
> + * we leave the fid untouched and clear the
> + * reference bit. We come back to it later
> + * in the next iteration. (a simple LRU without
> + * moving list elements around)
> + */
> +if (f->fsmap.flags & FID_REFERENCED) {
> +f->fsmap.flags &= ~FID_REFERENCED;
> +continue;
> +}
> +/*
> + * reclaim fd, by closing the file descriptors
> + */
> +if (f->fsmap.fid_type == P9_FID_FILE) {
> +if (f->fsmap.fs.fd != -1) {
> +v9fs_do_close(s, f->fsmap.fs.fd);
> +f->fsmap.fs.fd = -1;
> +reclaim_count++;
> +}
> +}
> +if (reclaim_count >= P9_FD_RECLAIM_THRES/2) {
> +break;
> +}
> +}
> +}
> +
> +static void v9fs_mark_fids_unreclaim(V9fsState *s, V9fsString *str)
> +{
> +V9fsFidState *fidp;
> +for (fidp = s->fid_list; fidp; fidp = fidp->next) {
> +if (!strcmp(fidp->fsmap.path.data, str->data)) {
> +/* Mark the fid non reclaimable. */
> +fidp->fsmap.flags |= FID_NON_RECLAIMABLE;
> +/* reopen the file if already closed */
> +
Re: [Qemu-devel] [PATCH] vnc: Fix heap corruption
At 03/01/2011 05:34 AM, Stefan Weil Write: > Commit bc2429b9174ac2d3c56b7fd35884b0d89ec7fb02 introduced > a severe bug (heap corruption). > > bitmap_clear was called with a wrong argument > which caused out-of-bound writes to width_mask. > > This bug was detected with QEMU running on windows. > It also occurs with wine: > > *** stack smashing detected ***: terminated > wine: Unhandled illegal instruction at address 0x6115c7 (thread 0009), > starting debugger... > > The bug is not windows specific! > > Cc: Corentin Chary > Cc: Anthony Liguori > Signed-off-by: Stefan Weil > --- > ui/vnc.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/ui/vnc.c b/ui/vnc.c > index af55156..89f71da 100644 > --- a/ui/vnc.c > +++ b/ui/vnc.c > @@ -2401,7 +2401,7 @@ static int vnc_refresh_server_surface(VncDisplay *vd) > */ > bitmap_set(width_mask, 0, (ds_get_width(vd->ds) / 16)); > bitmap_clear(width_mask, (ds_get_width(vd->ds) / 16), > - VNC_DIRTY_WORDS * BITS_PER_LONG); > + (VNC_MAX_WIDTH - ds_get_width(vd->ds)) / 16); The third argument of bitmap_clear() is number of bits to be cleared, but we pass the end bits to be cleared to bitmap_clear(). I think we can fix this bug like this(I can not reproduce this bug, so I do not know whether it can fix this bug): diff --git a/ui/vnc.c b/ui/vnc.c index fff34af..6d54661 100644 --- a/ui/vnc.c +++ b/ui/vnc.c @@ -2404,7 +2404,7 @@ static int vnc_refresh_server_surface(VncDisplay *vd) */ bitmap_set(width_mask, 0, (ds_get_width(vd->ds) / 16)); bitmap_clear(width_mask, (ds_get_width(vd->ds) / 16), - VNC_DIRTY_WORDS * BITS_PER_LONG); + VNC_DIRTY_WORDS * BITS_PER_LONG - (ds_get_width(vd->ds) / 16)); cmp_bytes = 16 * ds_get_bytes_per_pixel(vd->ds); guest_row = vd->guest.ds->data; server_row = vd->server->data; Thanks Wen Congyang > cmp_bytes = 16 * ds_get_bytes_per_pixel(vd->ds); > guest_row = vd->guest.ds->data; > server_row = vd->server->data;
Re: [Qemu-devel] 68k and BeBox (was SymbianOS, MeeGO, WebOS and QEMU)
Le 1 mars 2011 à 01:18, Natalia Portillo a écrit : >> Well, most of those emulators do not support the required mmu, except ARAnyM >> (and their mmu patch was backported to UAE I think). > That's the main problem, but first of all in QEMU there is the need for > complete pre-Coldfire 68ks, as well as the modular support for FPUs and MMU > (Sun and Apple's Lisa) Yeah old Sun stuff used their own mmu due to missing support in pre-020 for some insn restart. > Currently the fastest ones would be BeBox, Mac68k and NeXT machines, because > almost all devices are already emulated, but the assembly itself, firmware > and CPU/FPU/MMU in case of 68k. IIRC the Mac68k hardware is quite obscure and model-dependant... but EMILE and BasiliskII should say enough. Just posted my BeBox patch btw. >> A/UX would be fun to run :-) >> There used to be UNIX for Atari TT also IIRC, though not sure it was ever >> published. > There is a binary dump somewhere, I may have it. So should I, just can't recall where I left it. François.
Re: [Qemu-devel] 68k and BeBox (was SymbianOS, MeeGO, WebOS and QEMU)
Hi, > Indeed, and I'd love to get Haiku to boot on a NeXT :-) I'd love to boot NeXTStep/m68k even on emulation. >> (Unless your Atari ST and Amiga emulation pretends to support things no >> other does, like Amiga UNIX, Apple UNIX) > > Well, most of those emulators do not support the required mmu, except ARAnyM > (and their mmu patch was backported to UAE I think). That's the main problem, but first of all in QEMU there is the need for complete pre-Coldfire 68ks, as well as the modular support for FPUs and MMU (Sun and Apple's Lisa) Currently the fastest ones would be BeBox, Mac68k and NeXT machines, because almost all devices are already emulated, but the assembly itself, firmware and CPU/FPU/MMU in case of 68k. > A/UX would be fun to run :-) > There used to be UNIX for Atari TT also IIRC, though not sure it was ever > published. There is a binary dump somewhere, I may have it. Regards, Natalia Portillo
[Qemu-devel] [RFC][PATCH] Preliminary BeBox support
Since Natalia raised the subject I though I'd post my current patch for the
BeBox support.
I think the loader stuff can probably be committed already with some cleanup.
The rest is mostly a copy of the prep file with tweaks and needs more work.
The boot nub images can be extracted with this script:
http://revolf.free.fr/beos/extract_bebox_images.sh
Running -M bebox -bios bootnub.image makes it try to probe the PCI bridge for
now.
Comments ?
François.
diff --git a/Makefile.target b/Makefile.target
index 220589e..a41f792 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -227,6 +227,7 @@ obj-ppc-y += vga.o
# PREP target
obj-ppc-y += i8259.o mc146818rtc.o
obj-ppc-y += ppc_prep.o
+obj-ppc-y += ppc_bebox.o
# OldWorld PowerMac
obj-ppc-y += ppc_oldworld.o
# NewWorld PowerMac
diff --git a/hw/loader.c b/hw/loader.c
index 35d792e..7dc759a 100644
--- a/hw/loader.c
+++ b/hw/loader.c
@@ -515,6 +515,142 @@ out:
return ret;
}
+/* BeBox ROM image loader */
+
+struct bebox_image_header {
+ uint32_t entry;
+ uint32_t TOC;
+ uint32_t serial_num[2];
+ uint32_t checksum;
+ uint32_t addr;
+ uint32_t size;
+ uint32_t segtable;
+ char date[32];
+};
+
+struct bebox_image_section {
+ uint32_t size;
+ uint32_t offset;
+ uint32_t addr;
+ uint32_t zsize;
+};
+
+static void bswap_bebox_header(struct bebox_image_header *hdr)
+{
+#ifndef HOST_WORDS_BIGENDIAN
+bswap32s(&hdr->entry);
+bswap32s(&hdr->TOC);
+bswap32s(&hdr->serial_num[0]);
+bswap32s(&hdr->serial_num[1]);
+bswap32s(&hdr->checksum);
+bswap32s(&hdr->addr);
+bswap32s(&hdr->size);
+bswap32s(&hdr->segtable);
+#endif
+}
+
+static void bswap_bebox_section(struct bebox_image_section *sec)
+{
+#ifndef HOST_WORDS_BIGENDIAN
+bswap32s(&sec->size);
+bswap32s(&sec->addr);
+bswap32s(&sec->offset);
+bswap32s(&sec->zsize);
+#endif
+}
+
+/* Load a BeBox nub image. */
+int load_bebox(const char *filename, target_phys_addr_t *ep,
+ target_phys_addr_t *ds, target_phys_addr_t *loadaddr)
+{
+int fd;
+int size;
+ int i;
+struct bebox_image_header h;
+struct bebox_image_header *hdr = &h;
+struct bebox_image_section s;
+struct bebox_image_section *sec = &s;
+uint8_t *data = NULL;
+int ret = -1;
+fprintf(stderr, "%s(%s)\n", __FUNCTION__, filename);
+fd = open(filename, O_RDONLY | O_BINARY);
+if (fd < 0)
+return -1;
+
+size = read(fd, hdr, sizeof(uboot_image_header_t));
+if (size < sizeof(uboot_image_header_t))
+goto out;
+
+fprintf(stderr, "%s: %d read\n", __FUNCTION__, size);
+bswap_bebox_header(hdr);
+
+fprintf(stderr, "%s: entry %08x addr %08x\n", __FUNCTION__, hdr->entry,
hdr->addr);
+ /* XXX: all known images load there, but... */
+if (hdr->entry != 0xfff00100)
+goto out;
+if (hdr->addr != 0xfff0)
+goto out;
+ /* date field seems be ASCII, ends with \n and \0 padded */
+ for (i = 0; i < 32; i++) {
+ if (!qemu_isprint(hdr->date[i]))
+ break;
+ }
+ if (i >= 32 || hdr->date[i] != '\n')
+ goto out;
+ i++;
+ for (; i < 32; i++) {
+ if (hdr->date[i] != '\0')
+ goto out;
+ }
+
+ /* TODO: check sum */
+
+fprintf(stderr, "%s: hdr ok\n", __FUNCTION__);
+/* it seems the image is supposed to be loaded at hdr->addr,
+* then the primary boot nub relocates the sections itself, copying
some in RAM.
+ * But we don't have the image for the primary boot nub, so we do it on
our own. */
+
+*ep = hdr->entry;
+*ds = hdr->TOC;
+data = qemu_malloc(hdr->size);
+
+ /* we also include the header when flashing */
+ lseek(fd, 0, SEEK_SET);
+
+if (read(fd, data, hdr->size) != hdr->size) {
+fprintf(stderr, "Error reading file\n");
+goto out;
+}
+
+rom_add_blob_fixed(filename, data, hdr->size, hdr->addr);
+
+if (loadaddr)
+*loadaddr = hdr->addr;
+
+fprintf(stderr, "%s: loaded @ %08x\n", __FUNCTION__, *loadaddr);
+
+ /* relocate sections */
+ for (i = 0; ; i++) {
+ memcpy(sec, data + hdr->segtable + i * sizeof(*sec),
sizeof(*sec));
+ bswap_bebox_section(sec);
+fprintf(stderr, "%s: section: offset %08x addr %08x size %d zsize %d \n",
__FUNCTION__, sec->offset, sec->addr, sec->size, sec->zsize);
+ if (sec->size == 0 && sec->zsize == 0)
+ break;
+ /* already there */
+ if (sec->addr == -1 || sec->addr == (hdr->addr + sec->offset))
+ continue;
+ rom_add_blob_z(filename, data + sec->offset, sec->size,
sec->addr, sec->zsize);
+ }
+
+ret = hdr->size;
+
+out:
+if (data)
+qemu_free(data);
+close(fd);
+return ret;
+}
+
/*
* Functions for reboot-persistent memory regions.
* - used for vga bios an
[Qemu-devel] Re: KVM call agenda for Mars 1
On Feb 28, 2011 7:38 AM, "Juan Quintela" wrote: > > > Please send in any agenda items you are interested in covering. FYI, I cannot attend due to an all day meeting. Regards, Anthony Liguori > Thanks, Juan. > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: SymbianOS, MeeGO, WebOS and QEMU
Le 1 mars 2011 à 00:19, Natalia Portillo a écrit : >> I see someone wants BeBox support. >> I already started on this but it doesn't do much yet. > Loading Be's firmware or with a custom one? I wrote a loader for their boot nub. It currently starts by probing the PCI bridge and that's about it. The boot nub can be extracted from the floppy images from there: http://www.bebox.nu/tech.php?s=tech/bootROM/download with this script: http://revolf.free.fr/beos/extract_bebox_images.sh I shall post a patch someday. >> There are also several other 68k machines that could be fun to support once >> the m68k branch is in shape in addition to NeXT, like Atari ST/Falcon and >> Amiga, and there are existing emulators for those to look at. > Well, there are thousands of 68k machines, however the ones nobody emulates > are of more interest. Indeed, and I'd love to get Haiku to boot on a NeXT :-) > (Unless your Atari ST and Amiga emulation pretends to support things no other > does, like Amiga UNIX, Apple UNIX) Well, most of those emulators do not support the required mmu, except ARAnyM (and their mmu patch was backported to UAE I think). A/UX would be fun to run :-) There used to be UNIX for Atari TT also IIRC, though not sure it was ever published. >> And I need 68k emulators to finish my Haiku port :-) > Interesting http://www.haiku-os.org/blog/mmu_man/2008-08-03/helping_on_m68k Some recent stuff: http://revolf.free.fr/beos/shots/shot_haiku_loader_m68k_amiga_vs_atari.png http://revolf.free.fr/beos/shots/shot_haiku_loader_atari_m68k_splash_001.png François.
Re: [Qemu-devel] Re: SymbianOS, MeeGO, WebOS and QEMU
Hi, El 28/02/2011, a las 22:57, François Revol escribió: > > Le 28 févr. 2011 à 20:54, qemu-devel-requ...@nongnu.org a écrit : > >> I proposed on GSoC 2010 to cleanup and finish the WIP that was done on 0.9.0 >> for emulation Acorn Archimedes platform. >> It was going to be mentored by Paul Brook but no one took the project, so >> the proposal is still up. >> I cannot mentor it as I know nothing about ARM. >> >> Check on >> http://wiki.qemu.org/Google_Summer_of_Code_2011#Enhance.2C_update_and_integrate_Acorn_Archimedes_system_emulation > > Oh, interesting list there... > > I see someone wants BeBox support. > I already started on this but it doesn't do much yet. Loading Be's firmware or with a custom one? > There are also several other 68k machines that could be fun to support once > the m68k branch is in shape in addition to NeXT, like Atari ST/Falcon and > Amiga, and there are existing emulators for those to look at. Well, there are thousands of 68k machines, however the ones nobody emulates are of more interest. (Unless your Atari ST and Amiga emulation pretends to support things no other does, like Amiga UNIX, Apple UNIX) > And I need 68k emulators to finish my Haiku port :-) Interesting Regards, Natalia Portillo
[Qemu-devel] Re: SymbianOS, MeeGO, WebOS and QEMU
Le 28 févr. 2011 à 20:54, qemu-devel-requ...@nongnu.org a écrit : > I proposed on GSoC 2010 to cleanup and finish the WIP that was done on 0.9.0 > for emulation Acorn Archimedes platform. > It was going to be mentored by Paul Brook but no one took the project, so the > proposal is still up. > I cannot mentor it as I know nothing about ARM. > > Check on > http://wiki.qemu.org/Google_Summer_of_Code_2011#Enhance.2C_update_and_integrate_Acorn_Archimedes_system_emulation Oh, interesting list there... I see someone wants BeBox support. I already started on this but it doesn't do much yet. There are also several other 68k machines that could be fun to support once the m68k branch is in shape in addition to NeXT, like Atari ST/Falcon and Amiga, and there are existing emulators for those to look at. And I need 68k emulators to finish my Haiku port :-) François.
[Qemu-devel] [PATCH] vnc: Fix heap corruption
Commit bc2429b9174ac2d3c56b7fd35884b0d89ec7fb02 introduced a severe bug (heap corruption). bitmap_clear was called with a wrong argument which caused out-of-bound writes to width_mask. This bug was detected with QEMU running on windows. It also occurs with wine: *** stack smashing detected ***: terminated wine: Unhandled illegal instruction at address 0x6115c7 (thread 0009), starting debugger... The bug is not windows specific! Cc: Corentin Chary Cc: Anthony Liguori Signed-off-by: Stefan Weil --- ui/vnc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/ui/vnc.c b/ui/vnc.c index af55156..89f71da 100644 --- a/ui/vnc.c +++ b/ui/vnc.c @@ -2401,7 +2401,7 @@ static int vnc_refresh_server_surface(VncDisplay *vd) */ bitmap_set(width_mask, 0, (ds_get_width(vd->ds) / 16)); bitmap_clear(width_mask, (ds_get_width(vd->ds) / 16), - VNC_DIRTY_WORDS * BITS_PER_LONG); + (VNC_MAX_WIDTH - ds_get_width(vd->ds)) / 16); cmp_bytes = 16 * ds_get_bytes_per_pixel(vd->ds); guest_row = vd->guest.ds->data; server_row = vd->server->data; -- 1.7.2.3
[Qemu-devel] Re: Fix build breakage to kvm on ppc
On 2011-02-28 11:49, David Gibson wrote:
> Recent changes to the generic kvm support code broke compile of kvm
> for ppc. The patch below fixes the errors by adjusting types in the
> ppc code, and adding a missing #ifdef.
>
> Please apply.
>
> Signed-off-by: David Gibson
>
> ---
> kvm-all.c|2 ++
> target-ppc/kvm.c |6 +++---
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/kvm-all.c b/kvm-all.c
> index e6a7de4..fb44e2e 100644
> --- a/kvm-all.c
> +++ b/kvm-all.c
> @@ -998,7 +998,9 @@ int kvm_cpu_exec(CPUState *env)
> }
> ret = EXCP_INTERRUPT;
>
> +#ifdef KVM_CAP_SET_GUEST_DEBUG
> out:
> +#endif /* KVM_CAP_SET_GUEST_DEBUG */
Yeah, another non-x86 breakage. But this made me think about the main
loop again, and the result will move any related reasons for the #ifdef
into arch code.
> env->exit_request = 0;
> cpu_single_env = NULL;
> return ret;
> diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
> index 04b94a3..4fa1be3 100644
> --- a/target-ppc/kvm.c
> +++ b/target-ppc/kvm.c
> @@ -223,7 +223,7 @@ int kvmppc_set_interrupt(CPUState *env, int irq, int
> level)
> #define PPC_INPUT_INT PPC6xx_INPUT_INT
> #endif
>
> -int kvm_arch_pre_run(CPUState *env, struct kvm_run *run)
> +void kvm_arch_pre_run(CPUState *env, struct kvm_run *run)
> {
> int r;
> unsigned irq;
> @@ -254,15 +254,15 @@ int kvm_arch_pre_run(CPUState *env, struct kvm_run *run)
> /* We don't know if there are more interrupts pending after this.
> However,
> * the guest will return to userspace in the course of handling this one
> * anyways, so we will get a chance to deliver the rest. */
> -return 0;
> }
>
> void kvm_arch_post_run(CPUState *env, struct kvm_run *run)
> {
> }
>
> -void kvm_arch_process_irqchip_events(CPUState *env)
> +int kvm_arch_process_irqchip_events(CPUState *env)
> {
> +return 0;
> }
>
> static int kvmppc_handle_halt(CPUState *env)
>
That other fix is already filed for uq/master.
Thanks for reporting,
Jan
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] Re: KVM call agenda for Jan 25
On Sunday 27 February 2011 04:19 PM, Stefan Hajnoczi wrote: On Sat, Feb 26, 2011 at 9:50 PM, Dushyant Bansal wrote: Disk block size is usually 512 bytes and in qemu-img, sector size is also 512B. And, this change would copy n sectors even if only one of them actually contains data (while cp checks and copies one block(=sector) at a time). Therefore, it will end up writing more data than cp. cp(1) from GNU coreutils 8.5 works in units of 32 KB on my system. It reads 32 KB and checks for all zeroes. If there are all zeroes, it seeks ahead 32 KB in the output file. Otherwise it writes the entire 32 KB. You can check what cp(1) is doing using strace(1). yes, you are right. I was reading from a much older coreutils source. virtual size: 10G (10737418240 bytes) disk size: 569M convert-> original time0m52.522s convert-> modified (resultant disk size: 5.3G) time2m12.744s cp time0m51.724s (same disk size) --- virtual size: 10G (10737418240 bytes) disk size: 3.6G convert-> original time1m52.249s convert-> modified (resultant disk size: 7.1G) time3m2.891s cp time1m55.320s (same disk size) --- In these results, we can see that resultant disk size has increased. If I'm reading this correctly then qemu-img convert is within a few seconds of cp(1) for you? I have collected and attached some more time results for different operations on a 2.2G image. qemu-img convert is close to cp. qemu(modified): IO_BUF_SIZE = (2 * 1024 ) if any sector is non-null, write all sectors -- Dushyant results.xls Description: MS-Excel spreadsheet
[Qemu-devel] Re: GSoC 2011 project ideas
On 2011-02-28 19:51, Natalia Portillo wrote: > I have added my 2010 still valid projects (all), and three more. > > I also added myself as mentor for the USB projects, as I recently got > experience on how the QEMU's USB stack works. Great! Interesting to hear that you already have started with webcam emulation. Also Firewire would be a cool project (better hurry implementing it in QEMU as long as there is still real hardware around ;) ). > > One of the projects I suggest, implementing USB 3.0 XHCI may need to be > merged with clean up of Gerd's USB 2.0 EHCI emulation patches. Alex told me about plans for working on XHCI, and he also set up first contacts to Intel on this (e.g. to clarify the legal aspects when using that spec). I think he's not in the house ATM, but he will likely comment on this once he's back. Besides that, I think even basic XHCI emulation might be a bit more than a GSoC project - unless XHCI became much simpler than EHCI or we find a really advanced student. > I think just cleaning up for mainstream the patches done by Gerd is too > simple and fast-to-be-done for GSoC, but as it's Jan's proposition I will not > merge them. > > Jan if you agree with me, feel free to merge both projects, I'll mentor it. As I said, I didn't find Gerd's tree to asses the remaining todos. It's likely more than "just merging", but if it isn't and this is not worth a project of its own, even better! EHCI support in QEMU is overdue. Jan signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] SymbianOS, MeeGO, WebOS and QEMU
Hi Peter, El 28/02/2011, a las 19:15, Peter Maydell escribió: > On 28 February 2011 18:53, Natalia Portillo wrote: >> Last time I checked SymbianOS source repository I found references to QEMU. >> >> Are they using QEMU for the simulator? >> And for MeeGO? >> >> May HP also be using it for WebOS? >> >> We may propose putting their modifications upstream as a GSoC 2011 project >> if it's the case. > > Meego uses QEMU, yes: there's a git repo here: > http://meego.gitorious.org/qemu-maemo > > Upstreaming the OMAP3 support from that tree is on my TODO list, > but if anybody actually wants to do it as a GSOC project that's > fine with me. (Personally I would classify it as more of a chore > than a fun project :-)) Feel free to add it to the GSoC projects list :p > If anybody has a proposal for an interesting ARM qemu related > project I might be able to act as mentor for it (no promises > at this point, though.) I proposed on GSoC 2010 to cleanup and finish the WIP that was done on 0.9.0 for emulation Acorn Archimedes platform. It was going to be mentored by Paul Brook but no one took the project, so the proposal is still up. I cannot mentor it as I know nothing about ARM. Check on http://wiki.qemu.org/Google_Summer_of_Code_2011#Enhance.2C_update_and_integrate_Acorn_Archimedes_system_emulation Regards, Natalia Portillo
[Qemu-devel] [Bug 638955] Re: emulated netcards don't work with recent sunos kernel
Hi all, I can confirm this bug, on latest openindiana-148 and qemu-kvm 0.13.0 you cannot even ping the virtualization host. With qemu-kvm-0.14.0 (just released!) you CAN ping the host: this is already an improvement. HOWEVER biggest bug is still there: if you log in to the openindiana machine via ssh and do "dmesg" or "netstat" or some other command which ouptuts a lot of text, the tcp socket will hang (well say it hangs once every 3 attempts) forever. Going with tcpdump -e from within the guest, I have identified that the problem is when a big enough packet is outputed. I tried a few times with dmesg, and as soon as the tcp packet reaches the following length: 18:38:28.340097 52:54:69:b5:89:11 (oui Unknown) > 00:19:b9:81:2c:52 (oui Unknown), ethertype IPv4 (0x0800), length 1514: 192.168.7.38.ssh > 192.168.7.52.59008: Flags [.], ack 2824, win 64436, options [nop,nop,TS val 27488132 ecr 6063255], length 1448 it cannot get through. Then the IP stack tries and retries to send the same identical packet, but there will never be any reply from the other side. Finally the socket is torn down. I have bridged networking for the VM. My bridge is a normal linux bridge br0 with MTU 1500. Has MTU anything to do with all this? Is it a linux-bridge bug or a qemu-kvm bug? Please fix this, solaris is important for its ZFS. Thank you -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/638955 Title: emulated netcards don't work with recent sunos kernel Status in QEMU: New Bug description: hi there, i'm using qemu-kvm backend in version: # qemu-kvm -version QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5), Copyright (c) 2003-2008 Fabrice Bellard and there are just *not working any of model=$type with combinations of recent sunos (solaris, openindiana, opensolaris, ..) .. you can download for testing purposes iso from here: http://dlc- origin.openindiana.org/isos/147/ or from here: http://genunix.org/distributions/indiana/ << osol and oi are also bubuntu-like *live cds, so no need to bother with installing behaviour is as follows: e1000 - receiving doesn't work, transmitting works .. dladm (tool for handle ethers) shows that is all ok, correct mode is loaded up, it just seems like this driver works at 100% but .. rtl8169|pcnet - works in 10Mbit mode with several other issues like high cpu utilization and so .. dladm is unable to recognize options for this kind of -nic others - just don't work .. i experienced this issue several times in past .. woraround was, that rtl8169 worked so-so .. with recent sunos kernel it doesn't. it's easy to reproduce, this is why i'm not putting here more then launching script for my virtual machine: # cat openindiana.sh qemu-kvm -hda /home/kvm/openindiana/openindiana.img -m 2048 -localtime -cdrom /home/kvm/+images/oi-dev-147-x86.iso -boot d \ -vga std -vnc :9 -k en-us -monitor unix:/home/kvm/openindiana/instance,server,nowait \ -net nic,model=e1000,vlan=1 -net tap,ifname=oi0,script=no,vlan=1 & sleep 2; ip l set oi0 up; ip a a 192.168.99.9/24 dev oi0; regards by daniel
Re: [Qemu-devel] SymbianOS, MeeGO, WebOS and QEMU
On 28 February 2011 18:53, Natalia Portillo wrote: > Last time I checked SymbianOS source repository I found references to QEMU. > > Are they using QEMU for the simulator? > And for MeeGO? > > May HP also be using it for WebOS? > > We may propose putting their modifications upstream as a GSoC 2011 project if > it's the case. Meego uses QEMU, yes: there's a git repo here: http://meego.gitorious.org/qemu-maemo Upstreaming the OMAP3 support from that tree is on my TODO list, but if anybody actually wants to do it as a GSOC project that's fine with me. (Personally I would classify it as more of a chore than a fun project :-)) If anybody has a proposal for an interesting ARM qemu related project I might be able to act as mentor for it (no promises at this point, though.) -- PMM
Re: [Qemu-devel] [patch 2/3] Add support for live block copy
On Sat, Feb 26, 2011 at 07:45:44AM -0600, Anthony Liguori wrote: > >>>+- "commit_filename": target commit filename (json-string, optional) > >>I think we should drop this. > >Why? Sorry but this can't wait for non-config persistent storage. This > >mistake was made in the past with irqchip for example, lets not repeat > >it. > > > >Its OK to deprecate "commit_filename" in favour of its location in > >non-config persistent storage. > > > >Its not the end of the world for a mgmt app to handle change (not saying > >its not a good principle) such as this. > > Even as a one off, it's not a very good solution to the problem. > We'd be way better of just having nothing here than using the commit > file. What are the semantics of a half written file? How does a > management tool detect a half written file? If the commit file contains the full commit message, it can be considered valid. Otherwise, it should be considered invalid. Stopping the guest and waiting for mgmt to issue a continue command is a solution, but it has drawbacks introduced by reliance on mgmt app (what if mgmt app crashes, latency, etc). But it seems that it is preferred over a commit file. Addressing the other comments in the meantime, thanks for input.
Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy
On Mon, Feb 28, 2011 at 07:47:13PM +0200, Avi Kivity wrote: > On 02/28/2011 07:33 PM, Anthony Liguori wrote: > > > >> > >> You're just ignoring what I've written. > > > >No, you're just impervious to my subtle attempt to refocus the > >discussion on solving a practical problem. > > > >There's a lot of good, reasonably straight forward changes we can > >make that have a high return on investment. > > > > Is making qemu the authoritative source of configuration information > a straightforward change? Is the return on it high? Is the > investment low? > > "No" to all three (ignoring for the moment whether it is good or > not, which we were debating). > > >The only suggestion I'm making beyond Marcelo's original patch is > >that we use a structured format and that we make it possible to > >use the same file to solve this problem in multiple places. > > > > No, you're suggesting a lot more than that. > > >I don't think this creates a fundamental break in how management > >tools interact with QEMU. I don't think introducing RAID support > >in the block layer is a reasonable alternative. > > > > > > Why not? > > Something that avoids the whole state thing altogether: > > - instead of atomically switching when live copy is done, keep on > issuing writes to both the origin and the live copy > - issue a notification to management > - management receives the notification, and issues an atomic > blockdev switch command How do you know if QEMU performed the switch or not? That is, how can the switch command be atomic? > this is really the RAID-1 solution but without the state file > (credit Dor). An advantage is that there is no additional latency > when trying to catch up to the dirty bitmap. So you're implementing a virtual block driver not visible to the user as an image format. The image format would allow storage of persistent copy progress, etc. so you lose all that. All of that to avoid introducing a commit file which is not part of global qemu state.
[Qemu-devel] SymbianOS, MeeGO, WebOS and QEMU
Hi all, Last time I checked SymbianOS source repository I found references to QEMU. Are they using QEMU for the simulator? And for MeeGO? May HP also be using it for WebOS? We may propose putting their modifications upstream as a GSoC 2011 project if it's the case. Regards, Natalia Portillo
[Qemu-devel] Re: GSoC 2011 project ideas
I have added my 2010 still valid projects (all), and three more. I also added myself as mentor for the USB projects, as I recently got experience on how the QEMU's USB stack works. One of the projects I suggest, implementing USB 3.0 XHCI may need to be merged with clean up of Gerd's USB 2.0 EHCI emulation patches. I think just cleaning up for mainstream the patches done by Gerd is too simple and fast-to-be-done for GSoC, but as it's Jan's proposition I will not merge them. Jan if you agree with me, feel free to merge both projects, I'll mentor it. Regards, Natalia Portillo
Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy
On Feb 28, 2011 11:47 AM, "Avi Kivity" wrote: > > On 02/28/2011 07:33 PM, Anthony Liguori wrote: >> >> >> > >> > You're just ignoring what I've written. >> >> No, you're just impervious to my subtle attempt to refocus the discussion on solving a practical problem. >> >> There's a lot of good, reasonably straight forward changes we can make that have a high return on investment. >> > > Is making qemu the authoritative source of configuration information a straightforward change? Is the return on it high? Is the investment low? I think this is where we fundamentally disagree. My position is that QEMU is already the authoritative source. Having a state file doesn't change anything. Do a hot unplug of a network device with upstream libvirt with acpiphp unloaded, consult libvirt and then consult the monitor to see who has the right view of the guests config. To me, that's the definition of authoritative. > "No" to all three (ignoring for the moment whether it is good or not, which we were debating). > > >> The only suggestion I'm making beyond Marcelo's original patch is that we use a structured format and that we make it possible to use the same file to solve this problem in multiple places. >> > > No, you're suggesting a lot more than that. That's exactly what I'm suggesting from a technical perspective. >> I don't think this creates a fundamental break in how management tools interact with QEMU. I don't think introducing RAID support in the block layer is a reasonable alternative. >> >> > > Why not? Because its a lot of complexity and code that can go wrong while only solving the race for one specific case. Not to mention that we double the iop rate. > Something that avoids the whole state thing altogether: > > - instead of atomically switching when live copy is done, keep on issuing writes to both the origin and the live copy > - issue a notification to management > - management receives the notification, and issues an atomic blockdev switch command > this is really the RAID-1 solution but without the state file (credit Dor). An advantage is that there is no additional latency when trying to catch up to the dirty bitmap. It still suffers from the two generals problem. You cannot solve this without making one node reliable and that takes us back to it being either QEMU (posted event and state file) or the management tool (sync event). Regards, Anthony Liguori > > -- > error compiling committee.c: too many arguments to function >
Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy
On 02/28/2011 07:33 PM, Anthony Liguori wrote: > > You're just ignoring what I've written. No, you're just impervious to my subtle attempt to refocus the discussion on solving a practical problem. There's a lot of good, reasonably straight forward changes we can make that have a high return on investment. Is making qemu the authoritative source of configuration information a straightforward change? Is the return on it high? Is the investment low? "No" to all three (ignoring for the moment whether it is good or not, which we were debating). The only suggestion I'm making beyond Marcelo's original patch is that we use a structured format and that we make it possible to use the same file to solve this problem in multiple places. No, you're suggesting a lot more than that. I don't think this creates a fundamental break in how management tools interact with QEMU. I don't think introducing RAID support in the block layer is a reasonable alternative. Why not? Something that avoids the whole state thing altogether: - instead of atomically switching when live copy is done, keep on issuing writes to both the origin and the live copy - issue a notification to management - management receives the notification, and issues an atomic blockdev switch command this is really the RAID-1 solution but without the state file (credit Dor). An advantage is that there is no additional latency when trying to catch up to the dirty bitmap. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] QEMU: Discussion of separating core functionality vs supportive features
On Feb 28, 2011 10:44 AM, "Jes Sorensen" wrote: > > Hi, > > On last week's call we discussed the issue of splitting non core > features of QEMU into it's own process to reduce the security risks etc. > > I wrote up a summary of my thoughts on this to try to cover the various > issues. Feedback welcome and hopefully we can continue the discussion on > a future call - maybe next week? > > I would like to be part of the discussion, but it's a public holiday > here March 1st, so I won't be on that call. > > Cheers, > Jes > > > Separating host-side virtagent and other tasks from core QEMU > = > > To improve auditing of the core QEMU code, it would be ideal to be > able to separate the core QEMU functionality from utility > functionality by moving the utility functionality into its own > process. This process will be referred to as the QEMU client below. Separating as in moving code outside of qemu.git, making code optionally built in, making code optionally built in or loadable as a separate executable that is automatically launched, or making code always built outside the main executable? I'm very nervous about having a large number of daemons necessary to run QEMU. I think a reasonable approach would be a single front-end daemond. Once QAPI is merged, there is a very incremental approach we can take for this sort of work. Take your favorite subsystem (like gdbstub or SDL) and make it only use QMP apis. Once we're only using QMP internally in a subsystem, then building it out of the main QEMU and using libqmp should be fairly easy. Regards, Anthony Liguori > Components which are candidates for moving out of QEMU include: > - virtagent > - vnc server (and other graphical displays such as SDL, spice and > curses) > - human monitor These are all much harder than they may seem. There's a ton of QMP functions that would be needed before we could even try to do this. > The idea is to have QEMU launch as a daemon, and then allow for one of > more client processes to connect to it. These will then offer the > various services. The main issue to discuss is how to handle various > state information, reconnects, and migration. > > Security > > > The primary reason for this discussion is security, however there are > other benefits from this split, as will be mentioned below. During a > demo of virtagent I hit a case where a bug in the agent command > handling code caused a crash of the host QEMU process. While it is > probably a simple bug, it shows how adding more complexity to the QEMU > process increases the risk of adding security problems that could > potentially be exploited by a hostile guest. > > By splitting non core functionality into a QEMU client process, the > host process will be isolated from a large number of potential > security problems, ie. in case a client process is killed or crashes, > it should not affect the main QEMU process. In addition it makes it > easier to audit the core QEMU functionality. > > virtagent > = > > In short virtagent provides a set of simple commands, most of which > do not have state associated with them. These include shutdown, ping, > fsfreeze/fsthaw, etc. Other commands might be multi-stage commands > which could fail if the client is disconnected from the daemon while > the command is in progress. These include copy-paste and file copy. > > vnc server > == > > The vnc server simply needs a connection to the video memory of the > QEMU process, video mode state, as well as channels for sending > keyboard and mouse events. It is stateless by nature and supports > reconnects. This applies to the other graphical display engines (SDL, > spice, and curses) as well. > > Human monitor > = > > The human monitor is effectively stateless. It issues commands and > prints the result. There is no state in the monitor and it can be > built directly on top of QMP. > > An additional benefit here is that it would allow for multiple > monitors. > > Disconnects > === > > It must be possible for a client process getting killed or > disconnected from the QEMU process, in which case is should be > possible to launch a new client that connects to the QEMU > process. In this case, commands needs to be provided allowing the > client process to query the QEMU process and virtagent for current > state information. In-progress commands may fail, and will need to be > re-run, such as copy-paste and and file copy. However neither of > these are vital commands and a re-run of such commands is acceptable > behavior. > > Migration > = > > Given that migration moves the guest to a new QEMU process, normally > on a different host, any connection from management tools to the > monitor, QMP sockets, virtio-serial, etc. require a new connection > through the new QEMU process. Stateless connections, such as the > monitor, QMP and the vnc-server handles reconnects without problems, >
Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy
On Feb 28, 2011 7:21 AM, "Avi Kivity" wrote: > > On 02/28/2011 02:45 PM, Anthony Liguori wrote: >> >> On 02/28/2011 02:38 AM, Avi Kivity wrote: We don't separate configuration from guest state today. Instead of setting ourselves up for failure by setting an unrealistic standard that we try to achieve and never do, let's embrace the system that is working for us today. We are authoritative for everything and guest state is intimately tied to the virtual machine configuration. >>> >>> >>> "we are authoritative for everything" is a clean break from everything that's being done today. It's also a clean break from the model of central management plus database. We can't force it on people. >> >> >> No, it isn't. This has been the way QEMU has always been. >> >> QEMU has always and will always continue to be useful in the absence of a management layer. That means that it will mix modifications to configuration with guest actions. >> >> To avoid races, a management tool needs to either poll QEMU or listen for events to know when QEMU initiates a configuration change. This is how tools are written today. >> >> The only thing being discussed is how to handle a very small and rare race condition whereas QEMU may send an notification to a crashed management tool *and* QEMU crashes before the management tool restarts. >> >> The only two options to solve this problem are synchronous notifications or a QEMU global state file. Since the former is a radical change to our existing API, the later is a much more reasonable option. >> >> If a management tool doesn't care about this race, it can simply not use the global state file. > > > You're just ignoring what I've written. No, you're just impervious to my subtle attempt to refocus the discussion on solving a practical problem. There's a lot of good, reasonably straight forward changes we can make that have a high return on investment. The only suggestion I'm making beyond Marcelo's original patch is that we use a structured format and that we make it possible to use the same file to solve this problem in multiple places. I don't think this creates a fundamental break in how management tools interact with QEMU. I don't think introducing RAID support in the block layer is a reasonable alternative. Regards, Anthony Liguori > > > -- > error compiling committee.c: too many arguments to function >
[Qemu-devel] Re: [PATCH v2 13/24] kvm: Set up signal mask also for !CONFIG_IOTHREAD
On 02/28/2011 06:49 PM, Jan Kiszka wrote: > > That's what I tried, and it didn't work?! Maybe I forgot to compile or > something. Well, it maybe failed to build as qemu_kvm_init_cpu_signals became unused and the compiler should have bailed out? Probably it's better to disable it directly in the function. That's what I did, with #ifdefs, but brokenly (#ifndef). -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [PATCH v2 13/24] kvm: Set up signal mask also for !CONFIG_IOTHREAD
On 2011-02-28 17:45, Avi Kivity wrote:
> On 02/28/2011 06:16 PM, Jan Kiszka wrote:
>> On 2011-02-28 16:55, Avi Kivity wrote:
>>> On 02/01/2011 11:15 PM, Jan Kiszka wrote:
From: Jan Kiszka
Block SIG_IPI, unblock it during KVM_RUN, just like in io-thread mode.
It's unused so far, but this infrastructure will be required for
self-IPIs and to process SIGBUS plus, in KVM mode, SIGIO and SIGALRM. As
Windows doesn't support signal services, we need to provide a stub for
the init function.
>>>
>>> This patch breaks qemu-kvm after merging. The symptoms are that Windows
>>> XP x64 does not respond when netcat connects to some server in it, via
>>> -net user,hostfwd. The vcpu thread loops indefinitely on KVM_EXIT_INTR,
>>> which is consistent with signals being messed up.
>>>
>>> I verified that 981085dd465c1 merged with ff48eb5fe79ad works,
>>> while 981085dd465c1 merged with ff48eb5fe79ad^ fails.
>>>
>>>
diff --git a/cpus.c b/cpus.c
index 42717ba..a33e470 100644
--- a/cpus.c
+++ b/cpus.c
@@ -231,11 +231,9 @@ fail:
return err;
}
-#ifdef CONFIG_IOTHREAD
static void dummy_signal(int sig)
{
}
-#endif
#else /* _WIN32 */
@@ -267,6 +265,32 @@ static void qemu_event_increment(void)
#endif /* _WIN32 */
#ifndef CONFIG_IOTHREAD
+static void qemu_kvm_init_cpu_signals(CPUState *env)
+{
+#ifndef _WIN32
+int r;
+sigset_t set;
+struct sigaction sigact;
+
+memset(&sigact, 0, sizeof(sigact));
+sigact.sa_handler = dummy_signal;
+sigaction(SIG_IPI,&sigact, NULL);
+
+sigemptyset(&set);
+sigaddset(&set, SIG_IPI);
+pthread_sigmask(SIG_BLOCK,&set, NULL);
+
+pthread_sigmask(SIG_BLOCK, NULL,&set);
+sigdelset(&set, SIG_IPI);
+sigdelset(&set, SIGBUS);
+r = kvm_set_signal_mask(env,&set);
+if (r) {
+fprintf(stderr, "kvm_set_signal_mask: %s\n", strerror(-r));
+exit(1);
+}
+#endif
+}
+
int qemu_init_main_loop(void)
{
cpu_set_debug_excp_handler(cpu_debug_handler);
@@ -292,6 +316,7 @@ void qemu_init_vcpu(void *_env)
fprintf(stderr, "kvm_init_vcpu failed: %s\n",
strerror(-r));
exit(1);
}
+qemu_kvm_init_cpu_signals(env);
>>
>> Just comment that out as long as qemu-kvm is (mis-)using !IOTHREAD mode.
>> I thought it would run before setup_kernel_sigmask, but it's the other
>> way around, and then the wrong non-iothread signal setup is applied.
>
> That's what I tried, and it didn't work?! Maybe I forgot to compile or
> something.
Well, it maybe failed to build as qemu_kvm_init_cpu_signals became
unused and the compiler should have bailed out? Probably it's better to
disable it directly in the function.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
[Qemu-devel] Re: [PATCH v2 13/24] kvm: Set up signal mask also for !CONFIG_IOTHREAD
On 02/28/2011 06:45 PM, Avi Kivity wrote: That's what I tried, and it didn't work?! Maybe I forgot to compile or something. I misspelled #ifdef. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [PATCH v2 13/24] kvm: Set up signal mask also for !CONFIG_IOTHREAD
On 02/28/2011 06:16 PM, Jan Kiszka wrote:
On 2011-02-28 16:55, Avi Kivity wrote:
> On 02/01/2011 11:15 PM, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> Block SIG_IPI, unblock it during KVM_RUN, just like in io-thread mode.
>> It's unused so far, but this infrastructure will be required for
>> self-IPIs and to process SIGBUS plus, in KVM mode, SIGIO and SIGALRM. As
>> Windows doesn't support signal services, we need to provide a stub for
>> the init function.
>>
>
> This patch breaks qemu-kvm after merging. The symptoms are that Windows
> XP x64 does not respond when netcat connects to some server in it, via
> -net user,hostfwd. The vcpu thread loops indefinitely on KVM_EXIT_INTR,
> which is consistent with signals being messed up.
>
> I verified that 981085dd465c1 merged with ff48eb5fe79ad works,
> while 981085dd465c1 merged with ff48eb5fe79ad^ fails.
>
>
>> diff --git a/cpus.c b/cpus.c
>> index 42717ba..a33e470 100644
>> --- a/cpus.c
>> +++ b/cpus.c
>> @@ -231,11 +231,9 @@ fail:
>>return err;
>>}
>>
>> -#ifdef CONFIG_IOTHREAD
>>static void dummy_signal(int sig)
>>{
>>}
>> -#endif
>>
>>#else /* _WIN32 */
>>
>> @@ -267,6 +265,32 @@ static void qemu_event_increment(void)
>>#endif /* _WIN32 */
>>
>>#ifndef CONFIG_IOTHREAD
>> +static void qemu_kvm_init_cpu_signals(CPUState *env)
>> +{
>> +#ifndef _WIN32
>> +int r;
>> +sigset_t set;
>> +struct sigaction sigact;
>> +
>> +memset(&sigact, 0, sizeof(sigact));
>> +sigact.sa_handler = dummy_signal;
>> +sigaction(SIG_IPI,&sigact, NULL);
>> +
>> +sigemptyset(&set);
>> +sigaddset(&set, SIG_IPI);
>> +pthread_sigmask(SIG_BLOCK,&set, NULL);
>> +
>> +pthread_sigmask(SIG_BLOCK, NULL,&set);
>> +sigdelset(&set, SIG_IPI);
>> +sigdelset(&set, SIGBUS);
>> +r = kvm_set_signal_mask(env,&set);
>> +if (r) {
>> +fprintf(stderr, "kvm_set_signal_mask: %s\n", strerror(-r));
>> +exit(1);
>> +}
>> +#endif
>> +}
>> +
>>int qemu_init_main_loop(void)
>>{
>>cpu_set_debug_excp_handler(cpu_debug_handler);
>> @@ -292,6 +316,7 @@ void qemu_init_vcpu(void *_env)
>>fprintf(stderr, "kvm_init_vcpu failed: %s\n",
>> strerror(-r));
>>exit(1);
>>}
>> +qemu_kvm_init_cpu_signals(env);
Just comment that out as long as qemu-kvm is (mis-)using !IOTHREAD mode.
I thought it would run before setup_kernel_sigmask, but it's the other
way around, and then the wrong non-iothread signal setup is applied.
That's what I tried, and it didn't work?! Maybe I forgot to compile or
something.
--
error compiling committee.c: too many arguments to function
[Qemu-devel] QEMU: Discussion of separating core functionality vs supportive features
Hi, On last week's call we discussed the issue of splitting non core features of QEMU into it's own process to reduce the security risks etc. I wrote up a summary of my thoughts on this to try to cover the various issues. Feedback welcome and hopefully we can continue the discussion on a future call - maybe next week? I would like to be part of the discussion, but it's a public holiday here March 1st, so I won't be on that call. Cheers, Jes Separating host-side virtagent and other tasks from core QEMU = To improve auditing of the core QEMU code, it would be ideal to be able to separate the core QEMU functionality from utility functionality by moving the utility functionality into its own process. This process will be referred to as the QEMU client below. Components which are candidates for moving out of QEMU include: - virtagent - vnc server (and other graphical displays such as SDL, spice and curses) - human monitor The idea is to have QEMU launch as a daemon, and then allow for one of more client processes to connect to it. These will then offer the various services. The main issue to discuss is how to handle various state information, reconnects, and migration. Security The primary reason for this discussion is security, however there are other benefits from this split, as will be mentioned below. During a demo of virtagent I hit a case where a bug in the agent command handling code caused a crash of the host QEMU process. While it is probably a simple bug, it shows how adding more complexity to the QEMU process increases the risk of adding security problems that could potentially be exploited by a hostile guest. By splitting non core functionality into a QEMU client process, the host process will be isolated from a large number of potential security problems, ie. in case a client process is killed or crashes, it should not affect the main QEMU process. In addition it makes it easier to audit the core QEMU functionality. virtagent = In short virtagent provides a set of simple commands, most of which do not have state associated with them. These include shutdown, ping, fsfreeze/fsthaw, etc. Other commands might be multi-stage commands which could fail if the client is disconnected from the daemon while the command is in progress. These include copy-paste and file copy. vnc server == The vnc server simply needs a connection to the video memory of the QEMU process, video mode state, as well as channels for sending keyboard and mouse events. It is stateless by nature and supports reconnects. This applies to the other graphical display engines (SDL, spice, and curses) as well. Human monitor = The human monitor is effectively stateless. It issues commands and prints the result. There is no state in the monitor and it can be built directly on top of QMP. An additional benefit here is that it would allow for multiple monitors. Disconnects === It must be possible for a client process getting killed or disconnected from the QEMU process, in which case is should be possible to launch a new client that connects to the QEMU process. In this case, commands needs to be provided allowing the client process to query the QEMU process and virtagent for current state information. In-progress commands may fail, and will need to be re-run, such as copy-paste and and file copy. However neither of these are vital commands and a re-run of such commands is acceptable behavior. Migration = Given that migration moves the guest to a new QEMU process, normally on a different host, any connection from management tools to the monitor, QMP sockets, virtio-serial, etc. require a new connection through the new QEMU process. Stateless connections, such as the monitor, QMP and the vnc-server handles reconnects without problems, and should not have any issues during migration that are different from the issues in the current implementation. The main issues causing problems are stateful events such as copy-paste, which is handled via a guest agent. The copy-paste problem can be handled by blocking copy-paste operations during migration, until the guest agent is reachable through the QEMU process on the new host. This does mean that copy-paste can block or fail temporarily (depending on whether is it implemented as -EBUSY or just blocks), however it is not a mission critical feature, and it can also block or fail temporarily during normal operation on a non virtual system. Per the nature of the operation, a file copy via a guest agent is going to fail and will have to be restarted after migration has completed, in case it does not complete. This is again a non critical feature and requiring a restart is acceptable.
[Qemu-devel] Re: [PATCH v2 13/24] kvm: Set up signal mask also for !CONFIG_IOTHREAD
On 2011-02-28 16:55, Avi Kivity wrote:
> On 02/01/2011 11:15 PM, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> Block SIG_IPI, unblock it during KVM_RUN, just like in io-thread mode.
>> It's unused so far, but this infrastructure will be required for
>> self-IPIs and to process SIGBUS plus, in KVM mode, SIGIO and SIGALRM. As
>> Windows doesn't support signal services, we need to provide a stub for
>> the init function.
>>
>
> This patch breaks qemu-kvm after merging. The symptoms are that Windows
> XP x64 does not respond when netcat connects to some server in it, via
> -net user,hostfwd. The vcpu thread loops indefinitely on KVM_EXIT_INTR,
> which is consistent with signals being messed up.
>
> I verified that 981085dd465c1 merged with ff48eb5fe79ad works,
> while 981085dd465c1 merged with ff48eb5fe79ad^ fails.
>
>
>> diff --git a/cpus.c b/cpus.c
>> index 42717ba..a33e470 100644
>> --- a/cpus.c
>> +++ b/cpus.c
>> @@ -231,11 +231,9 @@ fail:
>> return err;
>> }
>>
>> -#ifdef CONFIG_IOTHREAD
>> static void dummy_signal(int sig)
>> {
>> }
>> -#endif
>>
>> #else /* _WIN32 */
>>
>> @@ -267,6 +265,32 @@ static void qemu_event_increment(void)
>> #endif /* _WIN32 */
>>
>> #ifndef CONFIG_IOTHREAD
>> +static void qemu_kvm_init_cpu_signals(CPUState *env)
>> +{
>> +#ifndef _WIN32
>> +int r;
>> +sigset_t set;
>> +struct sigaction sigact;
>> +
>> +memset(&sigact, 0, sizeof(sigact));
>> +sigact.sa_handler = dummy_signal;
>> +sigaction(SIG_IPI,&sigact, NULL);
>> +
>> +sigemptyset(&set);
>> +sigaddset(&set, SIG_IPI);
>> +pthread_sigmask(SIG_BLOCK,&set, NULL);
>> +
>> +pthread_sigmask(SIG_BLOCK, NULL,&set);
>> +sigdelset(&set, SIG_IPI);
>> +sigdelset(&set, SIGBUS);
>> +r = kvm_set_signal_mask(env,&set);
>> +if (r) {
>> +fprintf(stderr, "kvm_set_signal_mask: %s\n", strerror(-r));
>> +exit(1);
>> +}
>> +#endif
>> +}
>> +
>> int qemu_init_main_loop(void)
>> {
>> cpu_set_debug_excp_handler(cpu_debug_handler);
>> @@ -292,6 +316,7 @@ void qemu_init_vcpu(void *_env)
>> fprintf(stderr, "kvm_init_vcpu failed: %s\n",
>> strerror(-r));
>> exit(1);
>> }
>> +qemu_kvm_init_cpu_signals(env);
Just comment that out as long as qemu-kvm is (mis-)using !IOTHREAD mode.
I thought it would run before setup_kernel_sigmask, but it's the other
way around, and then the wrong non-iothread signal setup is applied.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
[Qemu-devel] [Bug 726619] [NEW] loadvm does not load (offline) snapshot anymore
Public bug reported: qemu Version: 0.14.0 The problem is present in the current code from git master as well. Loading a snapshot that was created while qemu was not running (using qemu-img) does not seem to work anymore. Using "loadvm " in the qemu monitor does not have the desired effect. Not even an error message is displayed. I was able to track down the problem (using git bisect) to this commit: http://git.qemu.org/qemu.git/commit/?id=f0aa7a8b2d518c54430e4382309281b93e51981a After reverting that commit in my local git checkout everything is workin as expected again. ** 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/726619 Title: loadvm does not load (offline) snapshot anymore Status in QEMU: New Bug description: qemu Version: 0.14.0 The problem is present in the current code from git master as well. Loading a snapshot that was created while qemu was not running (using qemu-img) does not seem to work anymore. Using "loadvm " in the qemu monitor does not have the desired effect. Not even an error message is displayed. I was able to track down the problem (using git bisect) to this commit: http://git.qemu.org/qemu.git/commit/?id=f0aa7a8b2d518c54430e4382309281b93e51981a After reverting that commit in my local git checkout everything is workin as expected again.
[Qemu-devel] Re: [PATCH v2 13/24] kvm: Set up signal mask also for !CONFIG_IOTHREAD
On 2011-02-28 17:02, Jan Kiszka wrote: > On 2011-02-28 16:55, Avi Kivity wrote: >> On 02/01/2011 11:15 PM, Jan Kiszka wrote: >>> From: Jan Kiszka >>> >>> Block SIG_IPI, unblock it during KVM_RUN, just like in io-thread mode. >>> It's unused so far, but this infrastructure will be required for >>> self-IPIs and to process SIGBUS plus, in KVM mode, SIGIO and SIGALRM. As >>> Windows doesn't support signal services, we need to provide a stub for >>> the init function. >>> >> >> This patch breaks qemu-kvm after merging. The symptoms are that Windows >> XP x64 does not respond when netcat connects to some server in it, via >> -net user,hostfwd. The vcpu thread loops indefinitely on KVM_EXIT_INTR, >> which is consistent with signals being messed up. > > Does the same test case work with qemu, iothread on and off? Just to Err, "iothread on" makes no sense here, of course. > ensure we are not hunting an issue with the patch itself but of the merge. > > Will have a look as well. > Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
[Qemu-devel] Re: [PATCH v2 13/24] kvm: Set up signal mask also for !CONFIG_IOTHREAD
On 2011-02-28 16:55, Avi Kivity wrote:
> On 02/01/2011 11:15 PM, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> Block SIG_IPI, unblock it during KVM_RUN, just like in io-thread mode.
>> It's unused so far, but this infrastructure will be required for
>> self-IPIs and to process SIGBUS plus, in KVM mode, SIGIO and SIGALRM. As
>> Windows doesn't support signal services, we need to provide a stub for
>> the init function.
>>
>
> This patch breaks qemu-kvm after merging. The symptoms are that Windows
> XP x64 does not respond when netcat connects to some server in it, via
> -net user,hostfwd. The vcpu thread loops indefinitely on KVM_EXIT_INTR,
> which is consistent with signals being messed up.
Does the same test case work with qemu, iothread on and off? Just to
ensure we are not hunting an issue with the patch itself but of the merge.
Will have a look as well.
Jan
>
> I verified that 981085dd465c1 merged with ff48eb5fe79ad works,
> while 981085dd465c1 merged with ff48eb5fe79ad^ fails.
>
>
>> diff --git a/cpus.c b/cpus.c
>> index 42717ba..a33e470 100644
>> --- a/cpus.c
>> +++ b/cpus.c
>> @@ -231,11 +231,9 @@ fail:
>> return err;
>> }
>>
>> -#ifdef CONFIG_IOTHREAD
>> static void dummy_signal(int sig)
>> {
>> }
>> -#endif
>>
>> #else /* _WIN32 */
>>
>> @@ -267,6 +265,32 @@ static void qemu_event_increment(void)
>> #endif /* _WIN32 */
>>
>> #ifndef CONFIG_IOTHREAD
>> +static void qemu_kvm_init_cpu_signals(CPUState *env)
>> +{
>> +#ifndef _WIN32
>> +int r;
>> +sigset_t set;
>> +struct sigaction sigact;
>> +
>> +memset(&sigact, 0, sizeof(sigact));
>> +sigact.sa_handler = dummy_signal;
>> +sigaction(SIG_IPI,&sigact, NULL);
>> +
>> +sigemptyset(&set);
>> +sigaddset(&set, SIG_IPI);
>> +pthread_sigmask(SIG_BLOCK,&set, NULL);
>> +
>> +pthread_sigmask(SIG_BLOCK, NULL,&set);
>> +sigdelset(&set, SIG_IPI);
>> +sigdelset(&set, SIGBUS);
>> +r = kvm_set_signal_mask(env,&set);
>> +if (r) {
>> +fprintf(stderr, "kvm_set_signal_mask: %s\n", strerror(-r));
>> +exit(1);
>> +}
>> +#endif
>> +}
>> +
>> int qemu_init_main_loop(void)
>> {
>> cpu_set_debug_excp_handler(cpu_debug_handler);
>> @@ -292,6 +316,7 @@ void qemu_init_vcpu(void *_env)
>> fprintf(stderr, "kvm_init_vcpu failed: %s\n",
>> strerror(-r));
>> exit(1);
>> }
>> +qemu_kvm_init_cpu_signals(env);
>> }
>> }
>>
>
>
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
[Qemu-devel] Re: [PATCH v2 13/24] kvm: Set up signal mask also for !CONFIG_IOTHREAD
On 02/01/2011 11:15 PM, Jan Kiszka wrote:
From: Jan Kiszka
Block SIG_IPI, unblock it during KVM_RUN, just like in io-thread mode.
It's unused so far, but this infrastructure will be required for
self-IPIs and to process SIGBUS plus, in KVM mode, SIGIO and SIGALRM. As
Windows doesn't support signal services, we need to provide a stub for
the init function.
This patch breaks qemu-kvm after merging. The symptoms are that Windows
XP x64 does not respond when netcat connects to some server in it, via
-net user,hostfwd. The vcpu thread loops indefinitely on KVM_EXIT_INTR,
which is consistent with signals being messed up.
I verified that 981085dd465c1 merged with ff48eb5fe79ad works,
while 981085dd465c1 merged with ff48eb5fe79ad^ fails.
diff --git a/cpus.c b/cpus.c
index 42717ba..a33e470 100644
--- a/cpus.c
+++ b/cpus.c
@@ -231,11 +231,9 @@ fail:
return err;
}
-#ifdef CONFIG_IOTHREAD
static void dummy_signal(int sig)
{
}
-#endif
#else /* _WIN32 */
@@ -267,6 +265,32 @@ static void qemu_event_increment(void)
#endif /* _WIN32 */
#ifndef CONFIG_IOTHREAD
+static void qemu_kvm_init_cpu_signals(CPUState *env)
+{
+#ifndef _WIN32
+int r;
+sigset_t set;
+struct sigaction sigact;
+
+memset(&sigact, 0, sizeof(sigact));
+sigact.sa_handler = dummy_signal;
+sigaction(SIG_IPI,&sigact, NULL);
+
+sigemptyset(&set);
+sigaddset(&set, SIG_IPI);
+pthread_sigmask(SIG_BLOCK,&set, NULL);
+
+pthread_sigmask(SIG_BLOCK, NULL,&set);
+sigdelset(&set, SIG_IPI);
+sigdelset(&set, SIGBUS);
+r = kvm_set_signal_mask(env,&set);
+if (r) {
+fprintf(stderr, "kvm_set_signal_mask: %s\n", strerror(-r));
+exit(1);
+}
+#endif
+}
+
int qemu_init_main_loop(void)
{
cpu_set_debug_excp_handler(cpu_debug_handler);
@@ -292,6 +316,7 @@ void qemu_init_vcpu(void *_env)
fprintf(stderr, "kvm_init_vcpu failed: %s\n", strerror(-r));
exit(1);
}
+qemu_kvm_init_cpu_signals(env);
}
}
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [RFC][PATCH 0/2] Allow cache settings for block devices to be changed at runtime.
Am 28.02.2011 16:35, schrieb Stefan Hajnoczi: > On Mon, Feb 28, 2011 at 3:12 PM, Kevin Wolf wrote: >> Am 28.02.2011 12:49, schrieb Prerna Saxena: >>> The following patchset introduces monitor commands: >>> >>> 1. set_cache DEVICE CACHE-SETTING >>> Change cache settings for block device, DEVICE, through the monitor. >>> (Available options : 'none', 'writeback', 'writethrough') >>> Eg, >>> (qemu)set_cache ide0-hd0 none >>> -> Changes cache setting for ide0-hd0 to 'none' >> >> Not sure if adding this interface is a good idea. I see that you only >> add it for HMP, and we may consider that, but it's definitely not >> suitable for QMP. >> >> One reason is that none/writethrough/writeback/unsafe isn't really what >> we want to use long term. We want to separate advertising a write cache >> (which is guest visible) from things like whether to use O_DIRECT or not. >> >> In the past, Christoph mentioned that he had patches to make these >> separate and even let the guest change the "write cache enabled" flag, >> which would probably solve most of the use cases of this patch. > > Toggling host page cache at runtime is useful too because it saves > having to restart VMs. Not sure why I wanted to change that during runtime, but agreed, allowing to change parameters using the monitor is generally a good thing. However, I'm not sure if a command for changing the cache mode is the right solution, or if it should be something like a command to change block device options. (For example, what about toggling read-only or snapshot mode?) > I agree that the guest should control the > emulated drive cache at runtime and we probably don't want to allow > toggling that from the host - it could be dangerous :). Good point. That's a NACK for this patch as long as we haven't separated WCE from the host cache setting. Kevin
Re: [Qemu-devel] [RFC][PATCH 0/2] Allow cache settings for block devices to be changed at runtime.
On Mon, Feb 28, 2011 at 3:12 PM, Kevin Wolf wrote: > Am 28.02.2011 12:49, schrieb Prerna Saxena: >> The following patchset introduces monitor commands: >> >> 1. set_cache DEVICE CACHE-SETTING >> Change cache settings for block device, DEVICE, through the monitor. >> (Available options : 'none', 'writeback', 'writethrough') >> Eg, >> (qemu)set_cache ide0-hd0 none >> -> Changes cache setting for ide0-hd0 to 'none' > > Not sure if adding this interface is a good idea. I see that you only > add it for HMP, and we may consider that, but it's definitely not > suitable for QMP. > > One reason is that none/writethrough/writeback/unsafe isn't really what > we want to use long term. We want to separate advertising a write cache > (which is guest visible) from things like whether to use O_DIRECT or not. > > In the past, Christoph mentioned that he had patches to make these > separate and even let the guest change the "write cache enabled" flag, > which would probably solve most of the use cases of this patch. Toggling host page cache at runtime is useful too because it saves having to restart VMs. I agree that the guest should control the emulated drive cache at runtime and we probably don't want to allow toggling that from the host - it could be dangerous :). Stefan
Re: [Qemu-devel] [PATCH (resend, rebase) 3/3] virtio-serial: Enable ioeventfd
On Mon, Feb 28, 2011 at 11:12 AM, Amit Shah wrote: > Enable ioeventfd for virtio-serial devices by default. Commit > 25db9ebe15125deb32958c6df74996f745edf1f9 lists the benefits of using > ioeventfd. > > Copying a file from guest to host over a virtio-serial channel didn't > show much difference in time or io_exit rate. The cost of enabling ioeventfd is one eventfd file descriptor and KVM in-kernel device slot per virtqueue. The current maximum number per VM is 200, this is a kernel limit in include/linux/kvm_host.h:NR_IOBUS_DEVS. Do you really want to use ioeventfd for virtio-serial? Perhaps this is more useful for high-frequency device interfaces. Stefan
Re: [Qemu-devel] [RFC][PATCH 2/2] Extend monitor command 'info block' to display cache settings for block devices.
Am 28.02.2011 13:11, schrieb Prerna Saxena:
> (qemu)info block
> SAMPLE output :
> ide0-hd0: type=hd removable=0 cache=none file=/tmp/abc.img ro=0
> drv=qcow2 encrypted=0
>
> ---
> block.c | 22 --
> 1 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/block.c b/block.c
> index f7d91a2..c717888 100644
> --- a/block.c
> +++ b/block.c
> @@ -1707,6 +1707,23 @@ static void bdrv_print_dict(QObject *obj, void *opaque)
> monitor_printf(mon, " locked=%d", qdict_get_bool(bs_dict, "locked"));
> }
>
> +if (qdict_haskey(bs_dict, "open_flags") &&
> +!strcmp(qdict_get_str(bs_dict, "type"), "hd")) {
> +int open_flags = qdict_get_int(bs_dict, "open_flags");
> +if (open_flags & BDRV_O_NOCACHE) {
> +monitor_printf(mon, " cache=none");
> +} else if (open_flags & BDRV_O_CACHE_WB) {
> +if (open_flags & BDRV_O_NO_FLUSH) {
> +monitor_printf(mon, " cache=unsafe");
> +}
> +else {
> +monitor_printf(mon, " cache=writeback");
> +}
> +} else {
> +monitor_printf(mon, " cache=writethrough");
> +}
> +}
> +
> if (qdict_haskey(bs_dict, "inserted")) {
> QDict *qdict = qobject_to_qdict(qdict_get(bs_dict, "inserted"));
>
> @@ -1756,9 +1773,10 @@ void bdrv_info(Monitor *mon, QObject **ret_data)
> }
>
> bs_obj = qobject_from_jsonf("{ 'device': %s, 'type': %s, "
> -"'removable': %i, 'locked': %i }",
> +"'removable': %i, 'locked': %i, "
> +"'open_flags': %d }",
> bs->device_name, type, bs->removable,
> -bs->locked);
> +bs->locked, bs->open_flags);
IIUC, this is the structure that a QMP client will receive for a
query-block command. The open_flags bitmask is not considered an ABI and
completely meaningless outside qemu.
Kevin
Re: [Qemu-devel] [RFC][PATCH 0/2] Allow cache settings for block devices to be changed at runtime.
Am 28.02.2011 12:49, schrieb Prerna Saxena: > The following patchset introduces monitor commands: > > 1. set_cache DEVICE CACHE-SETTING > Change cache settings for block device, DEVICE, through the monitor. > (Available options : 'none', 'writeback', 'writethrough') > Eg, > (qemu)set_cache ide0-hd0 none > -> Changes cache setting for ide0-hd0 to 'none' Not sure if adding this interface is a good idea. I see that you only add it for HMP, and we may consider that, but it's definitely not suitable for QMP. One reason is that none/writethrough/writeback/unsafe isn't really what we want to use long term. We want to separate advertising a write cache (which is guest visible) from things like whether to use O_DIRECT or not. In the past, Christoph mentioned that he had patches to make these separate and even let the guest change the "write cache enabled" flag, which would probably solve most of the use cases of this patch. Christoph, what's the status of these patches? > 2. info block > Now extended to display cache settings for available block devices. Have you checked that libvirt is okay with this? Kevin
[Qemu-devel] Re: [PATCH v3 uq/master 00/22] Win32 iothread support
On 02/28/2011 01:13 PM, Avi Kivity wrote: If there's a git tree of this I'll be happy to do an autotest run. Sure, it's branch iothread-win32 of git://github.com/bonzini/qemu.git Paolo
Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy
On 02/28/2011 02:45 PM, Anthony Liguori wrote: On 02/28/2011 02:38 AM, Avi Kivity wrote: We don't separate configuration from guest state today. Instead of setting ourselves up for failure by setting an unrealistic standard that we try to achieve and never do, let's embrace the system that is working for us today. We are authoritative for everything and guest state is intimately tied to the virtual machine configuration. "we are authoritative for everything" is a clean break from everything that's being done today. It's also a clean break from the model of central management plus database. We can't force it on people. No, it isn't. This has been the way QEMU has always been. QEMU has always and will always continue to be useful in the absence of a management layer. That means that it will mix modifications to configuration with guest actions. To avoid races, a management tool needs to either poll QEMU or listen for events to know when QEMU initiates a configuration change. This is how tools are written today. The only thing being discussed is how to handle a very small and rare race condition whereas QEMU may send an notification to a crashed management tool *and* QEMU crashes before the management tool restarts. The only two options to solve this problem are synchronous notifications or a QEMU global state file. Since the former is a radical change to our existing API, the later is a much more reasonable option. If a management tool doesn't care about this race, it can simply not use the global state file. You're just ignoring what I've written. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: GSoC 2011 project ideas
On Mon, 28 Feb 2011 10:09:43 +0100 Jan Kiszka wrote: > On 2011-02-28 00:44, Natalia Portillo wrote: > > Hi there, > > > > El 23/02/2011, a las 20:42, Luiz Capitulino escribió: > > > >> Hi there, > >> > >> Google will begin accepting mentoring organizations applications next > >> week, but > >> we count only with three projects so far. > >> > >> Although there doesn't seem to exist a hard deadline associated with the > >> ideas > >> page, nor with the number of projects, we had more than 20 projects > >> suggestions last year and a number of volunteering mentors. > > > > Is there any problem to repeat previously proposed and not chosen projects? > > > > I don't think so, and I've just ported one of my old proposals to this > year's page. This is ok, as long as the project is still valid of course. Thanks!
Re: [Qemu-devel] Re: kvm crashes with spice while loading qxl
On Sun, Feb 27, 2011 at 8:03 PM, Alon Levy wrote: > On Sat, Feb 26, 2011 at 01:29:01PM +0100, Jan Kiszka wrote: >> On 2011-02-26 12:43, xming wrote: >> > When trying to start X (and it loads qxl driver) the kvm process just >> > crashes. > > This is fixed by Gerd's attached patch (taken from rhel repository, don't know > why it wasn't pushed to qemu-kvm upstream). I'll send it to kvm list as well > (separate email). I can confirm that this patch fixes the issue, thanks a lot cheers
Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy
On 02/28/2011 02:38 AM, Avi Kivity wrote: We don't separate configuration from guest state today. Instead of setting ourselves up for failure by setting an unrealistic standard that we try to achieve and never do, let's embrace the system that is working for us today. We are authoritative for everything and guest state is intimately tied to the virtual machine configuration. "we are authoritative for everything" is a clean break from everything that's being done today. It's also a clean break from the model of central management plus database. We can't force it on people. No, it isn't. This has been the way QEMU has always been. QEMU has always and will always continue to be useful in the absence of a management layer. That means that it will mix modifications to configuration with guest actions. To avoid races, a management tool needs to either poll QEMU or listen for events to know when QEMU initiates a configuration change. This is how tools are written today. The only thing being discussed is how to handle a very small and rare race condition whereas QEMU may send an notification to a crashed management tool *and* QEMU crashes before the management tool restarts. The only two options to solve this problem are synchronous notifications or a QEMU global state file. Since the former is a radical change to our existing API, the later is a much more reasonable option. If a management tool doesn't care about this race, it can simply not use the global state file. Regards, Anthony Liguori
[Qemu-devel] Re: virtio-serial semantics for binary data and guest agents
On (Thu) 24 Feb 2011 [08:44:07], Anthony Liguori wrote: > For instance, if the host side disconnects, then reconnects before > we read(), we may never get the read()=0, and our FD remains valid. > Whereas with a tcp/unix socket our FD is no longer valid, and the > read()=0 is an event we can check for at any point after the other > end does a close/disconnect. > >>>There's SIGIO support, so host connect-disconnect notifications can be > >>>caught via the signal. > >>I recall looking into this at some pointbut don't we get a SIGIO > >>for read/write-ability in general? > >I don't get you -- the virtio_console driver emits the SIGIO signal > >only when the host side connects or disconnects. See > > Um, that's not the expected semantics of SIGIO. SIGIO can be > delivered for any number of reasons (including on a normal file > descriptor) so if there's no way to poll for the specific event then > the mechanism is inherently racy. Well -- for a custom driver something's going to be non-standard: if it's baking in connection info into the open/close semantics or having SIGIO delivered when needed. However, I think a generic library needs to be used for guest-host communications, abstracting away virtio-serial entirely. This way, apps should just communicate over tcp, the library should do the necessary virtio-serial (or even virt-9pfs) calls. This way, all guest apps written will be infrastructure-agnostic, and if there's a better protocol to communicate with, virtio-serial can easily be dropped w/o modifications to apps. Amit
Re: [Qemu-devel] Fix build errors introduced by vnc jpeg changes
On Mon, Feb 28, 2011 at 11:15:51AM +, Peter Maydell wrote: > On 28 February 2011 10:48, David Gibson wrote: > > The recent changes to handling of jpegs over tight vnc connections > > cause build errors if qemu is configured with --disable-vnc-jpeg. The > > patch below corrects the errors, by adding some left out #ifdefs. > > > > Please apply. > > > > Signed-off-by: David Gibson > > This is already fixed in master: > > http://git.qemu.org/qemu.git/commit/?id=cf76a1ce8b7cf4b92429d67d3f4626a92b2d8a37 Ah, sorry. Sent that mail several days ago, but it got stuck due to a mail configuration error. Forgot to recheck when I unstuck it. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
[Qemu-devel] Re: [PATCH v3 uq/master 00/22] Win32 iothread support
On 02/28/2011 01:57 PM, Jan Kiszka wrote: On 2011-02-28 11:10, Paolo Bonzini wrote: > On 02/28/2011 10:16 AM, Avi Kivity wrote: >> Why is that? uq/master is for kvm code, and this touches two or three >> lines? > > iothread code is also going in via uq/master often. I started with > uq/master because I depended on Jan's changes which are now upstream, I > have no problems with this going directly to qemu.git. As this touches the iothread, a central subsystem full of kvm code, and as uq/master is known to be checked against autotest, I still think uq/master is the right choice. If there's a git tree of this I'll be happy to do an autotest run. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [RFC][PATCH 2/2] Extend monitor command 'info block' to display cache settings for block devices.
(qemu)info block
SAMPLE output :
ide0-hd0: type=hd removable=0 cache=none file=/tmp/abc.img ro=0
drv=qcow2 encrypted=0
---
block.c | 22 --
1 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/block.c b/block.c
index f7d91a2..c717888 100644
--- a/block.c
+++ b/block.c
@@ -1707,6 +1707,23 @@ static void bdrv_print_dict(QObject *obj, void *opaque)
monitor_printf(mon, " locked=%d", qdict_get_bool(bs_dict, "locked"));
}
+if (qdict_haskey(bs_dict, "open_flags") &&
+!strcmp(qdict_get_str(bs_dict, "type"), "hd")) {
+int open_flags = qdict_get_int(bs_dict, "open_flags");
+if (open_flags & BDRV_O_NOCACHE) {
+monitor_printf(mon, " cache=none");
+} else if (open_flags & BDRV_O_CACHE_WB) {
+if (open_flags & BDRV_O_NO_FLUSH) {
+monitor_printf(mon, " cache=unsafe");
+}
+else {
+monitor_printf(mon, " cache=writeback");
+}
+} else {
+monitor_printf(mon, " cache=writethrough");
+}
+}
+
if (qdict_haskey(bs_dict, "inserted")) {
QDict *qdict = qobject_to_qdict(qdict_get(bs_dict, "inserted"));
@@ -1756,9 +1773,10 @@ void bdrv_info(Monitor *mon, QObject **ret_data)
}
bs_obj = qobject_from_jsonf("{ 'device': %s, 'type': %s, "
-"'removable': %i, 'locked': %i }",
+"'removable': %i, 'locked': %i, "
+"'open_flags': %d }",
bs->device_name, type, bs->removable,
-bs->locked);
+bs->locked, bs->open_flags);
if (bs->drv) {
QObject *obj;
--
1.7.2.3
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
Re: [Qemu-devel] Link to UEFI OVMF on downloads page
On 02/28/2011 02:04 AM, Jordan Justen wrote: Hi all, Would it be possible to add a link to OVMF: http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF on the qemu links page: http://wiki.qemu.org/Links for UEFI support on x86& x86-64 guests? Just create an account and add it yourself. Regards, Anthony Liguori Thanks, -Jordan
[Qemu-devel] [RFC][PATCH 1/2] Add monitor command 'set-cache' to change cache settings for a block device.
Usage :
(qemu) set_cache DEVICE CACHE-MODE
where CACHE-MODE can be one of writeback/ writethrough/ none.
At present, the image file is closed and re-opened with appropriate flags.
It might potentially cause problems if the underlying image is deleted
while a running qemu instance is using it. A change in cache operations
will cause the image file to be closed, and a deleted file will be gone.
Suggestions to fix this ?
---
blockdev.c | 76 +++
blockdev.h |1 +
hmp-commands.hx | 13 +
3 files changed, 90 insertions(+), 0 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index 0690cc8..6735205 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -636,6 +636,82 @@ out:
return ret;
}
+int do_set_cache(Monitor *mon, const QDict *qdict, QObject **ret_data)
+{
+const char *device = qdict_get_str(qdict, "device");
+const char *cache = qdict_get_str(qdict, "cache");
+BlockDriverState *bs;
+BlockDriver *drv;
+int ret = 0;
+int bdrv_flags = 0;
+
+if (!cache) {
+ /* TODO: in the absence of a change request,
+ simply display current cache setting.
+ Currently one needs 'info block' to query this */
+qerror_report(QERR_MISSING_PARAMETER, "cache");
+return -1;
+}
+
+bs = bdrv_find(device);
+if (!bs) {
+qerror_report(QERR_DEVICE_NOT_FOUND, device);
+return -1;
+}
+
+/* Clear old flags */
+bdrv_flags = bs->open_flags;
+if (bdrv_flags & BDRV_O_CACHE_MASK) {
+bdrv_flags &= ~BDRV_O_CACHE_MASK;
+}
+
+/* Determine flags for requested cache setting */
+if (!strcmp(cache, "none")) {
+bdrv_flags |= BDRV_O_NOCACHE;
+} else if (!strcmp(cache, "writeback")) {
+bdrv_flags |= BDRV_O_CACHE_WB;
+} else if (!strcmp(cache, "unsafe")) {
+ /* TODO : Support unsafe mode */
+qerror_report(QERR_INVALID_PARAMETER_VALUE, cache,
+ "writeback, writethrough, none");
+return -1;
+} else if (!strcmp(cache, "writethrough")) {
+/* Default setting */
+} else {
+qerror_report(QERR_INVALID_PARAMETER_VALUE, cache,
+ "'cache' must be one of writeback, writethrough, none");
+return -1;
+}
+
+/* Verify that the cache setting specified is different from current.
+ * Does NOT call for error return, since the 'request' is already
+ * honoured.
+ */
+if (bdrv_flags == bs->open_flags) {
+qerror_report(QERR_PROPERTY_VALUE_IN_USE, device, "cache", cache);
+return 0;
+}
+
+/* Quiesce IO for the given block device */
+qemu_aio_flush();
+bdrv_flush(bs);
+
+/* Change cache value and restart IO on the block device */
+printf("Setting cache=%s for device %s [ filename %s ]", cache, device,
+bs->filename );
+drv = bs->drv;
+bdrv_close(bs);
+ret = bdrv_open(bs, bs->filename, bdrv_flags, drv);
+/*
+ * A failed attempt to reopen the image file must lead to 'abort()'
+ */
+if (ret != 0) {
+abort();
+}
+
+return ret;
+}
+
static int eject_device(Monitor *mon, BlockDriverState *bs, int force)
{
if (!force) {
diff --git a/blockdev.h b/blockdev.h
index 2c9e780..9f35817 100644
--- a/blockdev.h
+++ b/blockdev.h
@@ -63,6 +63,7 @@ int do_change_block(Monitor *mon, const char *device,
const char *filename, const char *fmt);
int do_drive_del(Monitor *mon, const QDict *qdict, QObject **ret_data);
int do_snapshot_blkdev(Monitor *mon, const QDict *qdict, QObject **ret_data);
+int do_set_cache(Monitor *mon, const QDict *qdict, QObject **ret_data);
int do_block_resize(Monitor *mon, const QDict *qdict, QObject **ret_data);
#endif
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 372bef4..18761cf 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1066,7 +1066,20 @@ STEXI
@findex watchdog_action
Change watchdog action.
ETEXI
+{
+.name = "set_cache",
+.args_type = "device:B,cache:s",
+.params = "device writeback|writethrough|none",
+.help = "change cache settings for device",
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = do_set_cache,
+},
+STEXI
+@item set_cache
+@findex set_cache
+Set cache options for a block device.
+ETEXI
{
.name = "acl_show",
.args_type = "aclname:s",
--
1.7.2.3
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
[Qemu-devel] Re: [PATCH] Split machine creation from the main loop
On 02/28/2011 03:13 AM, Avi Kivity wrote:
On 02/28/2011 10:57 AM, Paolo Bonzini wrote:
On 02/28/2011 09:20 AM, Avi Kivity wrote:
We should have another abstraction for connection based backend. I'll
take a go at this when I'm ready to try to get those patches in.
Shouldn't each new connection return a chardev?
You would need a kind of "factory" interface that knows how to create
a new {monitor,serial port,you name it} for each new connection.
Actually it doesn't make much sense except for monitors.
Monitors and vnc.
VNC also does it's own buffering when reading and writing to a file
descriptor. The chardev layer doesn't really have a concept of flow
control.
Regards,
Anthony Liguori
[Qemu-devel] [V6 PATCH 0/9] virtio-9p: Use chroot to safely access files in passthrough security model
In passthrough security model, following symbolic links in the server side could result in TOCTTOU vulnerabilities. This patchset resolves this issue by creating a dedicated process which chroots into the share path and all file object access is done in the chroot environment. This patchset implements chroot enviroment, provides necessary functions that can be used by the passthrough function calls. Changes from version V5: * Return errno on failure instead of setting errno * Minor cleanups like updated comments, enable CONFIG_THREAD if CONFIG_VIRTFS is enabled Changes from version V4: * Avoid using malloc/free inside chroot process * Seperate chroot server and client functions Changes from version V3 * Return EIO incase of socket read/write fail instead of exiting * Changed data types as suggested by Blue Swirl * Chroot process reports error through qemu process Changes from version V2 * Treat socket IO errors as fatal, ie qemu will exit * Split patchset based on chroot side (server) and qemu side(client) functionalities M. Mohan Kumar (9): Implement qemu_read_full virtio-9p: Enable CONFIG_THREAD if CONFIG_VIRTFS is enabled virtio-9p: Provide chroot daemon side interfaces virtio-9p: Add qemu side interfaces for chroot environment virtio-9p: Add support to open a file in chroot environment virtio-9p: Create support in chroot environment virtio-9p: Support for creating special files virtio-9p: Move file post creation changes to none security model virtio-9p: Chroot environment for other functions Makefile.objs |1 + configure |1 + hw/9pfs/virtio-9p-chroot-dm.c | 282 ++ hw/9pfs/virtio-9p-chroot-qemu.c | 124 hw/9pfs/virtio-9p-chroot.h | 59 ++ hw/9pfs/virtio-9p-local.c | 418 +++ hw/9pfs/virtio-9p.c | 32 +++ hw/file-op-9p.h |4 + osdep.c | 32 +++ qemu-common.h |2 + 10 files changed, 875 insertions(+), 80 deletions(-) create mode 100644 hw/9pfs/virtio-9p-chroot-dm.c create mode 100644 hw/9pfs/virtio-9p-chroot-qemu.c create mode 100644 hw/9pfs/virtio-9p-chroot.h -- 1.7.3.4
[Qemu-devel] Re: [PATCH v3 uq/master 00/22] Win32 iothread support
On 2011-02-28 11:10, Paolo Bonzini wrote: > On 02/28/2011 10:16 AM, Avi Kivity wrote: >> Why is that? uq/master is for kvm code, and this touches two or three >> lines? > > iothread code is also going in via uq/master often. I started with > uq/master because I depended on Jan's changes which are now upstream, I > have no problems with this going directly to qemu.git. As this touches the iothread, a central subsystem full of kvm code, and as uq/master is known to be checked against autotest, I still think uq/master is the right choice. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
[Qemu-devel] jitter in Audio
Hi, Iam using qemu 0.13.0..whenever Iam playing any file using ffplay.sometimes it happens that audio stops and then after sometime gain it starts playing..but i dont see this problem with aplay. so whats going wrong.Plz update me as soon as possible. ---Thannx AK
[Qemu-devel] [RFC][PATCH 0/2] Allow cache settings for block devices to be changed at runtime.
The following patchset introduces monitor commands: 1. set_cache DEVICE CACHE-SETTING Change cache settings for block device, DEVICE, through the monitor. (Available options : 'none', 'writeback', 'writethrough') Eg, (qemu)set_cache ide0-hd0 none -> Changes cache setting for ide0-hd0 to 'none' 2. info block Now extended to display cache settings for available block devices. TODOS : --- 1. Support 'unsafe' cache mode. 2. Display current cache setting for device, if the CACHE-SETTING option is not supplied by the user. Eg, (qemu)set_cache ide0-hd0 presently errors out. Ideally, it should display current cache setting for the given device ide0-hd0 -- Prerna Saxena Linux Technology Centre, IBM Systems and Technology Lab, Bangalore, India
[Qemu-devel] KVM call agend for Mar 1
Please send in any agenda items you are interested in covering. Thanks, Juan.
[Qemu-devel] [V6 PATCH 9/9] virtio-9p: Chroot environment for other functions
Add chroot functionality for systemcalls that can operate on a file
using relative directory file descriptor.
Signed-off-by: M. Mohan Kumar
---
hw/9pfs/virtio-9p-local.c | 227 +++--
1 files changed, 197 insertions(+), 30 deletions(-)
diff --git a/hw/9pfs/virtio-9p-local.c b/hw/9pfs/virtio-9p-local.c
index f5dba35..b44ad55 100644
--- a/hw/9pfs/virtio-9p-local.c
+++ b/hw/9pfs/virtio-9p-local.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
/* Helper routine to fill V9fsFileObjectRequest structure */
static int fill_fileobjectrequest(V9fsFileObjectRequest *request,
@@ -96,14 +97,35 @@ static int passthrough_create_special(FsContext *fs_ctx,
const char *oldpath,
return retval;
}
+/*
+ * Returns file descriptor of dirname(path)
+ * This fd can be used by *at functions
+ */
+static int get_dirfd(FsContext *fs_ctx, const char *path)
+{
+V9fsFileObjectRequest request;
+int fd;
+char *dpath = qemu_strdup(path);
+
+fd = fill_fileobjectrequest(&request, dirname(dpath), NULL);
+if (fd < 0) {
+return fd;
+}
+request.data.type = T_OPEN;
+fd = v9fs_request(fs_ctx, &request);
+qemu_free(dpath);
+return fd;
+}
+
static int local_lstat(FsContext *fs_ctx, const char *path, struct stat *stbuf)
{
int err;
-err = lstat(rpath(fs_ctx, path), stbuf);
-if (err) {
-return err;
-}
+
if (fs_ctx->fs_sm == SM_MAPPED) {
+err = lstat(rpath(fs_ctx, path), stbuf);
+if (err) {
+return err;
+}
/* Actual credentials are part of extended attrs */
uid_t tmp_uid;
gid_t tmp_gid;
@@ -125,6 +147,27 @@ static int local_lstat(FsContext *fs_ctx, const char
*path, struct stat *stbuf)
sizeof(dev_t)) > 0) {
stbuf->st_rdev = tmp_dev;
}
+} else if (fs_ctx->fs_sm == SM_PASSTHROUGH) {
+int pfd, serrno = 0;
+char *tmp_path;
+
+pfd = get_dirfd(fs_ctx, path);
+if (pfd < 0) {
+return -1;
+}
+tmp_path = qemu_strdup(path);
+err = fstatat(pfd, basename(tmp_path), stbuf, AT_SYMLINK_NOFOLLOW);
+if (err < 0) {
+serrno = errno;
+}
+close(pfd);
+qemu_free(tmp_path);
+errno = serrno;
+} else {
+err = lstat(rpath(fs_ctx, path), stbuf);
+if (err) {
+return err;
+}
}
return err;
}
@@ -189,9 +232,23 @@ static ssize_t local_readlink(FsContext *fs_ctx, const
char *path,
} while (tsize == -1 && errno == EINTR);
close(fd);
return tsize;
-} else if ((fs_ctx->fs_sm == SM_PASSTHROUGH) ||
- (fs_ctx->fs_sm == SM_NONE)) {
+} else if (fs_ctx->fs_sm == SM_NONE) {
tsize = readlink(rpath(fs_ctx, path), buf, bufsz);
+} else if (fs_ctx->fs_sm == SM_PASSTHROUGH) {
+int pfd, serrno = 0;
+char *tmp_path;
+pfd = get_dirfd(fs_ctx, path);
+if (pfd < 0) {
+return -1;
+}
+tmp_path = qemu_strdup(path);
+tsize = readlinkat(pfd, basename(tmp_path), buf, bufsz);
+if (tsize < 0) {
+serrno = 0;
+}
+close(pfd);
+qemu_free(tmp_path);
+errno = serrno;
}
return tsize;
}
@@ -283,8 +340,23 @@ static int local_chmod(FsContext *fs_ctx, const char
*path, FsCred *credp)
{
if (fs_ctx->fs_sm == SM_MAPPED) {
return local_set_xattr(rpath(fs_ctx, path), credp);
-} else if ((fs_ctx->fs_sm == SM_PASSTHROUGH) ||
- (fs_ctx->fs_sm == SM_NONE)) {
+} else if (fs_ctx->fs_sm == SM_PASSTHROUGH) {
+int pfd, err, serrno = 0;
+char *tmp_path;
+pfd = get_dirfd(fs_ctx, path);
+if (pfd < 0) {
+return -1;
+}
+tmp_path = qemu_strdup(path);
+err = fchmodat(pfd, basename(tmp_path), credp->fc_mode, 0);
+if (err == -1) {
+serrno = errno;
+}
+qemu_free(tmp_path);
+close(pfd);
+errno = serrno;
+return err;
+} else if (fs_ctx->fs_sm == SM_NONE) {
return chmod(rpath(fs_ctx, path), credp->fc_mode);
}
return -1;
@@ -532,53 +604,148 @@ static int local_link(FsContext *fs_ctx, const char
*oldpath,
static int local_truncate(FsContext *ctx, const char *path, off_t size)
{
-return truncate(rpath(ctx, path), size);
+if (ctx->fs_sm == SM_PASSTHROUGH) {
+int fd, retval;
+fd = passthrough_open(ctx, path, O_RDWR);
+if (fd < 0) {
+errno = -fd;
+return -1;
+}
+retval = ftruncate(fd, size);
+close(fd);
+return retval;
+} else {
+return truncate(rpath(ctx, path), size);
+}
}
static int local_rename(FsContext *ctx, const char *oldpath,
const char *newpath)
{
-char *tmp;
-int err;
-
-tmp = qemu_strdup
[Qemu-devel] [V6 PATCH 7/9] virtio-9p: Support for creating special files
Add both chroot deamon and qemu side interfaces to create special files
(directory, device nodes, links and symbolic links)
Signed-off-by: M. Mohan Kumar
---
hw/9pfs/virtio-9p-chroot-dm.c | 57
hw/9pfs/virtio-9p-chroot-qemu.c | 19
hw/9pfs/virtio-9p-chroot.h |1 +
hw/9pfs/virtio-9p-local.c | 93 ++-
4 files changed, 139 insertions(+), 31 deletions(-)
diff --git a/hw/9pfs/virtio-9p-chroot-dm.c b/hw/9pfs/virtio-9p-chroot-dm.c
index 985d42b..0ead017 100644
--- a/hw/9pfs/virtio-9p-chroot-dm.c
+++ b/hw/9pfs/virtio-9p-chroot-dm.c
@@ -119,6 +119,57 @@ unset_uid:
setfsuid(cur_uid);
}
+/*
+ * Create directory, symbolic link, link, device node and regular files
+ * Similar to create, but it does not return the fd of created object
+ * Returns 0 as file descriptor on success and -errno on failure in FdInfo
+ * structure
+ */
+static void chroot_do_create_special(V9fsFileObjectRequest *request,
+FdInfo *fd_info)
+{
+int cur_uid, cur_gid;
+
+cur_uid = geteuid();
+cur_gid = getegid();
+
+fd_info->fi_fd = -1;
+/* fd is not valid for create operations */
+fd_info->fi_flags = FI_FD_INVALID;
+
+if (setfsuid(request->data.uid) < 0) {
+fd_info->fi_fd = -errno;
+return;
+}
+if (setfsgid(request->data.gid) < 0) {
+fd_info->fi_fd = -errno;
+goto unset_uid;
+}
+
+switch (request->data.type) {
+case T_MKDIR:
+fd_info->fi_fd = mkdir(request->path.path, request->data.mode);
+break;
+case T_SYMLINK:
+fd_info->fi_fd = symlink(request->path.old_path, request->path.path);
+break;
+case T_LINK:
+fd_info->fi_fd = link(request->path.old_path, request->path.path);
+break;
+default:
+fd_info->fi_fd = mknod(request->path.path, request->data.mode,
+request->data.dev);
+break;
+}
+
+if (fd_info->fi_fd < 0) {
+fd_info->fi_fd = -errno;
+}
+setfsgid(cur_gid);
+unset_uid:
+setfsuid(cur_uid);
+}
+
static int chroot_daemonize(int chroot_sock)
{
sigset_t sigset;
@@ -216,6 +267,12 @@ int v9fs_chroot(FsContext *fs_ctx)
case T_CREATE:
chroot_do_create(&request, &fd_info);
break;
+case T_MKDIR:
+case T_SYMLINK:
+case T_LINK:
+case T_MKNOD:
+chroot_do_create_special(&request, &fd_info);
+break;
default:
fd_info.fi_flags = FI_FD_SOCKERR;
break;
diff --git a/hw/9pfs/virtio-9p-chroot-qemu.c b/hw/9pfs/virtio-9p-chroot-qemu.c
index 41f9db2..1a42dc2 100644
--- a/hw/9pfs/virtio-9p-chroot-qemu.c
+++ b/hw/9pfs/virtio-9p-chroot-qemu.c
@@ -103,3 +103,22 @@ unlock:
qemu_mutex_unlock(&fs_ctx->chroot_mutex);
return fd;
}
+
+/* Return 0 on success or -errno on error */
+int v9fs_create_special(FsContext *fs_ctx, V9fsFileObjectRequest *request)
+{
+int fd, sock_error;
+qemu_mutex_lock(&fs_ctx->chroot_mutex);
+if (fs_ctx->chroot_ioerror) {
+fd = -EIO;
+goto unlock;
+}
+v9fs_write_request(fs_ctx->chroot_socket, request);
+fd = v9fs_receivefd(fs_ctx->chroot_socket, &sock_error);
+if (fd < 0 && sock_error) {
+fs_ctx->chroot_ioerror = 1;
+}
+unlock:
+qemu_mutex_unlock(&fs_ctx->chroot_mutex);
+return fd;
+}
diff --git a/hw/9pfs/virtio-9p-chroot.h b/hw/9pfs/virtio-9p-chroot.h
index 4592807..f113ff1 100644
--- a/hw/9pfs/virtio-9p-chroot.h
+++ b/hw/9pfs/virtio-9p-chroot.h
@@ -54,5 +54,6 @@ typedef struct V9fsFileObjectRequest
int v9fs_chroot(FsContext *fs_ctx);
int v9fs_request(FsContext *fs_ctx, V9fsFileObjectRequest *or);
+int v9fs_create_special(FsContext *fs_ctx, V9fsFileObjectRequest *request);
#endif /* _QEMU_VIRTIO_9P_CHROOT_H */
diff --git a/hw/9pfs/virtio-9p-local.c b/hw/9pfs/virtio-9p-local.c
index 3fed16c..c92c5dd 100644
--- a/hw/9pfs/virtio-9p-local.c
+++ b/hw/9pfs/virtio-9p-local.c
@@ -74,6 +74,28 @@ static int passthrough_create(FsContext *fs_ctx, const char
*path, int flags,
return fd;
}
+static int passthrough_create_special(FsContext *fs_ctx, const char *oldpath,
+const char *path, FsCred *credp, int type)
+{
+V9fsFileObjectRequest request;
+int retval;
+
+retval = fill_fileobjectrequest(&request, path, credp);
+if (retval < 0) {
+return retval;
+}
+request.data.type = type;
+if (oldpath) {
+request.data.oldpath_len = strlen(oldpath);
+if (strlen(oldpath) > PATH_MAX) {
+return -ENAMETOOLONG;
+}
+strcpy(request.path.old_path, oldpath);
+}
+retval = v9fs_create_special(fs_ctx, &request);
+return retval;
+}
+
static int local_lstat(FsContext *fs_ctx, const char *path, struct stat *stbuf)
{
int err;
@@ -291,8 +313,7 @@ static int local_mknod(FsContext *fs_ctx, const char *path,
FsCred *cr
[Qemu-devel] [V6 PATCH 5/9] virtio-9p: Add support to open a file in chroot environment
This patch adds both chroot deamon and qemu side support to open a file/
directory in the chroot environment
Signed-off-by: M. Mohan Kumar
---
hw/9pfs/virtio-9p-chroot-qemu.c | 24 +++-
hw/9pfs/virtio-9p-chroot.h |2 +-
hw/9pfs/virtio-9p-local.c | 58 ---
3 files changed, 71 insertions(+), 13 deletions(-)
diff --git a/hw/9pfs/virtio-9p-chroot-qemu.c b/hw/9pfs/virtio-9p-chroot-qemu.c
index d2d8ab9..41f9db2 100644
--- a/hw/9pfs/virtio-9p-chroot-qemu.c
+++ b/hw/9pfs/virtio-9p-chroot-qemu.c
@@ -85,13 +85,21 @@ static int v9fs_write_request(int sockfd,
V9fsFileObjectRequest *request)
return 0;
}
-/*
- * This patch adds v9fs_receivefd and v9fs_write_request functions,
- * but there is no callers. To avoid compiler warning message,
- * refer these two functions
- */
-void chroot_dummy(void)
+/* Return opened file descriptor on success or -errno on error */
+int v9fs_request(FsContext *fs_ctx, V9fsFileObjectRequest *request)
{
-(void)v9fs_receivefd;
-(void)v9fs_write_request;
+int fd, sock_error;
+qemu_mutex_lock(&fs_ctx->chroot_mutex);
+if (fs_ctx->chroot_ioerror) {
+fd = -EIO;
+goto unlock;
+}
+v9fs_write_request(fs_ctx->chroot_socket, request);
+fd = v9fs_receivefd(fs_ctx->chroot_socket, &sock_error);
+if (fd < 0 && sock_error) {
+fs_ctx->chroot_ioerror = 1;
+}
+unlock:
+qemu_mutex_unlock(&fs_ctx->chroot_mutex);
+return fd;
}
diff --git a/hw/9pfs/virtio-9p-chroot.h b/hw/9pfs/virtio-9p-chroot.h
index bd186dd..4592807 100644
--- a/hw/9pfs/virtio-9p-chroot.h
+++ b/hw/9pfs/virtio-9p-chroot.h
@@ -53,6 +53,6 @@ typedef struct V9fsFileObjectRequest
} V9fsFileObjectRequest;
int v9fs_chroot(FsContext *fs_ctx);
-void chroot_dummy(void);
+int v9fs_request(FsContext *fs_ctx, V9fsFileObjectRequest *or);
#endif /* _QEMU_VIRTIO_9P_CHROOT_H */
diff --git a/hw/9pfs/virtio-9p-local.c b/hw/9pfs/virtio-9p-local.c
index 0a015de..0c55d35 100644
--- a/hw/9pfs/virtio-9p-local.c
+++ b/hw/9pfs/virtio-9p-local.c
@@ -13,6 +13,9 @@
#include "virtio.h"
#include "virtio-9p.h"
#include "virtio-9p-xattr.h"
+#include "qemu_socket.h"
+#include "fsdev/qemu-fsdev.h"
+#include "virtio-9p-chroot.h"
#include
#include
#include
@@ -20,6 +23,40 @@
#include
#include
+/* Helper routine to fill V9fsFileObjectRequest structure */
+static int fill_fileobjectrequest(V9fsFileObjectRequest *request,
+const char *path, FsCred *credp)
+{
+if (strlen(path) > PATH_MAX) {
+return -ENAMETOOLONG;
+}
+memset(request, 0, sizeof(*request));
+request->data.path_len = strlen(path);
+strcpy(request->path.path, path);
+if (credp) {
+request->data.mode = credp->fc_mode;
+request->data.uid = credp->fc_uid;
+request->data.gid = credp->fc_gid;
+request->data.dev = credp->fc_rdev;
+}
+return 0;
+}
+
+static int passthrough_open(FsContext *fs_ctx, const char *path, int flags)
+{
+V9fsFileObjectRequest request;
+int fd;
+
+fd = fill_fileobjectrequest(&request, path, NULL);
+if (fd < 0) {
+errno = -fd;
+return -1;
+}
+request.data.flags = flags;
+request.data.type = T_OPEN;
+fd = v9fs_request(fs_ctx, &request);
+return fd;
+}
static int local_lstat(FsContext *fs_ctx, const char *path, struct stat *stbuf)
{
@@ -138,14 +175,27 @@ static int local_closedir(FsContext *ctx, DIR *dir)
return closedir(dir);
}
-static int local_open(FsContext *ctx, const char *path, int flags)
+static int local_open(FsContext *fs_ctx, const char *path, int flags)
{
-return open(rpath(ctx, path), flags);
+if (fs_ctx->fs_sm == SM_PASSTHROUGH) {
+return passthrough_open(fs_ctx, path, flags);
+} else {
+return open(rpath(fs_ctx, path), flags);
+}
}
-static DIR *local_opendir(FsContext *ctx, const char *path)
+static DIR *local_opendir(FsContext *fs_ctx, const char *path)
{
-return opendir(rpath(ctx, path));
+if (fs_ctx->fs_sm == SM_PASSTHROUGH) {
+int fd;
+fd = passthrough_open(fs_ctx, path, O_DIRECTORY);
+if (fd < 0) {
+return NULL;
+}
+return fdopendir(fd);
+} else {
+return opendir(rpath(fs_ctx, path));
+}
}
static void local_rewinddir(FsContext *ctx, DIR *dir)
--
1.7.3.4
[Qemu-devel] [V6 PATCH 4/9] virtio-9p: Add qemu side interfaces for chroot environment
QEMU side interfaces to communicate with chroot daemon process.
Signed-off-by: M. Mohan Kumar
---
Makefile.objs |2 +-
hw/9pfs/virtio-9p-chroot-qemu.c | 97 +++
hw/9pfs/virtio-9p-chroot.h |1 +
3 files changed, 99 insertions(+), 1 deletions(-)
create mode 100644 hw/9pfs/virtio-9p-chroot-qemu.c
diff --git a/Makefile.objs b/Makefile.objs
index f09cdee..9ea7946 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -283,7 +283,7 @@ hw-obj-$(CONFIG_SOUND) += $(sound-obj-y)
9pfs-nested-$(CONFIG_VIRTFS) = virtio-9p-debug.o
9pfs-nested-$(CONFIG_VIRTFS) += virtio-9p-local.o virtio-9p-xattr.o
9pfs-nested-$(CONFIG_VIRTFS) += virtio-9p-xattr-user.o virtio-9p-posix-acl.o
-9pfs-nested-$(CONFIG_VIRTFS) += virtio-9p-chroot-dm.o
+9pfs-nested-$(CONFIG_VIRTFS) += virtio-9p-chroot-dm.o virtio-9p-chroot-qemu.o
hw-obj-$(CONFIG_REALLY_VIRTFS) += $(addprefix 9pfs/, $(9pfs-nested-y))
$(addprefix 9pfs/, $(9pfs-nested-y)): CFLAGS += -I$(SRC_PATH)/hw/
diff --git a/hw/9pfs/virtio-9p-chroot-qemu.c b/hw/9pfs/virtio-9p-chroot-qemu.c
new file mode 100644
index 000..d2d8ab9
--- /dev/null
+++ b/hw/9pfs/virtio-9p-chroot-qemu.c
@@ -0,0 +1,97 @@
+/*
+ * Virtio 9p chroot environment for contained access to exported path
+ * Code handles qemu side interfaces to communicate with chroot daemon process
+ * Copyright IBM, Corp. 2011
+ *
+ * Authors:
+ * M. Mohan Kumar
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the copying file in the top-level directory
+ *
+ */
+
+#include
+#include
+#include
+#include "virtio.h"
+#include "qemu_socket.h"
+#include "qemu-thread.h"
+#include "qerror.h"
+#include "virtio-9p.h"
+#include "virtio-9p-chroot.h"
+
+/*
+ * Return received file descriptor on success and -errno on failure.
+ * sock_error is set to 1 whenever there is error in socket IO
+ */
+static int v9fs_receivefd(int sockfd, int *sock_error)
+{
+struct msghdr msg = { };
+struct iovec iov;
+union MsgControl msg_control;
+struct cmsghdr *cmsg;
+int retval, fd;
+FdInfo fd_info;
+
+iov.iov_base = &fd_info;
+iov.iov_len = sizeof(fd_info);
+
+*sock_error = 0;
+memset(&msg, 0, sizeof(msg));
+msg.msg_iov = &iov;
+msg.msg_iovlen = 1;
+msg.msg_control = &msg_control;
+msg.msg_controllen = sizeof(msg_control);
+
+retval = recvmsg(sockfd, &msg, 0);
+if (retval < 0) {
+*sock_error = 1;
+return -EIO;
+}
+if (fd_info.fi_flags & FI_FD_SOCKERR) {
+*sock_error = 1;
+return -EIO;
+}
+/* If fd is invalid, ancillary data is not present */
+if (fd_info.fi_fd < 0 || fd_info.fi_flags & FI_FD_INVALID) {
+return fd_info.fi_fd;
+}
+
+for (cmsg = CMSG_FIRSTHDR(&msg); cmsg; cmsg = CMSG_NXTHDR(&msg, cmsg)) {
+if (cmsg->cmsg_len != CMSG_LEN(sizeof(int)) ||
+cmsg->cmsg_level != SOL_SOCKET ||
+cmsg->cmsg_type != SCM_RIGHTS) {
+continue;
+}
+fd = *((int *)CMSG_DATA(cmsg));
+return fd;
+}
+*sock_error = 1;
+return -EIO;
+}
+
+/*
+ * V9fsFileObjectRequest is written into the socket by QEMU process.
+ * Then this request is read by chroot process using v9fs_read_request function
+ */
+static int v9fs_write_request(int sockfd, V9fsFileObjectRequest *request)
+{
+int retval;
+retval = qemu_write_full(sockfd, request, sizeof(*request));
+if (retval != sizeof(*request)) {
+return -EIO;
+}
+return 0;
+}
+
+/*
+ * This patch adds v9fs_receivefd and v9fs_write_request functions,
+ * but there is no callers. To avoid compiler warning message,
+ * refer these two functions
+ */
+void chroot_dummy(void)
+{
+(void)v9fs_receivefd;
+(void)v9fs_write_request;
+}
diff --git a/hw/9pfs/virtio-9p-chroot.h b/hw/9pfs/virtio-9p-chroot.h
index a5b2a41..bd186dd 100644
--- a/hw/9pfs/virtio-9p-chroot.h
+++ b/hw/9pfs/virtio-9p-chroot.h
@@ -53,5 +53,6 @@ typedef struct V9fsFileObjectRequest
} V9fsFileObjectRequest;
int v9fs_chroot(FsContext *fs_ctx);
+void chroot_dummy(void);
#endif /* _QEMU_VIRTIO_9P_CHROOT_H */
--
1.7.3.4
[Qemu-devel] [V6 PATCH 6/9] virtio-9p: Create support in chroot environment
Add both chroot deamon & qemu side interfaces to create regular files in
chroot environment
Signed-off-by: M. Mohan Kumar
---
hw/9pfs/virtio-9p-chroot-dm.c | 39 +++
hw/9pfs/virtio-9p-local.c | 21 +++--
2 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/hw/9pfs/virtio-9p-chroot-dm.c b/hw/9pfs/virtio-9p-chroot-dm.c
index c1d8c6e..985d42b 100644
--- a/hw/9pfs/virtio-9p-chroot-dm.c
+++ b/hw/9pfs/virtio-9p-chroot-dm.c
@@ -83,6 +83,42 @@ static void chroot_do_open(V9fsFileObjectRequest *request,
FdInfo *fd_info)
}
}
+/*
+ * Helper routine to create a file and return the file descriptor and
+ * error status in FdInfo structure.
+ */
+static void chroot_do_create(V9fsFileObjectRequest *request, FdInfo *fd_info)
+{
+uid_t cur_uid;
+gid_t cur_gid;
+
+cur_uid = geteuid();
+cur_gid = getegid();
+
+fd_info->fi_fd = -1;
+
+if (setfsuid(request->data.uid) < 0) {
+fd_info->fi_fd = -errno;
+fd_info->fi_flags = FI_FD_INVALID;
+return;
+}
+if (setfsgid(request->data.gid) < 0) {
+fd_info->fi_fd = -errno;
+fd_info->fi_flags = FI_FD_INVALID;
+goto unset_uid;
+}
+
+fd_info->fi_fd = open(request->path.path, request->data.flags,
+request->data.mode);
+if (fd_info->fi_fd < 0) {
+fd_info->fi_fd = -errno;
+fd_info->fi_flags = FI_FD_INVALID;
+}
+setfsgid(cur_gid);
+unset_uid:
+setfsuid(cur_uid);
+}
+
static int chroot_daemonize(int chroot_sock)
{
sigset_t sigset;
@@ -177,6 +213,9 @@ int v9fs_chroot(FsContext *fs_ctx)
case T_OPEN:
chroot_do_open(&request, &fd_info);
break;
+case T_CREATE:
+chroot_do_create(&request, &fd_info);
+break;
default:
fd_info.fi_flags = FI_FD_SOCKERR;
break;
diff --git a/hw/9pfs/virtio-9p-local.c b/hw/9pfs/virtio-9p-local.c
index 0c55d35..3fed16c 100644
--- a/hw/9pfs/virtio-9p-local.c
+++ b/hw/9pfs/virtio-9p-local.c
@@ -58,6 +58,22 @@ static int passthrough_open(FsContext *fs_ctx, const char
*path, int flags)
return fd;
}
+static int passthrough_create(FsContext *fs_ctx, const char *path, int flags,
+FsCred *credp)
+{
+V9fsFileObjectRequest request;
+int fd;
+
+fd = fill_fileobjectrequest(&request, path, credp);
+if (fd < 0) {
+return fd;
+}
+request.data.flags = flags;
+request.data.type = T_CREATE;
+fd = v9fs_request(fs_ctx, &request);
+return fd;
+}
+
static int local_lstat(FsContext *fs_ctx, const char *path, struct stat *stbuf)
{
int err;
@@ -382,8 +398,7 @@ static int local_open2(FsContext *fs_ctx, const char *path,
int flags,
serrno = errno;
goto err_end;
}
-} else if ((fs_ctx->fs_sm == SM_PASSTHROUGH) ||
- (fs_ctx->fs_sm == SM_NONE)) {
+} else if (fs_ctx->fs_sm == SM_NONE) {
fd = open(rpath(fs_ctx, path), flags, credp->fc_mode);
if (fd == -1) {
return fd;
@@ -393,6 +408,8 @@ static int local_open2(FsContext *fs_ctx, const char *path,
int flags,
serrno = errno;
goto err_end;
}
+} else if (fs_ctx->fs_sm == SM_PASSTHROUGH) {
+fd = passthrough_create(fs_ctx, path, flags, credp);
}
return fd;
--
1.7.3.4
[Qemu-devel] [V6 PATCH 3/9] virtio-9p: Provide chroot daemon side interfaces
Implement chroot daemon side interfaces like sending the file
descriptor to qemu process, reading the object request from socket etc.
Also add chroot main function and other helper routines.
Signed-off-by: M. Mohan Kumar
---
Makefile.objs |1 +
hw/9pfs/virtio-9p-chroot-dm.c | 186 +
hw/9pfs/virtio-9p-chroot.h| 57 +
hw/9pfs/virtio-9p.c | 32 +++
hw/file-op-9p.h |4 +
5 files changed, 280 insertions(+), 0 deletions(-)
create mode 100644 hw/9pfs/virtio-9p-chroot-dm.c
create mode 100644 hw/9pfs/virtio-9p-chroot.h
diff --git a/Makefile.objs b/Makefile.objs
index 6a9f765..f09cdee 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -283,6 +283,7 @@ hw-obj-$(CONFIG_SOUND) += $(sound-obj-y)
9pfs-nested-$(CONFIG_VIRTFS) = virtio-9p-debug.o
9pfs-nested-$(CONFIG_VIRTFS) += virtio-9p-local.o virtio-9p-xattr.o
9pfs-nested-$(CONFIG_VIRTFS) += virtio-9p-xattr-user.o virtio-9p-posix-acl.o
+9pfs-nested-$(CONFIG_VIRTFS) += virtio-9p-chroot-dm.o
hw-obj-$(CONFIG_REALLY_VIRTFS) += $(addprefix 9pfs/, $(9pfs-nested-y))
$(addprefix 9pfs/, $(9pfs-nested-y)): CFLAGS += -I$(SRC_PATH)/hw/
diff --git a/hw/9pfs/virtio-9p-chroot-dm.c b/hw/9pfs/virtio-9p-chroot-dm.c
new file mode 100644
index 000..c1d8c6e
--- /dev/null
+++ b/hw/9pfs/virtio-9p-chroot-dm.c
@@ -0,0 +1,186 @@
+/*
+ * Virtio 9p chroot environment for contained access to the exported path
+ * Code path handles chroot daemon interfaces
+ * Copyright IBM, Corp. 2011
+ *
+ * Authors:
+ * M. Mohan Kumar
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the copying file in the top-level directory
+ *
+ */
+
+#include
+#include
+#include
+#include "virtio.h"
+#include "qemu_socket.h"
+#include "qemu-thread.h"
+#include "qerror.h"
+#include "virtio-9p.h"
+#include "virtio-9p-chroot.h"
+
+/* Send file descriptor and error status to qemu process */
+static void chroot_sendfd(int sockfd, const FdInfo *fd_info)
+{
+struct msghdr msg = { };
+struct iovec iov;
+struct cmsghdr *cmsg;
+int retval;
+union MsgControl msg_control;
+
+iov.iov_base = (void *)fd_info;
+iov.iov_len = sizeof(*fd_info);
+
+memset(&msg, 0, sizeof(msg));
+msg.msg_iov = &iov;
+msg.msg_iovlen = 1;
+/* No ancillary data on error/fd invalid flag */
+if (!(fd_info->fi_flags & FI_FD_INVALID)) {
+msg.msg_control = &msg_control;
+msg.msg_controllen = sizeof(msg_control);
+
+cmsg = &msg_control.cmsg;
+cmsg->cmsg_len = CMSG_LEN(sizeof(fd_info->fi_fd));
+cmsg->cmsg_level = SOL_SOCKET;
+cmsg->cmsg_type = SCM_RIGHTS;
+memcpy(CMSG_DATA(cmsg), &fd_info->fi_fd, sizeof(fd_info->fi_fd));
+}
+retval = sendmsg(sockfd, &msg, 0);
+if (retval < 0) {
+_exit(1);
+}
+if (!(fd_info->fi_flags & FI_FD_INVALID)) {
+close(fd_info->fi_fd);
+}
+}
+
+/* Read V9fsFileObjectRequest sent by QEMU process */
+static int chroot_read_request(int sockfd, V9fsFileObjectRequest *request)
+{
+int retval;
+retval = qemu_read_full(sockfd, request, sizeof(*request));
+if (retval != sizeof(*request)) {
+if (errno == EBADF) {
+_exit(1);
+}
+return -EIO;
+}
+return 0;
+}
+
+/*
+ * Helper routine to open a file and return response through
+ * FdInfo structure
+ */
+static void chroot_do_open(V9fsFileObjectRequest *request, FdInfo *fd_info)
+{
+fd_info->fi_fd = open(request->path.path, request->data.flags);
+if (fd_info->fi_fd < 0) {
+fd_info->fi_fd = -errno;
+fd_info->fi_flags = FI_FD_INVALID;
+}
+}
+
+static int chroot_daemonize(int chroot_sock)
+{
+sigset_t sigset;
+struct rlimit nr_fd;
+int fd;
+
+/* Block all signals for this process */
+sigfillset(&sigset);
+sigprocmask(SIG_SETMASK, &sigset, NULL);
+
+/* Close other file descriptors */
+getrlimit(RLIMIT_NOFILE, &nr_fd);
+for (fd = 0; fd < nr_fd.rlim_cur; fd++) {
+if (fd != chroot_sock) {
+close(fd);
+}
+}
+chdir("/");
+/* Create files with mode as per request */
+umask(0);
+return 0;
+}
+
+/*
+ * Fork a process and chroot into the share path. Communication
+ * between qemu process and chroot process happens via socket.
+ * All file descriptors (including stdout and stderr) are closed
+ * except one socket descriptor (which is used for communicating
+ * between qemu process and chroot process).
+ * Note: To avoid errors in forked process in multi threaded environment
+ * only async-signal safe functions used. For more information see
+ * man fork(3p), signal(7)
+ */
+int v9fs_chroot(FsContext *fs_ctx)
+{
+int fd_pair[2], chroot_sock, error;
+V9fsFileObjectRequest request;
+pid_t pid;
+uint64_t code;
+FdInfo fd_info;
+
+if (socketpair(PF_UNIX, SOCK_STREAM, 0, fd_pair) < 0) {
+error_report("socketpair %s", strerror
[Qemu-devel] [V6 PATCH 2/9] virtio-9p: Enable CONFIG_THREAD if CONFIG_VIRTFS is enabled
9p Chroot environment needs APIs defined in qemu-thread.c, so enable CONFIG_THREAD if virtfs is enabled Signed-off-by: M. Mohan Kumar --- configure |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/configure b/configure index 2560357..9eddd38 100755 --- a/configure +++ b/configure @@ -2767,6 +2767,7 @@ fi if test "$linux" = "yes" ; then if test "$attr" = "yes" ; then echo "CONFIG_VIRTFS=y" >> $config_host_mak +echo "CONFIG_THREAD=y" >> $config_host_mak fi fi if test "$blobs" = "yes" ; then -- 1.7.3.4
[Qemu-devel] [V6 PATCH 1/9] Implement qemu_read_full
Add qemu_read_full function
Signed-off-by: M. Mohan Kumar
---
osdep.c | 32
qemu-common.h |2 ++
2 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/osdep.c b/osdep.c
index 327583b..8d84a88 100644
--- a/osdep.c
+++ b/osdep.c
@@ -127,6 +127,38 @@ ssize_t qemu_write_full(int fd, const void *buf, size_t
count)
}
/*
+ * A variant of read(2) which handles interrupted read.
+ * Simlar to qemu_write_full function
+ *
+ * Return the number of bytes read.
+ *
+ * This function does not work with non-blocking fd's.
+ * errno is set if fewer than `count' bytes are read because of any
+ * error
+ */
+ssize_t qemu_read_full(int fd, void *buf, size_t count)
+{
+ssize_t ret = 0;
+ssize_t total = 0;
+
+while (count) {
+ret = read(fd, buf, count);
+if (ret <= 0) {
+if (errno == EINTR) {
+continue;
+}
+break;
+}
+
+count -= ret;
+buf += ret;
+total += ret;
+}
+
+return total;
+}
+
+/*
* Opens a socket with FD_CLOEXEC set
*/
int qemu_socket(int domain, int type, int protocol)
diff --git a/qemu-common.h b/qemu-common.h
index 40dad52..325b16a 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -207,6 +207,8 @@ void qemu_mutex_unlock_iothread(void);
int qemu_open(const char *name, int flags, ...);
ssize_t qemu_write_full(int fd, const void *buf, size_t count)
QEMU_WARN_UNUSED_RESULT;
+ssize_t qemu_read_full(int fd, void *buf, size_t count)
+QEMU_WARN_UNUSED_RESULT;
void qemu_set_cloexec(int fd);
#ifndef _WIN32
--
1.7.3.4
[Qemu-devel] [V6 PATCH 8/9] virtio-9p: Move file post creation changes to none security model
After creating a file object, its permission and ownership details are updated
as per 9p client's request for both passthrough and none security model.
But with chrooted environment its not required for passthrough security model.
Move all post file creation changes to none security model.
Signed-off-by: M. Mohan Kumar
---
hw/9pfs/virtio-9p-local.c | 19 ++-
1 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/hw/9pfs/virtio-9p-local.c b/hw/9pfs/virtio-9p-local.c
index c92c5dd..f5dba35 100644
--- a/hw/9pfs/virtio-9p-local.c
+++ b/hw/9pfs/virtio-9p-local.c
@@ -163,21 +163,14 @@ static int local_set_xattr(const char *path, FsCred
*credp)
return 0;
}
-static int local_post_create_passthrough(FsContext *fs_ctx, const char *path,
+static int local_post_create_none(FsContext *fs_ctx, const char *path,
FsCred *credp)
{
+int retval;
if (chmod(rpath(fs_ctx, path), credp->fc_mode & 0) < 0) {
return -1;
}
-if (lchown(rpath(fs_ctx, path), credp->fc_uid, credp->fc_gid) < 0) {
-/*
- * If we fail to change ownership and if we are
- * using security model none. Ignore the error
- */
-if (fs_ctx->fs_sm != SM_NONE) {
-return -1;
-}
-}
+retval = lchown(rpath(fs_ctx, path), credp->fc_uid, credp->fc_gid);
return 0;
}
@@ -318,7 +311,7 @@ static int local_mknod(FsContext *fs_ctx, const char *path,
FsCred *credp)
if (err == -1) {
return err;
}
-err = local_post_create_passthrough(fs_ctx, path, credp);
+err = local_post_create_none(fs_ctx, path, credp);
if (err == -1) {
serrno = errno;
goto err_end;
@@ -360,7 +353,7 @@ static int local_mkdir(FsContext *fs_ctx, const char *path,
FsCred *credp)
if (err == -1) {
return err;
}
-err = local_post_create_passthrough(fs_ctx, path, credp);
+err = local_post_create_none(fs_ctx, path, credp);
if (err == -1) {
serrno = errno;
goto err_end;
@@ -435,7 +428,7 @@ static int local_open2(FsContext *fs_ctx, const char *path,
int flags,
if (fd == -1) {
return fd;
}
-err = local_post_create_passthrough(fs_ctx, path, credp);
+err = local_post_create_none(fs_ctx, path, credp);
if (err == -1) {
serrno = errno;
goto err_end;
--
1.7.3.4
[Qemu-devel] [PATCH (resend, rebase) 3/3] virtio-serial: Enable ioeventfd
Enable ioeventfd for virtio-serial devices by default. Commit
25db9ebe15125deb32958c6df74996f745edf1f9 lists the benefits of using
ioeventfd.
Copying a file from guest to host over a virtio-serial channel didn't
show much difference in time or io_exit rate.
Signed-off-by: Amit Shah
---
hw/virtio-pci.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index 952b5d2..ef65590 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -789,6 +789,7 @@ static int virtio_serial_exit_pci(PCIDevice *pci_dev)
{
VirtIOPCIProxy *proxy = DO_UPCAST(VirtIOPCIProxy, pci_dev, pci_dev);
+virtio_pci_stop_ioeventfd(proxy);
virtio_serial_exit(proxy->vdev);
return virtio_exit_pci(pci_dev);
}
@@ -898,6 +899,8 @@ static PCIDeviceInfo virtio_info[] = {
.init = virtio_serial_init_pci,
.exit = virtio_serial_exit_pci,
.qdev.props = (Property[]) {
+DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, flags,
+VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, true),
DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors,
DEV_NVECTORS_UNSPECIFIED),
DEFINE_PROP_HEX32("class", VirtIOPCIProxy, class_code, 0),
--
1.7.4
Re: [Qemu-devel] Fix build errors introduced by vnc jpeg changes
On 28 February 2011 10:48, David Gibson wrote: > The recent changes to handling of jpegs over tight vnc connections > cause build errors if qemu is configured with --disable-vnc-jpeg. The > patch below corrects the errors, by adding some left out #ifdefs. > > Please apply. > > Signed-off-by: David Gibson This is already fixed in master: http://git.qemu.org/qemu.git/commit/?id=cf76a1ce8b7cf4b92429d67d3f4626a92b2d8a37 -- PMM
[Qemu-devel] [PATCH (resend, rebase) 2/3] virtio-serial: Disallow generic ports at id 0
It was found libvirt was using port 0 for generic ports. It has been
fixed in libvirt commit 8e28c5d40200b4c5d483bd585d237b9d870372e5.
Port 0 is reserved for virtconsole devices for backward compatibility
with the old -virtioconsole (from qemu 0.12) device type.
Ensure we don't allow instantiating a port at id 0 as well.
Signed-off-by: Amit Shah
---
hw/virtio-console.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/hw/virtio-console.c b/hw/virtio-console.c
index c235b27..699f190 100644
--- a/hw/virtio-console.c
+++ b/hw/virtio-console.c
@@ -11,6 +11,7 @@
*/
#include "qemu-char.h"
+#include "qemu-error.h"
#include "virtio-serial.h"
typedef struct VirtConsole {
@@ -113,7 +114,15 @@ static int virtserialport_initfn(VirtIOSerialPort *port)
{
VirtConsole *vcon = DO_UPCAST(VirtConsole, port, port);
-return generic_port_init(vcon, port);
+if (port->id == 0) {
+/*
+ * Disallow a generic port at id 0, that's reserved for
+ * console ports.
+ */
+error_report("Port number 0 on virtio-serial devices reserved for
virtconsole devices for backward compatibility.");
+return -1;
+}
+return generic_port_init(vcon, dev);
}
static VirtIOSerialPortInfo virtserialport_info = {
--
1.7.4
[Qemu-devel] [PULL (resend, rebase) 0/3] virtio-serial fixes, ioeventfd support
Rebased version from last week: The following changes since commit 417131fb9ad3f6dd7177a338cc5f143dec4d75f0: HACKING: Update status of format checking (2011-02-25 16:31:05 -0600) are available in the git repository at: git://git.kernel.org/pub/scm/virt/qemu/amit/virtio-serial.git for-anthony Amit Shah (3): virtio-serial: Use a struct to pass config information from proxy virtio-serial: Disallow generic ports at id 0 virtio-serial: Enable ioeventfd hw/virtio-console.c| 11 ++- hw/virtio-pci.c| 15 +-- hw/virtio-serial-bus.c | 16 hw/virtio-serial.h |5 + hw/virtio.h|3 ++- 5 files changed, 34 insertions(+), 16 deletions(-) -- 1.7.4
[Qemu-devel] [PATCH (resend, rebase) 1/3] virtio-serial: Use a struct to pass config information from proxy
Instead of using a single variable to pass to the virtio_serial_init
function, use a struct so that expanding the number of variables to be
passed on later is easier.
Signed-off-by: Amit Shah
---
hw/virtio-pci.c| 12 ++--
hw/virtio-serial-bus.c | 16
hw/virtio-serial.h |5 +
hw/virtio.h|3 ++-
4 files changed, 21 insertions(+), 15 deletions(-)
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index 3911b09..952b5d2 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -18,6 +18,7 @@
#include "virtio.h"
#include "virtio-blk.h"
#include "virtio-net.h"
+#include "virtio-serial.h"
#include "pci.h"
#include "qemu-error.h"
#include "msix.h"
@@ -109,8 +110,7 @@ typedef struct {
#ifdef CONFIG_LINUX
V9fsConf fsconf;
#endif
-/* Max. number of ports we can have for a the virtio-serial device */
-uint32_t max_virtserial_ports;
+virtio_serial_conf serial;
virtio_net_conf net;
bool ioeventfd_disabled;
bool ioeventfd_started;
@@ -770,12 +770,12 @@ static int virtio_serial_init_pci(PCIDevice *pci_dev)
proxy->class_code != PCI_CLASS_OTHERS) /* qemu-kvm */
proxy->class_code = PCI_CLASS_COMMUNICATION_OTHER;
-vdev = virtio_serial_init(&pci_dev->qdev, proxy->max_virtserial_ports);
+vdev = virtio_serial_init(&pci_dev->qdev, &proxy->serial);
if (!vdev) {
return -1;
}
vdev->nvectors = proxy->nvectors == DEV_NVECTORS_UNSPECIFIED
-? proxy->max_virtserial_ports + 1
+? proxy->serial.max_virtserial_ports +
1
: proxy->nvectors;
virtio_init_pci(proxy, vdev,
PCI_VENDOR_ID_REDHAT_QUMRANET,
@@ -902,8 +902,8 @@ static PCIDeviceInfo virtio_info[] = {
DEV_NVECTORS_UNSPECIFIED),
DEFINE_PROP_HEX32("class", VirtIOPCIProxy, class_code, 0),
DEFINE_VIRTIO_COMMON_FEATURES(VirtIOPCIProxy, host_features),
-DEFINE_PROP_UINT32("max_ports", VirtIOPCIProxy,
max_virtserial_ports,
- 31),
+DEFINE_PROP_UINT32("max_ports", VirtIOPCIProxy,
+ serial.max_virtserial_ports, 31),
DEFINE_PROP_END_OF_LIST(),
},
.qdev.reset = virtio_pci_reset,
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index 8446bc2..c6feb43 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -811,19 +811,19 @@ void
virtio_serial_port_qdev_register(VirtIOSerialPortInfo *info)
qdev_register(&info->qdev);
}
-VirtIODevice *virtio_serial_init(DeviceState *dev, uint32_t max_nr_ports)
+VirtIODevice *virtio_serial_init(DeviceState *dev, virtio_serial_conf *conf)
{
VirtIOSerial *vser;
VirtIODevice *vdev;
uint32_t i, max_supported_ports;
-if (!max_nr_ports)
+if (!conf->max_virtserial_ports)
return NULL;
/* Each port takes 2 queues, and one pair is for the control queue */
max_supported_ports = VIRTIO_PCI_QUEUE_MAX / 2 - 1;
-if (max_nr_ports > max_supported_ports) {
+if (conf->max_virtserial_ports > max_supported_ports) {
error_report("maximum ports supported: %u", max_supported_ports);
return NULL;
}
@@ -839,9 +839,9 @@ VirtIODevice *virtio_serial_init(DeviceState *dev, uint32_t
max_nr_ports)
vser->bus->vser = vser;
QTAILQ_INIT(&vser->ports);
-vser->bus->max_nr_ports = max_nr_ports;
-vser->ivqs = qemu_malloc(max_nr_ports * sizeof(VirtQueue *));
-vser->ovqs = qemu_malloc(max_nr_ports * sizeof(VirtQueue *));
+vser->bus->max_nr_ports = conf->max_virtserial_ports;
+vser->ivqs = qemu_malloc(conf->max_virtserial_ports * sizeof(VirtQueue *));
+vser->ovqs = qemu_malloc(conf->max_virtserial_ports * sizeof(VirtQueue *));
/* Add a queue for host to guest transfers for port 0 (backward compat) */
vser->ivqs[0] = virtio_add_queue(vdev, 128, handle_input);
@@ -866,8 +866,8 @@ VirtIODevice *virtio_serial_init(DeviceState *dev, uint32_t
max_nr_ports)
vser->ovqs[i] = virtio_add_queue(vdev, 128, handle_output);
}
-vser->config.max_nr_ports = max_nr_ports;
-vser->ports_map = qemu_mallocz(((max_nr_ports + 31) / 32)
+vser->config.max_nr_ports = conf->max_virtserial_ports;
+vser->ports_map = qemu_mallocz(((conf->max_virtserial_ports + 31) / 32)
* sizeof(vser->ports_map[0]));
/*
* Reserve location 0 for a console port for backward compat
diff --git a/hw/virtio-serial.h b/hw/virtio-serial.h
index 8cb9fbe..87cd7a1 100644
--- a/hw/virtio-serial.h
+++ b/hw/virtio-serial.h
@@ -45,6 +45,11 @@ struct virtio_console_control {
uint16_t value;/* Extra information for the key */
};
+struct virtio_serial_conf {
+/* Max. number of ports we can have for a the virtio-serial device */
+uint32_t max_virtserial_ports;
+};
[Qemu-devel] Fix build breakage to kvm on ppc
Recent changes to the generic kvm support code broke compile of kvm
for ppc. The patch below fixes the errors by adjusting types in the
ppc code, and adding a missing #ifdef.
Please apply.
Signed-off-by: David Gibson
---
kvm-all.c|2 ++
target-ppc/kvm.c |6 +++---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index e6a7de4..fb44e2e 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -998,7 +998,9 @@ int kvm_cpu_exec(CPUState *env)
}
ret = EXCP_INTERRUPT;
+#ifdef KVM_CAP_SET_GUEST_DEBUG
out:
+#endif /* KVM_CAP_SET_GUEST_DEBUG */
env->exit_request = 0;
cpu_single_env = NULL;
return ret;
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 04b94a3..4fa1be3 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -223,7 +223,7 @@ int kvmppc_set_interrupt(CPUState *env, int irq, int level)
#define PPC_INPUT_INT PPC6xx_INPUT_INT
#endif
-int kvm_arch_pre_run(CPUState *env, struct kvm_run *run)
+void kvm_arch_pre_run(CPUState *env, struct kvm_run *run)
{
int r;
unsigned irq;
@@ -254,15 +254,15 @@ int kvm_arch_pre_run(CPUState *env, struct kvm_run *run)
/* We don't know if there are more interrupts pending after this. However,
* the guest will return to userspace in the course of handling this one
* anyways, so we will get a chance to deliver the rest. */
-return 0;
}
void kvm_arch_post_run(CPUState *env, struct kvm_run *run)
{
}
-void kvm_arch_process_irqchip_events(CPUState *env)
+int kvm_arch_process_irqchip_events(CPUState *env)
{
+return 0;
}
static int kvmppc_handle_halt(CPUState *env)
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[Qemu-devel] Fix build errors introduced by vnc jpeg changes
The recent changes to handling of jpegs over tight vnc connections
cause build errors if qemu is configured with --disable-vnc-jpeg. The
patch below corrects the errors, by adding some left out #ifdefs.
Please apply.
Signed-off-by: David Gibson
---
ui/vnc-enc-tight.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/ui/vnc-enc-tight.c b/ui/vnc-enc-tight.c
index 5933394..2522936 100644
--- a/ui/vnc-enc-tight.c
+++ b/ui/vnc-enc-tight.c
@@ -1536,8 +1536,10 @@ static int send_sub_rect(VncState *vs, int x, int y, int
w, int h)
uint32_t bg = 0, fg = 0;
int colors;
int ret = 0;
+#ifdef CONFIG_VNC_JPEG
bool force_jpeg = false;
bool allow_jpeg = true;
+#endif
vnc_framebuffer_update(vs, x, y, w, h, vs->tight.type);
@@ -1711,6 +1713,7 @@ static int tight_send_framebuffer_update(VncState *vs,
int x, int y,
vs->tight.pixel24 = false;
}
+#ifdef CONFIG_VNC_JPEG
if (vs->tight.quality != (uint8_t)-1) {
double freq = vnc_update_freq(vs, x, y, w, h);
@@ -1718,6 +1721,7 @@ static int tight_send_framebuffer_update(VncState *vs,
int x, int y,
return send_rect_simple(vs, x, y, w, h, false);
}
}
+#endif
if (w * h < VNC_TIGHT_MIN_SPLIT_RECT_SIZE) {
return send_rect_simple(vs, x, y, w, h, true);
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[Qemu-devel] [PATCH v3 uq/master 11/22] always qemu_cpu_kick after unhalting a cpu
This ensures env->halt_cond is broadcast, and the loop in
qemu_tcg_wait_io_event and qemu_kvm_wait_io_event is exited
naturally rather than through a timeout.
Signed-off-by: Paolo Bonzini
---
hw/ppc.c |2 ++
hw/sun4m.c | 10 --
hw/sun4u.c |4 ++--
target-s390x/kvm.c |1 +
4 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/hw/ppc.c b/hw/ppc.c
index 968aec1..de02d33 100644
--- a/hw/ppc.c
+++ b/hw/ppc.c
@@ -208,6 +208,7 @@ static void ppc970_set_irq (void *opaque, int pin, int
level)
} else {
LOG_IRQ("%s: restart the CPU\n", __func__);
env->halted = 0;
+qemu_cpu_kick(env);
}
break;
case PPC970_INPUT_HRESET:
@@ -300,6 +301,7 @@ static void ppc40x_set_irq (void *opaque, int pin, int
level)
} else {
LOG_IRQ("%s: restart the CPU\n", __func__);
env->halted = 0;
+qemu_cpu_kick(env);
}
break;
case PPC40x_INPUT_DEBUG:
diff --git a/hw/sun4m.c b/hw/sun4m.c
index 30e8a21..df3aa32 100644
--- a/hw/sun4m.c
+++ b/hw/sun4m.c
@@ -253,15 +253,21 @@ void cpu_check_irqs(CPUState *env)
}
}
+static void cpu_kick_irq(CPUState *env)
+{
+env->halted = 0;
+cpu_check_irqs(env);
+qemu_cpu_kick(env);
+}
+
static void cpu_set_irq(void *opaque, int irq, int level)
{
CPUState *env = opaque;
if (level) {
trace_sun4m_cpu_set_irq_raise(irq);
-env->halted = 0;
env->pil_in |= 1 << irq;
-cpu_check_irqs(env);
+cpu_kick_irq(env);
} else {
trace_sun4m_cpu_set_irq_lower(irq);
env->pil_in &= ~(1 << irq);
diff --git a/hw/sun4u.c b/hw/sun4u.c
index 90b1ce2..d282324 100644
--- a/hw/sun4u.c
+++ b/hw/sun4u.c
@@ -298,6 +298,7 @@ static void cpu_kick_irq(CPUState *env)
{
env->halted = 0;
cpu_check_irqs(env);
+qemu_cpu_kick(env);
}
static void cpu_set_irq(void *opaque, int irq, int level)
@@ -306,9 +307,8 @@ static void cpu_set_irq(void *opaque, int irq, int level)
if (level) {
CPUIRQ_DPRINTF("Raise CPU IRQ %d\n", irq);
-env->halted = 0;
env->pil_in |= 1 << irq;
-cpu_check_irqs(env);
+cpu_kick_irq(env);
} else {
CPUIRQ_DPRINTF("Lower CPU IRQ %d\n", irq);
env->pil_in &= ~(1 << irq);
diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index b349812..6e94274 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -194,6 +194,7 @@ static void kvm_s390_interrupt_internal(CPUState *env, int
type, uint32_t parm,
env->halted = 0;
env->exception_index = -1;
+qemu_cpu_kick(env);
kvmint.type = type;
kvmint.parm = parm;
--
1.7.4
[Qemu-devel] [PATCH v3 uq/master 22/22] add Win32 IPI service
Signed-off-by: Paolo Bonzini
---
cpus.c | 25 ++---
qemu-thread-posix.c |9 -
qemu-thread-posix.h |1 -
3 files changed, 22 insertions(+), 13 deletions(-)
diff --git a/cpus.c b/cpus.c
index 7559a02..077729c 100644
--- a/cpus.c
+++ b/cpus.c
@@ -854,13 +854,32 @@ static void *qemu_tcg_cpu_thread_fn(void *arg)
return NULL;
}
+static void qemu_cpu_kick_thread(CPUState *env)
+{
+#ifndef _WIN32
+int err;
+
+err = pthread_kill(env->thread->thread, SIG_IPI);
+if (err) {
+fprintf(stderr, "qemu:%s: %s", __func__, strerror(err));
+exit(1);
+}
+#else /* _WIN32 */
+if (!qemu_cpu_is_self(env)) {
+SuspendThread(env->thread->thread);
+cpu_signal(0);
+ResumeThread(env->thread->thread);
+}
+#endif
+}
+
void qemu_cpu_kick(void *_env)
{
CPUState *env = _env;
qemu_cond_broadcast(env->halt_cond);
if (!env->thread_kicked) {
-qemu_thread_signal(env->thread, SIG_IPI);
+qemu_cpu_kick_thread(env);
env->thread_kicked = true;
}
}
@@ -871,7 +890,7 @@ void qemu_cpu_kick_self(void)
assert(cpu_single_env);
if (!cpu_single_env->thread_kicked) {
-qemu_thread_signal(cpu_single_env->thread, SIG_IPI);
+qemu_cpu_kick_thread(cpu_single_env);
cpu_single_env->thread_kicked = true;
}
#else
@@ -893,7 +912,7 @@ void qemu_mutex_lock_iothread(void)
} else {
qemu_mutex_lock(&qemu_fair_mutex);
if (qemu_mutex_trylock(&qemu_global_mutex)) {
-qemu_thread_signal(tcg_cpu_thread, SIG_IPI);
+qemu_cpu_kick_thread(first_cpu);
qemu_mutex_lock(&qemu_global_mutex);
}
qemu_mutex_unlock(&qemu_fair_mutex);
diff --git a/qemu-thread-posix.c b/qemu-thread-posix.c
index a4c6e25..9cceda7 100644
--- a/qemu-thread-posix.c
+++ b/qemu-thread-posix.c
@@ -186,15 +186,6 @@ void qemu_thread_create(QemuThread *thread,
pthread_sigmask(SIG_SETMASK, &oldset, NULL);
}
-void qemu_thread_signal(QemuThread *thread, int sig)
-{
-int err;
-
-err = pthread_kill(thread->thread, sig);
-if (err)
-error_exit(err, __func__);
-}
-
void qemu_thread_get_self(QemuThread *thread)
{
thread->thread = pthread_self();
diff --git a/qemu-thread-posix.h b/qemu-thread-posix.h
index 11978db..35e0a8b 100644
--- a/qemu-thread-posix.h
+++ b/qemu-thread-posix.h
@@ -15,5 +15,4 @@ struct QemuThread {
pthread_t thread;
};
-void qemu_thread_signal(QemuThread *thread, int sig);
#endif
--
1.7.4
[Qemu-devel] [PATCH v3 uq/master 01/22] unlock iothread during WaitForMultipleObjects
Signed-off-by: Paolo Bonzini
---
os-win32.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/os-win32.c b/os-win32.c
index b214e6a..c971d92 100644
--- a/os-win32.c
+++ b/os-win32.c
@@ -140,7 +140,9 @@ void os_host_main_loop_wait(int *timeout)
int err;
WaitObjects *w = &wait_objects;
+qemu_mutex_unlock_iothread();
ret = WaitForMultipleObjects(w->num, w->events, FALSE, *timeout);
+qemu_mutex_lock_iothread();
if (WAIT_OBJECT_0 + 0 <= ret && ret <= WAIT_OBJECT_0 + w->num - 1) {
if (w->func[ret - WAIT_OBJECT_0])
w->func[ret - WAIT_OBJECT_0](w->opaque[ret - WAIT_OBJECT_0]);
--
1.7.4
[Qemu-devel] [PATCH v3 uq/master 15/22] do not use timedwait on qemu_system_cond
qemu_main_loop_start is the only place where qemu_system_ready is set
to 1.
Signed-off-by: Paolo Bonzini
---
cpus.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/cpus.c b/cpus.c
index 4c3837f..e367b3b 100644
--- a/cpus.c
+++ b/cpus.c
@@ -823,7 +823,7 @@ static void *qemu_kvm_cpu_thread_fn(void *arg)
/* and wait for machine initialization */
while (!qemu_system_ready) {
-qemu_cond_timedwait(&qemu_system_cond, &qemu_global_mutex, 100);
+qemu_cond_wait(&qemu_system_cond, &qemu_global_mutex);
}
while (1) {
@@ -855,7 +855,7 @@ static void *qemu_tcg_cpu_thread_fn(void *arg)
/* and wait for machine initialization */
while (!qemu_system_ready) {
-qemu_cond_timedwait(&qemu_system_cond, &qemu_global_mutex, 100);
+qemu_cond_wait(&qemu_system_cond, &qemu_global_mutex);
}
while (1) {
--
1.7.4
