Re: [Qemu-devel] Release of COREMU, a scalable and portable full-system emulator
On 2010-7-21, at 上午5:43, Blue Swirl wrote: On Sat, Jul 17, 2010 at 10:27 AM, Chen Yufei cyfde...@gmail.com wrote: We are pleased to announce COREMU, which is a multicore-on-multicore full-system emulator built on Qemu. (Simply speaking, we made Qemu parallel.) The project web page is located at: http://ppi.fudan.edu.cn/coremu You can also download the source code, images for playing on sourceforge http://sf.net/p/coremu COREMU is composed of 1. a parallel emulation library 2. a set of patches to qemu (We worked on the master branch, commit 54d7cf136f040713095cbc064f62d753bff6f9d2) It currently supports full-system emulation of x64 and ARM MPcore platforms. By leveraging the underlying multicore resources, it can emulate up to 255 cores running commodity operating systems (even on a 4-core machine). Enjoy, Nice work. Do you plan to submit the improvements back to upstream QEMU? It would be great if we can submit our code to QEMU, but we do not know the process. Would you please give us some instructions? -- Best regards, Chen Yufei
[Qemu-devel] Re: Virtualization at Plumbers 2010 - Time to submit your proposals!
Hi, There has been some confusion around the format of the tracks at Linux Plumbers: Presentations vs Micro Conference, so the program committee has extended the deadline by one week. If you didn't get your submission in earlier, or you were confused, this is your final chance. Please see http://lwn.net/Articles/396629/ for details! My apologies for the spamming. Best regards, Jes
Re: [Qemu-devel] Question about qemu firmware configuration (fw_cfg) device
On 21.07.2010, at 00:22, Blue Swirl wrote: On Sat, Jul 17, 2010 at 9:50 AM, Richard W.M. Jones rjo...@redhat.com wrote: I'm trying to speed up the process of loading kernel and initrd. I found that the main loop which loads these into qemu memory does it via executing in the guest: rep insb (%dx),%es:(%edi) In other words, reading it byte-at-a-time from an emulated IO port. This is very slow[1] when your initrd is 100MB like mine is. Questions: Is fw_cfg a purely qemu concept? Does this BIOS firmware port 0x510-0x511 exist in real hardware? I understand from the git logs that fw_cfg was added because the old way was to load kernel initrd into RAM directly, but this didn't work because SeaBIOS would clear the RAM, clobbering kernel initrd. Could we change to loading these directly into RAM, and instead provide some indication to SeaBIOS so it doesn't clobber the RAM? I'm quite prepared to do the work, just wondering if there's something else I'm not getting about this. The entire discussion after this very first message seems to focus on the DMA method. But is it so hard to fix SeaBIOS from clobbering RAM? It was basically introduced to have a clean way of actually loading the blobs. This is a lot more flexible than trying to make sure every firmware out there doesn't accidently overwrite random ram regions. The conclusion on the phone call was basically to try and look into optimizing the general rep ins case for now. That should also benefit others and isn't tightly coupled with this exact problem. Alex
[Qemu-devel] [PATCH v3] Error on O_DIRECT for physical CDROM/DVD drives
From: Jes Sorensen jes.soren...@redhat.com
O_DIRECT (cache=none) requires sector alignment, however the physical
sector size of CDROM/DVD drives is 2048, as opposed to most disk
devices which use 512. QEMU is hard coding 512 all over the place, so
allowing O_DIRECT for CDROM/DVD devices does not work.
Return -ENOTSUP from cdrom_open() in this case.
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
block/raw-posix.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/block/raw-posix.c b/block/raw-posix.c
index 291699f..4b84770 100644
--- a/block/raw-posix.c
+++ b/block/raw-posix.c
@@ -1139,6 +1139,11 @@ static int cdrom_open(BlockDriverState *bs, const char
*filename, int flags)
BDRVRawState *s = bs-opaque;
s-type = FTYPE_CD;
+if (flags BDRV_O_NOCACHE) {
+fprintf(stderr, O_DIRECT (cache=none) for CDROM/DVD device (%s)
+is unsupported\n, filename);
+return -ENOTSUP;
+}
/* open will not fail even if no CD is inserted, so add O_NONBLOCK */
return raw_open_common(bs, filename, flags, O_NONBLOCK);
--
1.7.1.1
Re: [Qemu-devel] [PATCH] Error on O_DIRECT for physical CDROM/DVD drives
On 07/20/10 19:19, Markus Armbruster wrote: Jes Sorensen jes.soren...@redhat.com writes: On 07/20/10 18:35, David S. Ahern wrote: On 07/20/10 10:09, jes.soren...@redhat.com wrote: If a cdrom is added via the monitor this would abruptly terminate the VM - which is not good. True, but this would only happen if the user explicitly marks it cache=none which is not the default value for a new drive, so it would be a corner case. Why not return -ENOTSUP? Good point, just posted v3 of the patch that does this instead of exit() Jes
[Qemu-devel] virtio-9p is not working
Hi, I have trying to use the virtio-9p for my linux in QEMU, but without success. Here is my option for booting my qemu: i386-softmmu/qemu -kernel bzImage -append console=ttyS0 video=uvesafb:ywrap,overlay:rgb16,480x800...@60 root=/dev/nfs rw nfsroot=10.0.2.2:/root,udp ip=10.0.2.16:eth0:none 5 -net nic,model=virtio -net user -soundhw all -usb -serial telnet:localhost:1200,server -vga std -m 512 -L ./pc-bios -bios bios.bin -virtfs local,path=/home/dallas/nfs,security_model=passthrough,mount_tag=v_tmp The virtio network is working, I could mount the nfs through virio net. And in the guest linux, I tried to mount v9fs by using following command: mount -t 9p -o trans=virtio -o debug=0x v_tmp /mnt but unfortunately I got the error: mount: mounting v_tmp on /mnt failed: No such device And I can't find the v_tmp neither in /sys/devices/virtio-pci/virtio1/ nor in /sys/bus/virtio/drivers/9pnet_virtio/virtio1/ And before building the kernel, I enabled the Plan 9 Ressource Sharing Support under File System/Network File System, I also enabled the following configures: PARAVIRT_GUEST: - Processor type and features - Paravirtualized guest support LGUEST_GUEST: - Processor type and features - Paravirtualized guest support - Lguest guest support VIRTIO_PCI: - Virtualization (VIRTUALIZATION [=y]) - PCI driver for virtio devices VIRTIO_BLK: - Device Drivers - Block devices (BLK_DEV [=y]) - Virtio block driver VIRTIO_NET: - Device Drivers - Network device support (NETDEVICES [=y]) - Virtio network driver Would you please help me to find out the problem why I couldn't mount the v9fs? Thank you very much! BR, Dallas
[Qemu-devel] [Bug 608107] Re: ppc fails to clear MSR_POW when incurring exception
** Patch added: Suggested fix http://launchpadlibrarian.net/52250654/ppc-msr_pow-clear.diff -- ppc fails to clear MSR_POW when incurring exception https://bugs.launchpad.net/bugs/608107 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: QEMU VERSION: 0.12.4 According to FreeScale's 'Programming Environments Manual for 32-bit Implementations of the PowerPC Architecture' [MPCFPE32B, Rev.3, 9/2005], section 6.5, table 6-7, an interrupt resets MSR_POW to zero but qemu-0.12.4 fails to do so. Resetting the bit is necessary in order to bring the processor out of power-management since otherwise it goes to sleep right away in the exception handler, i.e., it is impossible to leave PM-mode.
[Qemu-devel] [Bug 608107] [NEW] ppc fails to clear MSR_POW when incurring exception
Public bug reported: QEMU VERSION: 0.12.4 According to FreeScale's 'Programming Environments Manual for 32-bit Implementations of the PowerPC Architecture' [MPCFPE32B, Rev.3, 9/2005], section 6.5, table 6-7, an interrupt resets MSR_POW to zero but qemu-0.12.4 fails to do so. Resetting the bit is necessary in order to bring the processor out of power-management since otherwise it goes to sleep right away in the exception handler, i.e., it is impossible to leave PM-mode. ** Affects: qemu Importance: Undecided Status: New -- ppc fails to clear MSR_POW when incurring exception https://bugs.launchpad.net/bugs/608107 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: QEMU VERSION: 0.12.4 According to FreeScale's 'Programming Environments Manual for 32-bit Implementations of the PowerPC Architecture' [MPCFPE32B, Rev.3, 9/2005], section 6.5, table 6-7, an interrupt resets MSR_POW to zero but qemu-0.12.4 fails to do so. Resetting the bit is necessary in order to bring the processor out of power-management since otherwise it goes to sleep right away in the exception handler, i.e., it is impossible to leave PM-mode.
Re: [Qemu-devel] [PATCH v3] Error on O_DIRECT for physical CDROM/DVD drives
jes.soren...@redhat.com writes: From: Jes Sorensen jes.soren...@redhat.com O_DIRECT (cache=none) requires sector alignment, however the physical sector size of CDROM/DVD drives is 2048, as opposed to most disk devices which use 512. QEMU is hard coding 512 all over the place, so allowing O_DIRECT for CDROM/DVD devices does not work. Return -ENOTSUP from cdrom_open() in this case. Good short-term fix.
[Qemu-devel] [PATCH] virtio-serial: Check if more max_ports specified than we can handle
Currently virtio-serial supports a maximum of 31 ports. Specifying the
'max_ports' parameter to be 31 on the cmd line causes badness.
Ensure we initialise virtio-serial only if max_ports is within the
supported range.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-serial-bus.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index 8e611c0..0586b89 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -734,11 +734,19 @@ VirtIODevice *virtio_serial_init(DeviceState *dev,
uint32_t max_nr_ports)
{
VirtIOSerial *vser;
VirtIODevice *vdev;
-uint32_t i;
+uint32_t i, max_supported_ports;
if (!max_nr_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) {
+error_report(maximum ports supported: %u, max_supported_ports);
+return NULL;
+}
+
vdev = virtio_common_init(virtio-serial, VIRTIO_ID_CONSOLE,
sizeof(struct virtio_console_config),
sizeof(VirtIOSerial));
--
1.7.1.1
[Qemu-devel] Unknown command 0xffffff in SVGA command FIFO
Hi! I'm trying to run a Linux guest on top of QEMU (kvm). The only VGA emulation that seems to give any kind of usable performance is the vmware SVGA adapter, but that in turn is very unstable. It usually freezes the guest display within a minute or two and starts printing an error like vmsvga_fifo_run: Unknown command 0xff in SVGA command FIFO. A bit of googling tells that I'm not the only one with this problem (1). Now, correct me if I'm wrong, but isn't vmsvga_fifo_run() called from an asynchronous context (wrt the guest)? If that indeed is so, it may very well be, that it is run while the guest is modifying the FIFO. This means, that a command may found in the FIFO, but its arguments may not be there yet. AFAICT the code just seems to check that the FIFO is not empty before reading the command, but then assumes that the rest of the command arguments are also there and reads the FIFO without further checks. If it is possible that part of the command is missing, this will desynchronize the FIFO. As there seems to be no mechanism for re-syncing it, we're toast. Also, if the FIFO gets full, the guest will force the FIFO to be run. Now, AFAICT there is no guarantee on the guest side that the last command in the FIFO won't be incomplete when this happens. This will desynchronize the FIFO the same way and can happen even if all the calls to vmsvga_fifo_run() are synchronized. It seems to me that the FIFO handling probably needs some way to peek into the FIFO to see if the command in there is complete and delay executing it if parts of it are still missing. That should work in all cases except if a single command can be so big that it won't fit in the FIFO. The other alternative I can think of is to implement the vmsvga_fifo_run() as a state machine that can read a partial command from the FIFO and continue it on the next call. Finally, if it indeed is true that the FIFO can be run both asynchronously and forced by the guest, shouldn't the access to the FIFO also be protected between these two somehow? At least I couldn't find any such mechanism, but I must admit that I may have easily just missed it. (1): https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/595427
Re: [Qemu-devel] Unknown command 0xffffff in SVGA command FIFO
Hi, On 21 July 2010 13:17, Janne Huttunen jahut...@gmail.com wrote: Now, correct me if I'm wrong, but isn't vmsvga_fifo_run() called from an asynchronous context (wrt the guest)? If that indeed is so, it may very well be, that it is run while the guest is modifying the FIFO. This means, that a command may found in the FIFO, but its arguments may not be there yet. No, I think that can't happen, but it would be interesting to bisect what the guest is doing exactly when this happens. The guest should not move the next command pointer before if has written the command entirely, this should be enough to guard against executing a partial command. Unless there's another timing issue somewhere obviously. Can you check whether this also happens without kvm? AFAICT the code just seems to check that the FIFO is not empty before reading the command, but then assumes that the rest of the command arguments are also there and reads the FIFO without further checks. If it is possible that part of the command is missing, this will desynchronize the FIFO. As there seems to be no mechanism for re-syncing it, we're toast. Also, if the FIFO gets full, the guest will force the FIFO to be run. Now, AFAICT there is no guarantee on the guest side that the last command in the FIFO won't be incomplete when this happens. This will desynchronize the FIFO the same way and can happen even if all the calls to vmsvga_fifo_run() are synchronized. Hmm, I don't know about the guest.. would be good to check too, but it should be only fixable in the guest if it is so. I'm not sure if it's likely that the FIFO is really getting full? Most guest software will not write too many commands without knowing that the previous content has appeared on the screen, right? It seems to me that the FIFO handling probably needs some way to peek into the FIFO to see if the command in there is complete and delay executing it if parts of it are still missing. That should work in all cases except if a single command can be so big that it won't fit in the FIFO. The other alternative I can think of is to implement the vmsvga_fifo_run() as a state machine that can read a partial command from the FIFO and continue it on the next call. Finally, if it indeed is true that the FIFO can be run both asynchronously and forced by the guest, shouldn't the access to the FIFO also be protected between these two somehow? At least I couldn't find any such mechanism, but I must admit that I may have easily just missed it. The FIFO can run at any moment but everything else stops until all the commands currently in the FIFO have been executed. vmware_fifo_run is called by the UI update which in turn is called from the main select() loop. Guest code is also executed in that loop. Cheers
Re: [Qemu-devel] Unknown command 0xffffff in SVGA command FIFO
No, I think that can't happen, but it would be interesting to bisect what the guest is doing exactly when this happens. The guest should not move the next command pointer before if has written the command entirely, this should be enough to guard against executing a partial command. Unless there's another timing issue somewhere obviously. Well, the guest driver is essentially the one in X.Org git tree here: http://cgit.freedesktop.org/xorg/driver/xf86-video-vmware/tree/src Looking at e.g. vmwareSendSVGACmdUpdate and vmwareWriteWordToFIFO in vmware.c, the command seems to be inserted into the FIFO one value at a time. Now, is the whole sequence somehow atomic wrt the host FIFO access or not? Hmm, I don't know about the guest.. would be good to check too, but it should be only fixable in the guest if it is so. Is the FIFO protocol documented somewhere? Like what kind of atomicity is expected? I'm not sure if it's likely that the FIFO is really getting full? Most guest software will not write too many commands without knowing that the previous content has appeared on the screen, right? Yes, I agree. That's more of a theoretical issue. The FIFO can run at any moment but everything else stops until all the commands currently in the FIFO have been executed. vmware_fifo_run is called by the UI update which in turn is called from the main select() loop. Guest code is also executed in that loop. At any time as in between guest calls to vmwareWriteWordToFIFO? Or not? It seems to me that the GUI is updated from a timer, but can it go off at any time?
Re: [Qemu-devel] Unknown command 0xffffff in SVGA command FIFO
On 21 July 2010 14:14, Janne Huttunen jahut...@gmail.com wrote: No, I think that can't happen, but it would be interesting to bisect what the guest is doing exactly when this happens. The guest should not move the next command pointer before if has written the command entirely, this should be enough to guard against executing a partial command. Unless there's another timing issue somewhere obviously. Well, the guest driver is essentially the one in X.Org git tree here: http://cgit.freedesktop.org/xorg/driver/xf86-video-vmware/tree/src Looking at e.g. vmwareSendSVGACmdUpdate and vmwareWriteWordToFIFO in vmware.c, the command seems to be inserted into the FIFO one value at a time. Now, is the whole sequence somehow atomic wrt the host FIFO access or not? Hmm, okay, I had expected the driver to not update NEXT_CMD until it's done with writing the current command, but it does update after every word. I'd say this is wrong, but we probably need to handle it in qemu. The sequence is not atomic, although with TCG it may turn out to be atomic depending on how the code was compiled and where the page boundary is... there are only RAM accesses so they shouldn't cause a vmexit. No idea about KVM. Hmm, I don't know about the guest.. would be good to check too, but it should be only fixable in the guest if it is so. Is the FIFO protocol documented somewhere? Like what kind of atomicity is expected? Not that I know. At any time as in between guest calls to vmwareWriteWordToFIFO? Or not? It seems to me that the GUI is updated from a timer, but can it go off at any time? The timers are also updated from the select loop.. but in theory yes, it can go off in between the WriteWordToFIFO calls and we need to take that into account. I see no way to tell whether the guest is currently in the middle of writing a command. So it seems the only way to check is to peek the first word in the fifo (which *is* written entirely before a NEXT_CMD update) and look up the expected command length, and then check whether enough data is in the FIFO. Do you want to implement this? Cheers
[Qemu-devel] Adding new hardware emulation
Hello, I am looking for documentation on adding new hardware support, I would like to emulate an SH7724 processors, is there any kind of documentation on adding support in qemu for new hardware?.. thank in advanced and best regards!.
Re: [Qemu-devel] [PATCH v3] Error on O_DIRECT for physical CDROM/DVD drives
On Wed, Jul 21, 2010 at 09:45:19AM +0200, jes.soren...@redhat.com wrote: From: Jes Sorensen jes.soren...@redhat.com O_DIRECT (cache=none) requires sector alignment, however the physical sector size of CDROM/DVD drives is 2048, as opposed to most disk devices which use 512. QEMU is hard coding 512 all over the place, so allowing O_DIRECT for CDROM/DVD devices does not work. Return -ENOTSUP from cdrom_open() in this case. The patch is not quite correct. There are CDROMs with 512 byte sectors, just as there are disks with larger sector sizes. And of course these limitations also apply when running ontop of filesystems. So we really need to handle these things better and need to query the sector size of the device and handle it properly.
[Qemu-devel] Move the xenfb pointer handler to the connected method
From: John Haxby john.ha...@oracle.com
Move the xenfb pointer handler to the connected method
Ensure that we read request-abs-pointer after the frontend has written
it. This means that we will correctly set up an ansolute or relative
pointer handler correctly.
Signed-off-by: John Haxby john.ha...@oracle.com
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
diff --git a/hw/xenfb.c b/hw/xenfb.c
index b535d8c..72e5277 100644
--- a/hw/xenfb.c
+++ b/hw/xenfb.c
@@ -364,19 +364,27 @@ static int input_initialise(struct XenDevice *xendev)
struct XenInput *in = container_of(xendev, struct XenInput, c.xendev);
int rc;
-if (xenstore_read_fe_int(xendev, request-abs-pointer,
- in-abs_pointer_wanted) == -1)
- in-abs_pointer_wanted = 0;
-
rc = common_bind(in-c);
if (rc != 0)
return rc;
qemu_add_kbd_event_handler(xenfb_key_event, in);
+return 0;
+}
+
+static void input_connected(struct XenDevice *xendev)
+{
+struct XenInput *in = container_of(xendev, struct XenInput, c.xendev);
+
+if (xenstore_read_fe_int(xendev, request-abs-pointer,
+ in-abs_pointer_wanted) == -1)
+ in-abs_pointer_wanted = 0;
+
+if (in-qmouse)
+ qemu_remove_mouse_event_handler(in-qmouse);
in-qmouse = qemu_add_mouse_event_handler(xenfb_mouse_event, in,
in-abs_pointer_wanted,
Xen PVFB Mouse);
-return 0;
}
static void input_disconnect(struct XenDevice *xendev)
@@ -956,6 +964,7 @@ struct XenDevOps xen_kbdmouse_ops = {
.size = sizeof(struct XenInput),
.init = input_init,
.initialise = input_initialise,
+.connected = input_connected,
.disconnect = input_disconnect,
.event = input_event,
};
[Qemu-devel] Introduce a new 'connected' xendev op called when Connected.
From: John Haxby john.ha...@oracle.com
Introduce a new 'connected' xendev op called when Connected.
Rename the existing xendev 'connect' op to 'initialised' and introduce
a new 'connected' op. This new op, if defined, is called when the
backend is connected. Note that since there is no state transition this
may be called more than once.
Signed-off-by: John Haxby john.ha...@oracle.com
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
diff --git a/hw/xen_backend.c b/hw/xen_backend.c
index a2e408f..b99055a 100644
--- a/hw/xen_backend.c
+++ b/hw/xen_backend.c
@@ -400,13 +400,13 @@ static int xen_be_try_init(struct XenDevice *xendev)
}
/*
- * Try to connect xendev. Depends on the frontend being ready
+ * Try to initialise xendev. Depends on the frontend being ready
* for it (shared ring and evtchn info in xenstore, state being
* Initialised or Connected).
*
* Goes to Connected on success.
*/
-static int xen_be_try_connect(struct XenDevice *xendev)
+static int xen_be_try_initialise(struct XenDevice *xendev)
{
int rc = 0;
@@ -420,10 +420,10 @@ static int xen_be_try_connect(struct XenDevice *xendev)
}
}
-if (xendev-ops-connect)
- rc = xendev-ops-connect(xendev);
+if (xendev-ops-initialise)
+ rc = xendev-ops-initialise(xendev);
if (rc != 0) {
- xen_be_printf(xendev, 0, connect() failed\n);
+ xen_be_printf(xendev, 0, initialise() failed\n);
return rc;
}
@@ -432,6 +432,28 @@ static int xen_be_try_connect(struct XenDevice *xendev)
}
/*
+ * Try to let xendev know that it is connected. Depends on the
+ * frontend being Connected. Note that this may be called more
+ * than once since the backend state is not modified.
+ */
+static void xen_be_try_connected(struct XenDevice *xendev)
+{
+if (!xendev-ops-connected)
+ return;
+
+if (xendev-fe_state != XenbusStateConnected) {
+ if (xendev-ops-flags DEVOPS_FLAG_IGNORE_STATE) {
+ xen_be_printf(xendev, 2, frontend not ready, ignoring\n);
+ } else {
+ xen_be_printf(xendev, 2, frontend not ready (yet)\n);
+ return;
+ }
+}
+
+xendev-ops-connected(xendev);
+}
+
+/*
* Teardown connection.
*
* Goes to Closed when done.
@@ -483,7 +505,12 @@ void xen_be_check_state(struct XenDevice *xendev)
rc = xen_be_try_init(xendev);
break;
case XenbusStateInitWait:
- rc = xen_be_try_connect(xendev);
+ rc = xen_be_try_initialise(xendev);
+ break;
+ case XenbusStateConnected:
+ /* xendev-be_state doesn't change */
+ xen_be_try_connected(xendev);
+ rc = -1;
break;
case XenbusStateClosed:
rc = xen_be_try_reset(xendev);
diff --git a/hw/xen_backend.h b/hw/xen_backend.h
index cc25f9d..154922a 100644
--- a/hw/xen_backend.h
+++ b/hw/xen_backend.h
@@ -23,7 +23,8 @@ struct XenDevOps {
uint32_t flags;
void (*alloc)(struct XenDevice *xendev);
int (*init)(struct XenDevice *xendev);
-int (*connect)(struct XenDevice *xendev);
+int (*initialise)(struct XenDevice *xendev);
+void (*connected)(struct XenDevice *xendev);
void (*event)(struct XenDevice *xendev);
void (*disconnect)(struct XenDevice *xendev);
int (*free)(struct XenDevice *xendev);
diff --git a/hw/xen_console.c b/hw/xen_console.c
index d2261f4..258c003 100644
--- a/hw/xen_console.c
+++ b/hw/xen_console.c
@@ -202,7 +202,7 @@ static int con_init(struct XenDevice *xendev)
return 0;
}
-static int con_connect(struct XenDevice *xendev)
+static int con_initialise(struct XenDevice *xendev)
{
struct XenConsole *con = container_of(xendev, struct XenConsole, xendev);
int limit;
@@ -263,7 +263,7 @@ struct XenDevOps xen_console_ops = {
.size = sizeof(struct XenConsole),
.flags = DEVOPS_FLAG_IGNORE_STATE,
.init = con_init,
-.connect= con_connect,
+.initialise = con_initialise,
.event = con_event,
.disconnect = con_disconnect,
};
diff --git a/hw/xenfb.c b/hw/xenfb.c
index da5297b..b535d8c 100644
--- a/hw/xenfb.c
+++ b/hw/xenfb.c
@@ -359,7 +359,7 @@ static int input_init(struct XenDevice *xendev)
return 0;
}
-static int input_connect(struct XenDevice *xendev)
+static int input_initialise(struct XenDevice *xendev)
{
struct XenInput *in = container_of(xendev, struct XenInput, c.xendev);
int rc;
@@ -861,7 +861,7 @@ static int fb_init(struct XenDevice *xendev)
return 0;
}
-static int fb_connect(struct XenDevice *xendev)
+static int fb_initialise(struct XenDevice *xendev)
{
struct XenFB *fb = container_of(xendev, struct XenFB, c.xendev);
struct xenfb_page *fb_page;
@@ -955,7 +955,7 @@ static void fb_event(struct XenDevice *xendev)
struct XenDevOps xen_kbdmouse_ops = {
.size = sizeof(struct XenInput),
.init = input_init,
-
Re: [Qemu-devel] [PATCH] virtio-blk: Create exit function to unregister savevm
Am 20.07.2010 19:14, schrieb Alex Williamson: Otherwise we can't migrate after we've removed a virtio block device. Signed-off-by: Alex Williamson alex.william...@redhat.com Thanks, applied to the block branch. Kevin
Re: [Qemu-devel] [PATCH v3] Error on O_DIRECT for physical CDROM/DVD drives
Christoph Hellwig h...@lst.de writes: On Wed, Jul 21, 2010 at 09:45:19AM +0200, jes.soren...@redhat.com wrote: From: Jes Sorensen jes.soren...@redhat.com O_DIRECT (cache=none) requires sector alignment, however the physical sector size of CDROM/DVD drives is 2048, as opposed to most disk devices which use 512. QEMU is hard coding 512 all over the place, so allowing O_DIRECT for CDROM/DVD devices does not work. Return -ENOTSUP from cdrom_open() in this case. The patch is not quite correct. There are CDROMs with 512 byte sectors, just as there are disks with larger sector sizes. And of course these limitations also apply when running ontop of filesystems. So we really need to handle these things better and need to query the sector size of the device and handle it properly. Agreed, but I figure Jes's fix is the best we can do for .13, and worth doing for .13.
Re: [Qemu-devel] [PATCH v3] Error on O_DIRECT for physical CDROM/DVD drives
On Wed, Jul 21, 2010 at 04:13:10PM +0200, Markus Armbruster wrote: Agreed, but I figure Jes's fix is the best we can do for .13, and worth doing for .13. As said in the previous mail it's incorrect in many ways. If at all you could reject devices and files on filesysystems on device with sector size 512 bytes. But once that infrastructure is there fixing it for real should be rather trivial. I'm looking into it now.
[Qemu-devel] [PATCH] savevm: Fix memory leak of compat struct
Forgot to check for and free these.
Found-by: Zachary Amsden zams...@redhat.com
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
0.13 Candidate
savevm.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/savevm.c b/savevm.c
index ee27989..1612794 100644
--- a/savevm.c
+++ b/savevm.c
@@ -1126,6 +1126,9 @@ void unregister_savevm(DeviceState *dev, const char
*idstr, void *opaque)
QTAILQ_FOREACH_SAFE(se, savevm_handlers, entry, new_se) {
if (strcmp(se-idstr, id) == 0 se-opaque == opaque) {
QTAILQ_REMOVE(savevm_handlers, se, entry);
+if (se-compat) {
+qemu_free(se-compat);
+}
qemu_free(se);
}
}
@@ -1193,6 +1196,9 @@ void vmstate_unregister(DeviceState *dev, const
VMStateDescription *vmsd,
QTAILQ_FOREACH_SAFE(se, savevm_handlers, entry, new_se) {
if (se-vmsd == vmsd se-opaque == opaque) {
QTAILQ_REMOVE(savevm_handlers, se, entry);
+if (se-compat) {
+qemu_free(se-compat);
+}
qemu_free(se);
}
}
Re: [Qemu-devel] Unknown command 0xffffff in SVGA command FIFO
I see no way to tell whether the guest is currently in the middle of
writing a command. So it seems the only way to check is to peek the
first word in the fifo (which *is* written entirely before a NEXT_CMD
update) and look up the expected command length, and then check
whether enough data is in the FIFO. Do you want to implement this?
It's not quite that simple. There are a bunch of command where
amount of arguments depends on other arguments.
Here's an experiment for sanity checking the lengths and leaving
the command in the FIFO if it is not complete. It fixes the
problem for me (running it right now), but I agree that it's not
very elegant to look at :-/ .
diff --git a/hw/vmware_vga.c b/hw/vmware_vga.c
index 12bff48..7730ae0 100644
--- a/hw/vmware_vga.c
+++ b/hw/vmware_vga.c
@@ -526,6 +526,17 @@ static inline int vmsvga_fifo_empty(struct vmsvga_state_s
*s)
return (s-cmd-next_cmd == s-cmd-stop);
}
+static inline int vmsvga_fifo_items(struct vmsvga_state_s *s)
+{
+int num;
+if (!s-config || !s-enable)
+return 0;
+num = CMD(next_cmd) - CMD(stop);
+if (num 0)
+num += (CMD(max) - CMD(min));
+return (num 2);
+}
+
static inline uint32_t vmsvga_fifo_read_raw(struct vmsvga_state_s *s)
{
uint32_t cmd = s-fifo[CMD(stop) 2];
@@ -540,6 +551,14 @@ static inline uint32_t vmsvga_fifo_read(struct
vmsvga_state_s *s)
return le32_to_cpu(vmsvga_fifo_read_raw(s));
}
+static inline uint32_t vmsvga_fifo_peek(struct vmsvga_state_s *s, uint32_t
offs)
+{
+offs = (offs 2) + CMD(stop);
+if (offs = CMD(max))
+offs = offs - CMD(max) + CMD(min);
+return le32_to_cpu(s-fifo[offs 2]);
+}
+
static void vmsvga_fifo_run(struct vmsvga_state_s *s)
{
uint32_t cmd, colour;
@@ -547,9 +566,12 @@ static void vmsvga_fifo_run(struct vmsvga_state_s *s)
int x, y, dx, dy, width, height;
struct vmsvga_cursor_definition_s cursor;
while (!vmsvga_fifo_empty(s))
-switch (cmd = vmsvga_fifo_read(s)) {
+switch (cmd = vmsvga_fifo_peek(s, 0)) {
case SVGA_CMD_UPDATE:
case SVGA_CMD_UPDATE_VERBOSE:
+if (vmsvga_fifo_items(s) 5)
+break;
+vmsvga_fifo_read(s);
x = vmsvga_fifo_read(s);
y = vmsvga_fifo_read(s);
width = vmsvga_fifo_read(s);
@@ -558,6 +580,9 @@ static void vmsvga_fifo_run(struct vmsvga_state_s *s)
break;
case SVGA_CMD_RECT_FILL:
+if (vmsvga_fifo_items(s) 6)
+break;
+vmsvga_fifo_read(s);
colour = vmsvga_fifo_read(s);
x = vmsvga_fifo_read(s);
y = vmsvga_fifo_read(s);
@@ -571,6 +596,9 @@ static void vmsvga_fifo_run(struct vmsvga_state_s *s)
#endif
case SVGA_CMD_RECT_COPY:
+if (vmsvga_fifo_items(s) 7)
+break;
+vmsvga_fifo_read(s);
x = vmsvga_fifo_read(s);
y = vmsvga_fifo_read(s);
dx = vmsvga_fifo_read(s);
@@ -585,13 +613,20 @@ static void vmsvga_fifo_run(struct vmsvga_state_s *s)
#endif
case SVGA_CMD_DEFINE_CURSOR:
-cursor.id = vmsvga_fifo_read(s);
-cursor.hot_x = vmsvga_fifo_read(s);
-cursor.hot_y = vmsvga_fifo_read(s);
-cursor.width = x = vmsvga_fifo_read(s);
-cursor.height = y = vmsvga_fifo_read(s);
-vmsvga_fifo_read(s);
-cursor.bpp = vmsvga_fifo_read(s);
+if (vmsvga_fifo_items(s) 8)
+break;
+cursor.id = vmsvga_fifo_peek(s, 1);
+cursor.hot_x = vmsvga_fifo_peek(s, 2);
+cursor.hot_y = vmsvga_fifo_peek(s, 3);
+cursor.width = x = vmsvga_fifo_peek(s, 4);
+cursor.height = y = vmsvga_fifo_peek(s, 5);
+cursor.bpp = vmsvga_fifo_peek(s, 7);
+
+if (vmsvga_fifo_items(s) SVGA_BITMAP_SIZE(x, y) +
SVGA_PIXMAP_SIZE(x, y, cursor.bpp) + 8)
+break;
+
+for (args = 0; args 8; args++)
+vmsvga_fifo_read(s);
if (SVGA_BITMAP_SIZE(x, y) sizeof cursor.mask ||
SVGA_PIXMAP_SIZE(x, y, cursor.bpp) sizeof cursor.image) {
@@ -616,25 +651,43 @@ static void vmsvga_fifo_run(struct vmsvga_state_s *s)
* for so we can avoid FIFO desync if driver uses them illegally.
*/
case SVGA_CMD_DEFINE_ALPHA_CURSOR:
-vmsvga_fifo_read(s);
-vmsvga_fifo_read(s);
-vmsvga_fifo_read(s);
-x = vmsvga_fifo_read(s);
-y = vmsvga_fifo_read(s);
+if (vmsvga_fifo_items(s) 6)
+break;
+x = vmsvga_fifo_peek(s, 4);
+y = vmsvga_fifo_peek(s, 5);
+if (vmsvga_fifo_items(s) x * y + 6)
+break;
+for (args = 0; args 6; args++)
+vmsvga_fifo_read(s);
args = x * y;
goto badcmd;
case SVGA_CMD_RECT_ROP_FILL:
Re: [Qemu-devel] Unknown command 0xffffff in SVGA command FIFO
Here's an experiment for sanity checking the lengths and leaving
the command in the FIFO if it is not complete. It fixes the
problem for me (running it right now), but I agree that it's not
very elegant to look at :-/ .
And here's another version with couple of stupid bugs removed
(it obviously is not a good idea to busyloop if the command is
incomplete).
diff --git a/hw/vmware_vga.c b/hw/vmware_vga.c
index 12bff48..839f715 100644
--- a/hw/vmware_vga.c
+++ b/hw/vmware_vga.c
@@ -526,6 +526,17 @@ static inline int vmsvga_fifo_empty(struct vmsvga_state_s
*s)
return (s-cmd-next_cmd == s-cmd-stop);
}
+static inline int vmsvga_fifo_items(struct vmsvga_state_s *s)
+{
+int num;
+if (!s-config || !s-enable)
+return 0;
+num = CMD(next_cmd) - CMD(stop);
+if (num 0)
+num += (CMD(max) - CMD(min));
+return (num 2);
+}
+
static inline uint32_t vmsvga_fifo_read_raw(struct vmsvga_state_s *s)
{
uint32_t cmd = s-fifo[CMD(stop) 2];
@@ -540,6 +551,14 @@ static inline uint32_t vmsvga_fifo_read(struct
vmsvga_state_s *s)
return le32_to_cpu(vmsvga_fifo_read_raw(s));
}
+static inline uint32_t vmsvga_fifo_peek(struct vmsvga_state_s *s, uint32_t
offs)
+{
+offs = (offs 2) + CMD(stop);
+if (offs = CMD(max))
+offs = offs - CMD(max) + CMD(min);
+return le32_to_cpu(s-fifo[offs 2]);
+}
+
static void vmsvga_fifo_run(struct vmsvga_state_s *s)
{
uint32_t cmd, colour;
@@ -547,9 +566,12 @@ static void vmsvga_fifo_run(struct vmsvga_state_s *s)
int x, y, dx, dy, width, height;
struct vmsvga_cursor_definition_s cursor;
while (!vmsvga_fifo_empty(s))
-switch (cmd = vmsvga_fifo_read(s)) {
+switch (cmd = vmsvga_fifo_peek(s, 0)) {
case SVGA_CMD_UPDATE:
case SVGA_CMD_UPDATE_VERBOSE:
+if (vmsvga_fifo_items(s) 5)
+goto out;
+vmsvga_fifo_read(s);
x = vmsvga_fifo_read(s);
y = vmsvga_fifo_read(s);
width = vmsvga_fifo_read(s);
@@ -558,6 +580,9 @@ static void vmsvga_fifo_run(struct vmsvga_state_s *s)
break;
case SVGA_CMD_RECT_FILL:
+if (vmsvga_fifo_items(s) 6)
+goto out;
+vmsvga_fifo_read(s);
colour = vmsvga_fifo_read(s);
x = vmsvga_fifo_read(s);
y = vmsvga_fifo_read(s);
@@ -571,6 +596,9 @@ static void vmsvga_fifo_run(struct vmsvga_state_s *s)
#endif
case SVGA_CMD_RECT_COPY:
+if (vmsvga_fifo_items(s) 7)
+goto out;
+vmsvga_fifo_read(s);
x = vmsvga_fifo_read(s);
y = vmsvga_fifo_read(s);
dx = vmsvga_fifo_read(s);
@@ -585,13 +613,20 @@ static void vmsvga_fifo_run(struct vmsvga_state_s *s)
#endif
case SVGA_CMD_DEFINE_CURSOR:
-cursor.id = vmsvga_fifo_read(s);
-cursor.hot_x = vmsvga_fifo_read(s);
-cursor.hot_y = vmsvga_fifo_read(s);
-cursor.width = x = vmsvga_fifo_read(s);
-cursor.height = y = vmsvga_fifo_read(s);
-vmsvga_fifo_read(s);
-cursor.bpp = vmsvga_fifo_read(s);
+if (vmsvga_fifo_items(s) 8)
+goto out;
+cursor.id = vmsvga_fifo_peek(s, 1);
+cursor.hot_x = vmsvga_fifo_peek(s, 2);
+cursor.hot_y = vmsvga_fifo_peek(s, 3);
+cursor.width = x = vmsvga_fifo_peek(s, 4);
+cursor.height = y = vmsvga_fifo_peek(s, 5);
+cursor.bpp = vmsvga_fifo_peek(s, 7);
+
+if (vmsvga_fifo_items(s) SVGA_BITMAP_SIZE(x, y) +
SVGA_PIXMAP_SIZE(x, y, cursor.bpp) + 8)
+goto out;
+
+for (args = 0; args 8; args++)
+vmsvga_fifo_read(s);
if (SVGA_BITMAP_SIZE(x, y) sizeof cursor.mask ||
SVGA_PIXMAP_SIZE(x, y, cursor.bpp) sizeof cursor.image) {
@@ -616,25 +651,43 @@ static void vmsvga_fifo_run(struct vmsvga_state_s *s)
* for so we can avoid FIFO desync if driver uses them illegally.
*/
case SVGA_CMD_DEFINE_ALPHA_CURSOR:
-vmsvga_fifo_read(s);
-vmsvga_fifo_read(s);
-vmsvga_fifo_read(s);
-x = vmsvga_fifo_read(s);
-y = vmsvga_fifo_read(s);
+if (vmsvga_fifo_items(s) 6)
+goto out;
+x = vmsvga_fifo_peek(s, 4);
+y = vmsvga_fifo_peek(s, 5);
+if (vmsvga_fifo_items(s) x * y + 6)
+goto out;
+for (args = 0; args 6; args++)
+vmsvga_fifo_read(s);
args = x * y;
goto badcmd;
case SVGA_CMD_RECT_ROP_FILL:
+if (vmsvga_fifo_items(s) 7)
+goto out;
+vmsvga_fifo_read(s);
args = 6;
goto badcmd;
case SVGA_CMD_RECT_ROP_COPY:
+if (vmsvga_fifo_items(s) 8)
+goto out;
+vmsvga_fifo_read(s);
[Qemu-devel] [PATCH-V2 02/24] qemu: virtio-9p: Implement statfs support in server
From: M. Mohan Kumar mo...@in.ibm.com
Implement statfs support in qemu server based on Sripathi's
initial statfs patch.
Signed-off-by: M. Mohan Kumar mo...@in.ibm.com
Signed-off-by: Sripathi Kodi sripat...@in.ibm.com
Signed-off-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
---
hw/file-op-9p.h |1 +
hw/virtio-9p-local.c |6
hw/virtio-9p.c | 63 ++
hw/virtio-9p.h | 24 +++
4 files changed, 94 insertions(+), 0 deletions(-)
diff --git a/hw/file-op-9p.h b/hw/file-op-9p.h
index a741c93..dd82ac7 100644
--- a/hw/file-op-9p.h
+++ b/hw/file-op-9p.h
@@ -74,6 +74,7 @@ typedef struct FileOperations
int (*rename)(FsContext *, const char *, const char *);
int (*truncate)(FsContext *, const char *, off_t);
int (*fsync)(FsContext *, int);
+int (*statfs)(FsContext *s, const char *path, struct statfs *stbuf);
void *opaque;
} FileOperations;
#endif
diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
index 04f7f6f..8ae5b07 100644
--- a/hw/virtio-9p-local.c
+++ b/hw/virtio-9p-local.c
@@ -469,6 +469,11 @@ static int local_fsync(FsContext *ctx, int fd)
return fsync(fd);
}
+static int local_statfs(FsContext *s, const char *path, struct statfs *stbuf)
+{
+ return statfs(rpath(s, path), stbuf);
+}
+
FileOperations local_ops = {
.lstat = local_lstat,
.readlink = local_readlink,
@@ -496,4 +501,5 @@ FileOperations local_ops = {
.utime = local_utime,
.remove = local_remove,
.fsync = local_fsync,
+.statfs = local_statfs,
};
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index e41c51e..20560e5 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -2145,9 +2145,72 @@ out:
qemu_free(vs);
}
+static int v9fs_do_statfs(V9fsState *s, V9fsString *path, struct statfs *stbuf)
+{
+return s-ops-statfs(s-ctx, path-data, stbuf);
+}
+
+static void v9fs_statfs_post_statfs(V9fsState *s, V9fsStatfsState *vs, int err)
+{
+if (err) {
+err = -errno;
+goto out;
+}
+
+vs-v9statfs.f_type = vs-stbuf.f_type;
+vs-v9statfs.f_bsize = vs-stbuf.f_bsize;
+vs-v9statfs.f_blocks = vs-stbuf.f_blocks;
+vs-v9statfs.f_bfree = vs-stbuf.f_bfree;
+vs-v9statfs.f_bavail = vs-stbuf.f_bavail;
+vs-v9statfs.f_files = vs-stbuf.f_files;
+vs-v9statfs.f_ffree = vs-stbuf.f_ffree;
+vs-v9statfs.fsid_val = (unsigned int) vs-stbuf.f_fsid.__val[0] |
+ (unsigned long long)vs-stbuf.f_fsid.__val[1] 32;
+vs-v9statfs.f_namelen = vs-stbuf.f_namelen;
+
+vs-offset += pdu_marshal(vs-pdu, vs-offset, ddqqd,
+ vs-v9statfs.f_type, vs-v9statfs.f_bsize, vs-v9statfs.f_blocks,
+ vs-v9statfs.f_bfree, vs-v9statfs.f_bavail, vs-v9statfs.f_files,
+ vs-v9statfs.f_ffree, vs-v9statfs.fsid_val,
+ vs-v9statfs.f_namelen);
+
+out:
+complete_pdu(s, vs-pdu, vs-offset);
+qemu_free(vs);
+}
+
+static void v9fs_statfs(V9fsState *s, V9fsPDU *pdu)
+{
+V9fsStatfsState *vs;
+ssize_t err = 0;
+
+vs = qemu_malloc(sizeof(*vs));
+vs-pdu = pdu;
+vs-offset = 7;
+
+memset(vs-v9statfs, 0, sizeof(vs-v9statfs));
+
+pdu_unmarshal(vs-pdu, vs-offset, d, vs-fid);
+
+vs-fidp = lookup_fid(s, vs-fid);
+if (vs-fidp == NULL) {
+err = -ENOENT;
+goto out;
+}
+
+err = v9fs_do_statfs(s, vs-fidp-path, vs-stbuf);
+v9fs_statfs_post_statfs(s, vs, err);
+return;
+
+out:
+complete_pdu(s, vs-pdu, err);
+qemu_free(vs);
+}
+
typedef void (pdu_handler_t)(V9fsState *s, V9fsPDU *pdu);
static pdu_handler_t *pdu_handlers[] = {
+[P9_TSTATFS] = v9fs_statfs,
[P9_TVERSION] = v9fs_version,
[P9_TATTACH] = v9fs_attach,
[P9_TSTAT] = v9fs_stat,
diff --git a/hw/virtio-9p.h b/hw/virtio-9p.h
index 9286f59..992c765 100644
--- a/hw/virtio-9p.h
+++ b/hw/virtio-9p.h
@@ -13,6 +13,8 @@
#define VIRTIO_9P_MOUNT_TAG 0
enum {
+P9_TSTATFS = 8,
+P9_RSTATFS,
P9_TVERSION = 100,
P9_RVERSION,
P9_TAUTH = 102,
@@ -252,6 +254,28 @@ struct virtio_9p_config
uint8_t tag[0];
} __attribute__((packed));
+typedef struct V9fsStatfs
+{
+uint32_t f_type;
+uint32_t f_bsize;
+uint64_t f_blocks;
+uint64_t f_bfree;
+uint64_t f_bavail;
+uint64_t f_files;
+uint64_t f_ffree;
+uint64_t fsid_val;
+uint32_t f_namelen;
+} V9fsStatfs;
+
+typedef struct V9fsStatfsState {
+V9fsPDU *pdu;
+size_t offset;
+int32_t fid;
+V9fsStatfs v9statfs;
+V9fsFidState *fidp;
+struct statfs stbuf;
+} V9fsStatfsState;
+
extern size_t pdu_packunpack(void *addr, struct iovec *sg, int sg_count,
size_t offset, size_t size, int pack);
--
1.6.5.2
[Qemu-devel] [PATCH-V2 01/24] qemu: virtio-9p: Recognize 9P2000.L protocol
From: M. Mohan Kumar mo...@in.ibm.com
Make 9P server recognize 9P2000.L protocol version
Signed-off-by: M. Mohan Kumar mo...@in.ibm.com
Signed-off-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
---
hw/virtio-9p.c |6 +-
hw/virtio-9p.h |6 ++
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index f8c85c3..e41c51e 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -1025,7 +1025,11 @@ static void v9fs_version(V9fsState *s, V9fsPDU *pdu)
pdu_unmarshal(pdu, offset, ds, msize, version);
-if (strcmp(version.data, 9P2000.u)) {
+if (!strcmp(version.data, 9P2000.u)) {
+s-proto_version = V9FS_PROTO_2000U;
+} else if (!strcmp(version.data, 9P2000.L)) {
+s-proto_version = V9FS_PROTO_2000L;
+} else {
v9fs_string_sprintf(version, unknown);
}
diff --git a/hw/virtio-9p.h b/hw/virtio-9p.h
index 67f8087..9286f59 100644
--- a/hw/virtio-9p.h
+++ b/hw/virtio-9p.h
@@ -57,6 +57,11 @@ enum {
P9_QTFILE = 0x00,
};
+enum p9_proto_version {
+V9FS_PROTO_2000U = 0x01,
+V9FS_PROTO_2000L = 0x02,
+};
+
#define P9_NOTAG(u16)(~0)
#define P9_NOFID(u32)(~0)
#define P9_MAXWELEM 16
@@ -144,6 +149,7 @@ typedef struct V9fsState
uint16_t tag_len;
uint8_t *tag;
size_t config_size;
+enum p9_proto_version proto_version;
} V9fsState;
typedef struct V9fsCreateState {
--
1.6.5.2
[Qemu-devel] [PATCH-V2 17/24] virtio-9p: Add fidtype so that we can do type specific operation
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
We want to add type specific operation during read/write
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
hw/virtio-9p.c | 110 ++--
hw/virtio-9p.h | 24 +++-
2 files changed, 81 insertions(+), 53 deletions(-)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index b4badc1..3e9c525 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -408,8 +408,7 @@ static V9fsFidState *alloc_fid(V9fsState *s, int32_t fid)
f = qemu_mallocz(sizeof(V9fsFidState));
f-fid = fid;
-f-fd = -1;
-f-dir = NULL;
+f-fid_type = P9_FID_NONE;
f-next = s-fid_list;
s-fid_list = f;
@@ -434,11 +433,20 @@ static int free_fid(V9fsState *s, int32_t fid)
fidp = *fidpp;
*fidpp = fidp-next;
-if (fidp-fd != -1) {
-v9fs_do_close(s, fidp-fd);
+if (fidp-fid_type == P9_FID_FILE) {
+if (fidp-fs.fd != -1) {
+ v9fs_do_close(s, fidp-fs.fd);
+}
+}
+if (fidp-fid_type == P9_FID_DIR) {
+if (fidp-fs.dir) {
+ v9fs_do_closedir(s, fidp-fs.dir);
+}
}
-if (fidp-dir) {
-v9fs_do_closedir(s, fidp-dir);
+if (fidp-fid_type == P9_FID_XATTR) {
+ if (fidp-fs.xattr.value) {
+ qemu_free(fidp-fs.xattr.value);
+ }
}
v9fs_string_free(fidp-path);
qemu_free(fidp);
@@ -1519,8 +1527,7 @@ static void v9fs_walk(V9fsState *s, V9fsPDU *pdu)
/* FIXME: is this really valid? */
if (fid == newfid) {
-BUG_ON(vs-fidp-fd != -1);
-BUG_ON(vs-fidp-dir);
+BUG_ON(vs-fidp-fid_type != P9_FID_NONE);
v9fs_string_init(vs-path);
vs-name_idx = 0;
@@ -1584,11 +1591,12 @@ static int32_t get_iounit(V9fsState *s, V9fsString
*name)
static void v9fs_open_post_opendir(V9fsState *s, V9fsOpenState *vs, int err)
{
-if (vs-fidp-dir == NULL) {
+if (vs-fidp-fs.dir == NULL) {
err = -errno;
goto out;
}
+vs-fidp-fid_type = P9_FID_DIR;
vs-offset += pdu_marshal(vs-pdu, vs-offset, Qd, vs-qid, 0);
err = vs-offset;
out:
@@ -1608,11 +1616,11 @@ static void v9fs_open_post_getiounit(V9fsState *s,
V9fsOpenState *vs)
static void v9fs_open_post_open(V9fsState *s, V9fsOpenState *vs, int err)
{
-if (vs-fidp-fd == -1) {
+if (vs-fidp-fs.fd == -1) {
err = -errno;
goto out;
}
-
+vs-fidp-fid_type = P9_FID_FILE;
vs-iounit = get_iounit(s, vs-fidp-path);
v9fs_open_post_getiounit(s, vs);
return;
@@ -1642,7 +1650,7 @@ static void v9fs_open_post_lstat(V9fsState *s,
V9fsOpenState *vs, int err)
stat_to_qid(vs-stbuf, vs-qid);
if (S_ISDIR(vs-stbuf.st_mode)) {
-vs-fidp-dir = v9fs_do_opendir(s, vs-fidp-path);
+vs-fidp-fs.dir = v9fs_do_opendir(s, vs-fidp-path);
v9fs_open_post_opendir(s, vs, err);
} else {
if (s-proto_version == V9FS_PROTO_2000L) {
@@ -1654,7 +1662,7 @@ static void v9fs_open_post_lstat(V9fsState *s,
V9fsOpenState *vs, int err)
} else {
flags = omode_to_uflags(vs-mode);
}
-vs-fidp-fd = v9fs_do_open(s, vs-fidp-path, flags);
+vs-fidp-fs.fd = v9fs_do_open(s, vs-fidp-path, flags);
v9fs_open_post_open(s, vs, err);
}
return;
@@ -1682,8 +1690,7 @@ static void v9fs_open(V9fsState *s, V9fsPDU *pdu)
goto out;
}
-BUG_ON(vs-fidp-fd != -1);
-BUG_ON(vs-fidp-dir);
+BUG_ON(vs-fidp-fid_type != P9_FID_NONE);
err = v9fs_do_lstat(s, vs-fidp-path, vs-stbuf);
@@ -1728,7 +1735,7 @@ out:
static void v9fs_lcreate_post_do_open2(V9fsState *s, V9fsLcreateState *vs,
int err)
{
-if (vs-fidp-fd == -1) {
+if (vs-fidp-fs.fd == -1) {
err = -errno;
goto out;
}
@@ -1765,7 +1772,7 @@ static void v9fs_lcreate(V9fsState *s, V9fsPDU *pdu)
v9fs_string_sprintf(vs-fullname, %s/%s, vs-fidp-path.data,
vs-name.data);
-vs-fidp-fd = v9fs_do_open2(s, vs-fullname.data, vs-fidp-uid,
+vs-fidp-fs.fd = v9fs_do_open2(s, vs-fullname.data, vs-fidp-uid,
gid, flags, mode);
v9fs_lcreate_post_do_open2(s, vs, err);
return;
@@ -1829,7 +1836,7 @@ static void v9fs_read_post_dir_lstat(V9fsState *s,
V9fsReadState *vs,
vs-v9stat);
if ((vs-len != (vs-v9stat.size + 2)) ||
((vs-count + vs-len) vs-max_count)) {
-v9fs_do_seekdir(s, vs-fidp-dir, vs-dir_pos);
+v9fs_do_seekdir(s, vs-fidp-fs.dir, vs-dir_pos);
v9fs_read_post_seekdir(s, vs, err);
return;
}
@@ -1837,11 +1844,11 @@ static void v9fs_read_post_dir_lstat(V9fsState *s,
V9fsReadState *vs,
v9fs_stat_free(vs-v9stat);
v9fs_string_free(vs-name);
vs-dir_pos = vs-dent-d_off;
-vs-dent = v9fs_do_readdir(s, vs-fidp-dir);
+vs-dent = v9fs_do_readdir(s, vs-fidp-fs.dir);
v9fs_read_post_readdir(s, vs, err);
return;
out:
-
[Qemu-devel] [PATCH-V2 00/24] Consolidated VirtFS work
This patch series is a consolidated view of various VirtFS patches on the Mailing List. None of these patches are new in this series. For sometime all these patches were on the mainling list individually. Signed-off-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
[Qemu-devel] [PATCH-V2 10/24] [virtio-9p] Implement TLINK for 9P2000.L
Create a Hardlink.
SYNOPSIS
size[4] Tlink tag[2] dfid[4] oldfid[4] newpath[s]
size[4] Rlink tag[2]
DESCRIPTION
Create a link 'newpath' in directory pointed by dfid linking to oldfid path.
Signed-off-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
---
hw/virtio-9p-debug.c |9 +
hw/virtio-9p.c | 38 ++
hw/virtio-9p.h |2 ++
3 files changed, 49 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-9p-debug.c b/hw/virtio-9p-debug.c
index a880b13..2e61e9d 100644
--- a/hw/virtio-9p-debug.c
+++ b/hw/virtio-9p-debug.c
@@ -497,6 +497,15 @@ void pprint_pdu(V9fsPDU *pdu)
case P9_RCLUNK:
fprintf(llogfile, RCLUNK: ();
break;
+case P9_TLINK:
+fprintf(llogfile, TLINK: ();
+pprint_int32(pdu, 0, offset, fid);
+pprint_str(pdu, 0, offset, , oldpath);
+pprint_str(pdu, 0, offset, , newpath);
+break;
+case P9_RLINK:
+fprintf(llogfile, RLINK: ();
+break;
case P9_TREMOVE:
fprintf(llogfile, TREMOVE: ();
pprint_int32(pdu, 0, offset, fid);
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 76c875c..e2d841c 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -2307,6 +2307,43 @@ static void v9fs_flush(V9fsState *s, V9fsPDU *pdu)
complete_pdu(s, pdu, 7);
}
+static void v9fs_link(V9fsState *s, V9fsPDU *pdu)
+{
+int32_t dfid, oldfid;
+V9fsFidState *dfidp, *oldfidp;
+V9fsString name, fullname;
+size_t offset = 7;
+int err = 0;
+
+v9fs_string_init(fullname);
+
+pdu_unmarshal(pdu, offset, dds, dfid, oldfid, name);
+
+dfidp = lookup_fid(s, dfid);
+if (dfidp == NULL) {
+err = -errno;
+goto out;
+}
+
+oldfidp = lookup_fid(s, oldfid);
+if (oldfidp == NULL) {
+err = -errno;
+goto out;
+}
+
+v9fs_string_sprintf(fullname, %s/%s, dfidp-path.data, name.data);
+err = offset;
+err = v9fs_do_link(s, oldfidp-path, fullname);
+if (err) {
+err = -errno;
+}
+v9fs_string_free(fullname);
+
+out:
+v9fs_string_free(name);
+complete_pdu(s, pdu, err);
+}
+
static void v9fs_remove_post_remove(V9fsState *s, V9fsRemoveState *vs,
int err)
{
@@ -2681,6 +2718,7 @@ static pdu_handler_t *pdu_handlers[] = {
[P9_TAUTH] = v9fs_auth,
#endif
[P9_TFLUSH] = v9fs_flush,
+[P9_TLINK] = v9fs_link,
[P9_TCREATE] = v9fs_create,
[P9_TWRITE] = v9fs_write,
[P9_TWSTAT] = v9fs_wstat,
diff --git a/hw/virtio-9p.h b/hw/virtio-9p.h
index ebf44a7..d48776f 100644
--- a/hw/virtio-9p.h
+++ b/hw/virtio-9p.h
@@ -21,6 +21,8 @@ enum {
P9_RSETATTR,
P9_TREADDIR = 40,
P9_RREADDIR,
+P9_TLINK = 70,
+P9_RLINK,
P9_TVERSION = 100,
P9_RVERSION,
P9_TAUTH = 102,
--
1.6.5.2
[Qemu-devel] [PATCH-V2 23/24] virtio-9p: Fix the memset usage
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
The arguments are wrong. Use qemu_mallocz directly
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Signed-off-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
---
hw/virtio-9p.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 68103ab..1621dab 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -2824,8 +2824,7 @@ static void v9fs_wstat_post_chown(V9fsState *s,
V9fsWstatState *vs, int err)
if (vs-v9stat.name.size != 0) {
V9fsRenameState *vr;
- vr = qemu_malloc(sizeof(V9fsRenameState));
- memset(vr, sizeof(*vr), 0);
+vr = qemu_mallocz(sizeof(V9fsRenameState));
vr-newdirfid = -1;
vr-pdu = vs-pdu;
vr-fidp = vs-fidp;
--
1.6.5.2
[Qemu-devel] [PATCH-V2 18/24] virtio-9p: Implement TXATTRWALK
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
TXATTRWALK: Descend a ATTR namespace
size[4] TXATTRWALK tag[2] fid[4] newfid[4] name[s]
size[4] RXATTRWALK tag[2] size[8]
txattrwalk gets a fid pointing to xattr. This fid can later be
used to get read the xattr value. If name is NULL the fid returned
can be used to get the list of extended attribute associated to
the file system object.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Signed-off-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
---
hw/file-op-9p.h |3 +
hw/virtio-9p-debug.c | 10 +++
hw/virtio-9p-local.c | 14
hw/virtio-9p.c | 191 +-
hw/virtio-9p.h | 14
5 files changed, 230 insertions(+), 2 deletions(-)
diff --git a/hw/file-op-9p.h b/hw/file-op-9p.h
index 120c803..8f466b4 100644
--- a/hw/file-op-9p.h
+++ b/hw/file-op-9p.h
@@ -75,6 +75,9 @@ typedef struct FileOperations
int (*truncate)(FsContext *, const char *, off_t);
int (*fsync)(FsContext *, int);
int (*statfs)(FsContext *s, const char *path, struct statfs *stbuf);
+ssize_t (*lgetxattr)(FsContext *, const char *, const char *, void *,
+size_t);
+ssize_t (*llistxattr)(FsContext *, const char *, void *, size_t);
void *opaque;
} FileOperations;
#endif
diff --git a/hw/virtio-9p-debug.c b/hw/virtio-9p-debug.c
index 949a4bf..4554eb6 100644
--- a/hw/virtio-9p-debug.c
+++ b/hw/virtio-9p-debug.c
@@ -579,6 +579,16 @@ void pprint_pdu(V9fsPDU *pdu)
case P9_RWSTAT:
fprintf(llogfile, RWSTAT: ();
break;
+case P9_TXATTRWALK:
+fprintf(llogfile, TXATTRWALK: ();
+pprint_int32(pdu, 0, offset, fid);
+pprint_int32(pdu, 0, offset, , newfid);
+pprint_str(pdu, 0, offset, , xattr name);
+break;
+case P9_RXATTRWALK:
+fprintf(llogfile, RXATTRWALK: ();
+pprint_int64(pdu, 1, offset, xattrsize);
+break;
default:
fprintf(llogfile, unknown(%d): (, pdu-id);
break;
diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
index 1f72f2e..5a3f5b8 100644
--- a/hw/virtio-9p-local.c
+++ b/hw/virtio-9p-local.c
@@ -477,6 +477,18 @@ static int local_statfs(FsContext *s, const char *path,
struct statfs *stbuf)
return statfs(rpath(s, path), stbuf);
}
+static ssize_t local_lgetxattr(FsContext *ctx, const char *path,
+const char *name, void *value, size_t size)
+{
+return lgetxattr(rpath(ctx, path), name, value, size);
+}
+
+static ssize_t local_llistxattr(FsContext *ctx, const char *path,
+void *value, size_t size)
+{
+return llistxattr(rpath(ctx, path), value, size);
+}
+
FileOperations local_ops = {
.lstat = local_lstat,
.readlink = local_readlink,
@@ -505,4 +517,6 @@ FileOperations local_ops = {
.remove = local_remove,
.fsync = local_fsync,
.statfs = local_statfs,
+.lgetxattr = local_lgetxattr,
+.llistxattr = local_llistxattr,
};
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 3e9c525..f0f6195 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -263,6 +263,21 @@ static int v9fs_do_statfs(V9fsState *s, V9fsString *path,
struct statfs *stbuf)
return s-ops-statfs(s-ctx, path-data, stbuf);
}
+static ssize_t v9fs_do_lgetxattr(V9fsState *s, V9fsString *path,
+ V9fsString *xattr_name,
+ void *value, size_t size)
+{
+return s-ops-lgetxattr(s-ctx, path-data,
+ xattr_name-data, value, size);
+}
+
+static ssize_t v9fs_do_llistxattr(V9fsState *s, V9fsString *path,
+ void *value, size_t size)
+{
+return s-ops-llistxattr(s-ctx, path-data,
+ value, size);
+}
+
static void v9fs_string_init(V9fsString *str)
{
str-data = NULL;
@@ -1946,6 +1961,31 @@ out:
qemu_free(vs);
}
+static void v9fs_xattr_read(V9fsState *s, V9fsReadState *vs)
+{
+ssize_t err = 0;
+int read_count;
+int64_t xattr_len;
+
+xattr_len = vs-fidp-fs.xattr.len;
+read_count = xattr_len - vs-off;
+if (read_count vs-count) {
+ read_count = vs-count;
+} else if (read_count 0) {
+ /*
+* read beyond XATTR value
+*/
+ read_count = 0;
+}
+vs-offset += pdu_marshal(vs-pdu, vs-offset, d, read_count);
+vs-offset += pdu_pack(vs-pdu, vs-offset,
+ ((char *)vs-fidp-fs.xattr.value) + vs-off,
+ read_count);
+err = vs-offset;
+complete_pdu(s, vs-pdu, err);
+qemu_free(vs);
+}
+
static void v9fs_read(V9fsState *s, V9fsPDU *pdu)
{
int32_t fid;
@@ -1967,7 +2007,7 @@ static void v9fs_read(V9fsState *s, V9fsPDU *pdu)
goto out;
}
-if (vs-fidp-fs.dir) {
+if (vs-fidp-fid_type == P9_FID_DIR vs-fidp-fs.dir) {
vs-max_count = vs-count;
vs-count = 0;
if (vs-off
[Qemu-devel] [PATCH-V2 19/24] virtio-9p: Implement TXATTRCREATE
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
TXATTRCREATE: Prepare a fid for setting xattr value on a file system object.
size[4] TXATTRCREATE tag[2] fid[4] name[s] attr_size[8] flags[4]
size[4] RXATTRWALK tag[2]
txattrcreate gets a fid pointing to xattr. This fid can later be
used to get set the xattr value.
flag value is derived from set Linux setxattr. The manpage says
The flags parameter can be used to refine the semantics of the operation.
XATTR_CREATE specifies a pure create, which fails if the named attribute
exists already. XATTR_REPLACE specifies a pure replace operation, which
fails if the named attribute does not already exist. By default (no flags),
the extended attribute will be created if need be, or will simply replace
the value if the attribute exists.
The actual setxattr operation happens when the fid is clunked. At that point
the written byte count and the attr_size specified in TXATTRCREATE should be
same otherwise an error will be returned.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Signed-off-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
---
hw/file-op-9p.h |2 +
hw/virtio-9p-debug.c |9 +++
hw/virtio-9p-local.c |7 +++
hw/virtio-9p.c | 143 ++---
hw/virtio-9p.h |2 +
5 files changed, 154 insertions(+), 9 deletions(-)
diff --git a/hw/file-op-9p.h b/hw/file-op-9p.h
index 8f466b4..2563f7b 100644
--- a/hw/file-op-9p.h
+++ b/hw/file-op-9p.h
@@ -78,6 +78,8 @@ typedef struct FileOperations
ssize_t (*lgetxattr)(FsContext *, const char *, const char *, void *,
size_t);
ssize_t (*llistxattr)(FsContext *, const char *, void *, size_t);
+int (*lsetxattr)(FsContext *, const char *, const char *, void *, size_t,
+int);
void *opaque;
} FileOperations;
#endif
diff --git a/hw/virtio-9p-debug.c b/hw/virtio-9p-debug.c
index 4554eb6..ad68054 100644
--- a/hw/virtio-9p-debug.c
+++ b/hw/virtio-9p-debug.c
@@ -588,6 +588,15 @@ void pprint_pdu(V9fsPDU *pdu)
case P9_RXATTRWALK:
fprintf(llogfile, RXATTRWALK: ();
pprint_int64(pdu, 1, offset, xattrsize);
+case P9_TXATTRCREATE:
+fprintf(llogfile, TXATTRCREATE: ();
+pprint_int32(pdu, 0, offset, fid);
+pprint_str(pdu, 0, offset, , name);
+pprint_int64(pdu, 0, offset, , xattrsize);
+pprint_int32(pdu, 0, offset, , flags);
+break;
+case P9_RXATTRCREATE:
+fprintf(llogfile, RXATTRCREATE: ();
break;
default:
fprintf(llogfile, unknown(%d): (, pdu-id);
diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
index 5a3f5b8..3944cf3 100644
--- a/hw/virtio-9p-local.c
+++ b/hw/virtio-9p-local.c
@@ -489,6 +489,12 @@ static ssize_t local_llistxattr(FsContext *ctx, const char
*path,
return llistxattr(rpath(ctx, path), value, size);
}
+static int local_lsetxattr(FsContext *ctx, const char *path, const char *name,
+ void *value, size_t size, int flags)
+{
+return lsetxattr(rpath(ctx, path), name, value, size, flags);
+}
+
FileOperations local_ops = {
.lstat = local_lstat,
.readlink = local_readlink,
@@ -519,4 +525,5 @@ FileOperations local_ops = {
.statfs = local_statfs,
.lgetxattr = local_lgetxattr,
.llistxattr = local_llistxattr,
+.lsetxattr = local_lsetxattr,
};
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index f0f6195..d931e05 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -278,6 +278,14 @@ static ssize_t v9fs_do_llistxattr(V9fsState *s, V9fsString
*path,
value, size);
}
+static int v9fs_do_lsetxattr(V9fsState *s, V9fsString *path,
+ V9fsString *xattr_name,
+ void *value, size_t size, int flags)
+{
+return s-ops-lsetxattr(s-ctx, path-data,
+ xattr_name-data, value, size, flags);
+}
+
static void v9fs_string_init(V9fsString *str)
{
str-data = NULL;
@@ -431,8 +439,39 @@ static V9fsFidState *alloc_fid(V9fsState *s, int32_t fid)
return f;
}
+static int v9fs_xattr_fid_clunk(V9fsState *s, V9fsFidState *fidp)
+{
+int retval = 0;
+
+if (fidp-fs.xattr.copied_len == -1) {
+ /* getxattr/listxattr fid */
+ goto free_value;
+}
+/*
+ * if this is fid for setxattr. clunk should
+ * result in setxattr localcall
+ */
+if (fidp-fs.xattr.len != fidp-fs.xattr.copied_len) {
+ /* clunk after partial write */
+ retval = -EINVAL;
+ goto free_out;
+}
+retval = v9fs_do_lsetxattr(s, fidp-path, fidp-fs.xattr.name,
+ fidp-fs.xattr.value,
+ fidp-fs.xattr.len,
+ fidp-fs.xattr.flags);
+free_out:
+v9fs_string_free(fidp-fs.xattr.name);
+free_value:
+if (fidp-fs.xattr.value) {
+ qemu_free(fidp-fs.xattr.value);
+}
+return retval;
+}
+
static int
[Qemu-devel] [PATCH-V2 07/24] virtio-9p: Do not reset atime
From: M. Mohan Kumar mo...@in.ibm.com
Current code resets file's atime to 0 when there is a change in mtime.
This results in resetting the atime to 1970-01-01 05:30:00. For
example, truncate -s 0 filename results in changing the mtime to the
truncate time, but resets the atime to 1970-01-01 05:30:00. utime
system call does not have any provision to set only mtime or atime. So
change v9fs_wstat_post_chmod function to use utimensat function to change
the atime and mtime fields. If tv_nsec field is set to the special value
UTIME_OMIT, corresponding file time stamp is not updated.
Signed-off-by: M. Mohan Kumar mo...@in.ibm.com
Signed-off-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
---
hw/file-op-9p.h |2 +-
hw/virtio-9p-local.c |8
hw/virtio-9p.c | 28
3 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/hw/file-op-9p.h b/hw/file-op-9p.h
index dd82ac7..120c803 100644
--- a/hw/file-op-9p.h
+++ b/hw/file-op-9p.h
@@ -52,7 +52,7 @@ typedef struct FileOperations
int (*chmod)(FsContext *, const char *, FsCred *);
int (*chown)(FsContext *, const char *, FsCred *);
int (*mknod)(FsContext *, const char *, FsCred *);
-int (*utime)(FsContext *, const char *, const struct utimbuf *);
+int (*utimensat)(FsContext *, const char *, const struct timespec *);
int (*remove)(FsContext *, const char *);
int (*symlink)(FsContext *, const char *, const char *, FsCred *);
int (*link)(FsContext *, const char *, const char *);
diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
index 8ae5b07..b29f513 100644
--- a/hw/virtio-9p-local.c
+++ b/hw/virtio-9p-local.c
@@ -453,10 +453,10 @@ static int local_chown(FsContext *fs_ctx, const char
*path, FsCred *credp)
return -1;
}
-static int local_utime(FsContext *ctx, const char *path,
-const struct utimbuf *buf)
+static int local_utimensat(FsContext *s, const char *path,
+ const struct timespec *buf)
{
-return utime(rpath(ctx, path), buf);
+return utimensat(AT_FDCWD, rpath(s, path), buf, AT_SYMLINK_NOFOLLOW);
}
static int local_remove(FsContext *ctx, const char *path)
@@ -498,7 +498,7 @@ FileOperations local_ops = {
.truncate = local_truncate,
.rename = local_rename,
.chown = local_chown,
-.utime = local_utime,
+.utimensat = local_utimensat,
.remove = local_remove,
.fsync = local_fsync,
.statfs = local_statfs,
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 10cc003..bb59c0c 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -237,10 +237,25 @@ static int v9fs_do_chown(V9fsState *s, V9fsString *path,
uid_t uid, gid_t gid)
return s-ops-chown(s-ctx, path-data, cred);
}
-static int v9fs_do_utime(V9fsState *s, V9fsString *path,
-const struct utimbuf *buf)
+static int v9fs_do_utimensat(V9fsState *s, V9fsString *path, V9fsStat v9stat)
{
-return s-ops-utime(s-ctx, path-data, buf);
+struct timespec ts[2];
+
+if (v9stat.atime != -1) {
+ts[0].tv_sec = v9stat.atime;
+ts[0].tv_nsec = 0;
+} else {
+ts[0].tv_nsec = UTIME_OMIT;
+}
+
+if (v9stat.mtime != -1) {
+ts[1].tv_sec = v9stat.mtime;
+ts[1].tv_nsec = 0;
+} else {
+ts[1].tv_nsec = UTIME_OMIT;
+}
+
+return s-ops-utimensat(s-ctx, path-data, ts);
}
static int v9fs_do_remove(V9fsState *s, V9fsString *path)
@@ -2326,11 +2341,8 @@ static void v9fs_wstat_post_chmod(V9fsState *s,
V9fsWstatState *vs, int err)
goto out;
}
-if (vs-v9stat.mtime != -1) {
-struct utimbuf tb;
-tb.actime = 0;
-tb.modtime = vs-v9stat.mtime;
-if (v9fs_do_utime(s, vs-fidp-path, tb)) {
+if (vs-v9stat.mtime != -1 || vs-v9stat.atime != -1) {
+if (v9fs_do_utimensat(s, vs-fidp-path, vs-v9stat)) {
err = -errno;
}
}
--
1.6.5.2
[Qemu-devel] [PATCH-V2 21/24] virtio-9p: Add SM_NONE security model
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
This is equivalent to SM_PASSTHROUGH security model.
The only exception is, failure of privilige operation like chown
are ignored. This makes a passthrough like security model usable
for people who runs kvm as non root
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Signed-off-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
---
hw/file-op-9p.h | 15 +--
hw/virtio-9p-local.c | 40 ++--
hw/virtio-9p.c | 13 ++---
qemu-options.hx |4 ++--
vl.c |2 +-
5 files changed, 56 insertions(+), 18 deletions(-)
diff --git a/hw/file-op-9p.h b/hw/file-op-9p.h
index 2563f7b..6461a20 100644
--- a/hw/file-op-9p.h
+++ b/hw/file-op-9p.h
@@ -24,8 +24,19 @@
typedef enum
{
-SM_PASSTHROUGH = 1, /* uid/gid set on fileserver files */
-SM_MAPPED, /* uid/gid part of xattr */
+/*
+ * Server will try to set uid/gid.
+ * On failure ignore the error.
+ */
+SM_NONE = 0,
+/*
+ * uid/gid set on fileserver files
+ */
+SM_PASSTHROUGH = 1,
+/*
+ * uid/gid part of xattr
+ */
+SM_MAPPED,
} SecModel;
typedef struct FsCred
diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
index 87ff953..67f12ad 100644
--- a/hw/virtio-9p-local.c
+++ b/hw/virtio-9p-local.c
@@ -102,7 +102,13 @@ static int local_post_create_passthrough(FsContext
*fs_ctx, const char *path,
return -1;
}
if (chown(rpath(fs_ctx, path), credp-fc_uid, credp-fc_gid) 0) {
-return -1;
+/*
+ * 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;
+}
}
return 0;
}
@@ -122,7 +128,8 @@ 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) {
+} else if ((fs_ctx-fs_sm == SM_PASSTHROUGH) ||
+ (fs_ctx-fs_sm == SM_NONE)) {
tsize = readlink(rpath(fs_ctx, path), buf, bufsz);
}
return tsize;
@@ -189,7 +196,8 @@ 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) {
+} else if ((fs_ctx-fs_sm == SM_PASSTHROUGH) ||
+ (fs_ctx-fs_sm == SM_NONE)) {
return chmod(rpath(fs_ctx, path), credp-fc_mode);
}
return -1;
@@ -211,7 +219,8 @@ static int local_mknod(FsContext *fs_ctx, const char *path,
FsCred *credp)
serrno = errno;
goto err_end;
}
-} else if (fs_ctx-fs_sm == SM_PASSTHROUGH) {
+} else if ((fs_ctx-fs_sm == SM_PASSTHROUGH) ||
+ (fs_ctx-fs_sm == SM_NONE)) {
err = mknod(rpath(fs_ctx, path), credp-fc_mode, credp-fc_rdev);
if (err == -1) {
return err;
@@ -247,7 +256,8 @@ static int local_mkdir(FsContext *fs_ctx, const char *path,
FsCred *credp)
serrno = errno;
goto err_end;
}
-} else if (fs_ctx-fs_sm == SM_PASSTHROUGH) {
+} else if ((fs_ctx-fs_sm == SM_PASSTHROUGH) ||
+ (fs_ctx-fs_sm == SM_NONE)) {
err = mkdir(rpath(fs_ctx, path), credp-fc_mode);
if (err == -1) {
return err;
@@ -316,7 +326,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) {
+} else if ((fs_ctx-fs_sm == SM_PASSTHROUGH) ||
+ (fs_ctx-fs_sm == SM_NONE)) {
fd = open(rpath(fs_ctx, path), flags, credp-fc_mode);
if (fd == -1) {
return fd;
@@ -372,15 +383,23 @@ static int local_symlink(FsContext *fs_ctx, const char
*oldpath,
serrno = errno;
goto err_end;
}
-} else if (fs_ctx-fs_sm == SM_PASSTHROUGH) {
+} else if ((fs_ctx-fs_sm == SM_PASSTHROUGH) ||
+ (fs_ctx-fs_sm == SM_NONE)) {
err = symlink(oldpath, rpath(fs_ctx, newpath));
if (err) {
return err;
}
err = lchown(rpath(fs_ctx, newpath), credp-fc_uid, credp-fc_gid);
if (err == -1) {
-serrno = errno;
-goto err_end;
+/*
+ * If we fail to change ownership and if we are
+ * using security model none. Ignore the error
+ */
+if (fs_ctx-fs_sm != SM_NONE) {
+serrno = errno;
+goto err_end;
+} else
+err = 0;
}
}
return err;
@@ -450,7 +469,8 @@ static int local_chown(FsContext *fs_ctx, const char *path,
FsCred *credp)
return
[Qemu-devel] [PATCH-V2 03/24] virtio-9p: Return correct error from v9fs_remove
From: Sripathi Kodi sripat...@in.ibm.com
Signed-off-by: Sripathi Kodi sripat...@in.ibm.com
In v9fs_remove_post_remove() we currently ignore the error returned by
the previous call to remove() and return an error only if freeing the
fid fails. However, the client expects to see the error from remove().
Currently the client falsely thinks that the remove call has always
succeeded. For example, doing rmdir on a non-empty directory does
not return ENOTEMPTY.
With this patch we ignore the error from free_fid(). The client cannot
use this error value anyway.
Signed-off-by: Sripathi Kodi sripat...@in.ibm.com
Signed-off-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
---
hw/virtio-9p.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 20560e5..0540a74 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -1877,14 +1877,15 @@ static void v9fs_flush(V9fsState *s, V9fsPDU *pdu)
static void v9fs_remove_post_remove(V9fsState *s, V9fsRemoveState *vs,
int err)
{
-/* For TREMOVE we need to clunk the fid even on failed remove */
-err = free_fid(s, vs-fidp-fid);
if (err 0) {
-goto out;
+err = -errno;
+} else {
+err = vs-offset;
}
-err = vs-offset;
-out:
+/* For TREMOVE we need to clunk the fid even on failed remove */
+free_fid(s, vs-fidp-fid);
+
complete_pdu(s, vs-pdu, err);
qemu_free(vs);
}
--
1.6.5.2
[Qemu-devel] [PATCH-V2 09/24] virtio-9p: Implement server side of setattr for 9P2000.L protocol.
From: Sripathi Kodi sripat...@in.ibm.com
SYNOPSIS
size[4] Tsetattr tag[2] attr[n]
size[4] Rsetattr tag[2]
DESCRIPTION
The setattr command changes some of the file status information.
attr resembles the iattr structure used in Linux kernel. It
specifies which status parameter is to be changed and to what
value. It is laid out as follows:
valid[4]
specifies which status information is to be changed. Possible
values are:
ATTR_MODE (1 0)
ATTR_UID(1 1)
ATTR_GID(1 2)
ATTR_SIZE (1 3)
ATTR_ATIME (1 4)
ATTR_MTIME (1 5)
ATTR_CTIME (1 5)
ATTR_ATIME_SET (1 7)
ATTR_MTIME_SET (1 8)
The last two bits represent whether the time information
is being sent by the client's user space. In the absense
of these bits the server always uses server's time.
mode[4]
File permission bits
uid[4]
Owner id of file
gid[4]
Group id of the file
size[8]
File size
atime_sec[8]
Time of last file access, seconds
atime_nsec[8]
Time of last file access, nanoseconds
mtime_sec[8]
Time of last file modification, seconds
mtime_nsec[8]
Time of last file modification, nanoseconds
Explanation of the patches:
--
*) The kernel just copies relevent contents of iattr structure to p9_iattr_dotl
structure and passes it down to the client. The only check it has is calling
inode_change_ok()
*) The p9_iattr_dotl structure does not have ctime and ia_file parameters
because
I don't think these are needed in our case. The client user space can request
updating just ctime by calling chown(fd, -1, -1). This is handled on server
side without a need for putting ctime on the wire.
*) The server currently supports changing mode, time, ownership and size of the
file.
*) 9P RFC says Either all the changes in wstat request happen, or none of them
does: if the request succeeds, all changes were made; if it fails, none
were.
I have not done anything to implement this specifically because I don't see
a reason.
[jv...@linux.vnet.ibm.com: Parts of code for handling chown(-1,-1)
Signed-off-by: Sripathi Kodi sripat...@in.ibm.com
Signed-off-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
---
hw/virtio-9p-local.c |5 +-
hw/virtio-9p.c | 155 ++
hw/virtio-9p.h | 23
3 files changed, 182 insertions(+), 1 deletions(-)
diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
index b29f513..1f72f2e 100644
--- a/hw/virtio-9p-local.c
+++ b/hw/virtio-9p-local.c
@@ -445,7 +445,10 @@ static int local_rename(FsContext *ctx, const char
*oldpath,
static int local_chown(FsContext *fs_ctx, const char *path, FsCred *credp)
{
-if (fs_ctx-fs_sm == SM_MAPPED) {
+if ((credp-fc_uid == -1 credp-fc_gid == -1) ||
+(fs_ctx-fs_sm == SM_PASSTHROUGH)) {
+return lchown(rpath(fs_ctx, path), credp-fc_uid, credp-fc_gid);
+} else if (fs_ctx-fs_sm == SM_MAPPED) {
return local_set_xattr(rpath(fs_ctx, path), credp);
} else if (fs_ctx-fs_sm == SM_PASSTHROUGH) {
return lchown(rpath(fs_ctx, path), credp-fc_uid, credp-fc_gid);
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index e4754b8..76c875c 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -665,6 +665,15 @@ static size_t pdu_unmarshal(V9fsPDU *pdu, size_t offset,
const char *fmt, ...)
statp-n_muid);
break;
}
+case 'I': {
+V9fsIattr *iattr = va_arg(ap, V9fsIattr *);
+offset += pdu_unmarshal(pdu, offset, q,
+iattr-valid, iattr-mode,
+iattr-uid, iattr-gid, iattr-size,
+iattr-atime_sec, iattr-atime_nsec,
+iattr-mtime_sec, iattr-mtime_nsec);
+break;
+}
default:
break;
}
@@ -1240,6 +1249,151 @@ out:
qemu_free(vs);
}
+/* From Linux kernel code */
+#define ATTR_MODE(1 0)
+#define ATTR_UID (1 1)
+#define ATTR_GID (1 2)
+#define ATTR_SIZE(1 3)
+#define ATTR_ATIME (1 4)
+#define ATTR_MTIME (1 5)
+#define ATTR_CTIME (1 6)
+#define ATTR_MASK127
+#define ATTR_ATIME_SET (1 7)
+#define ATTR_MTIME_SET (1 8)
+
+static void v9fs_setattr_post_truncate(V9fsState *s, V9fsSetattrState *vs,
+ int err)
+{
+if (err == -1) {
+err = -errno;
+goto out;
+}
+err = vs-offset;
+
+out:
+complete_pdu(s, vs-pdu, err);
+qemu_free(vs);
+}
+
+static void v9fs_setattr_post_chown(V9fsState
[Qemu-devel] [PATCH-V2 11/24] [virtio-9p] Define and implement TSYMLINK for 9P2000.L
This patch implements creating a symlink for TSYMLINK request
and responds with RSYMLINK. In the case of error, we return RERROR.
SYNOPSIS
size[4] Tsymlink tag[2] fid[4] name[s] symtgt[s] gid[4]
size[4] Rsymlink tag[2] qid[13]
DESCRIPTION
Create a symbolic link named 'name' pointing to 'symtgt'.
gid represents the effective group id of the caller.
The permissions of a symbolic link are irrelevant hence it is omitted
from the protocol.
Signed-off-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
---
hw/virtio-9p-debug.c | 11 +++
hw/virtio-9p.c | 78 ++
hw/virtio-9p.h | 14 +
3 files changed, 97 insertions(+), 6 deletions(-)
diff --git a/hw/virtio-9p-debug.c b/hw/virtio-9p-debug.c
index 2e61e9d..54179aa 100644
--- a/hw/virtio-9p-debug.c
+++ b/hw/virtio-9p-debug.c
@@ -464,6 +464,17 @@ void pprint_pdu(V9fsPDU *pdu)
pprint_qid(pdu, 1, offset, qid);
pprint_int32(pdu, 1, offset, , iounit);
break;
+case P9_TSYMLINK:
+fprintf(llogfile, TSYMLINK: ();
+pprint_int32(pdu, 0, offset, fid);
+pprint_str(pdu, 0, offset, , name);
+pprint_str(pdu, 0, offset, , symname);
+pprint_int32(pdu, 0, offset, , gid);
+break;
+case P9_RSYMLINK:
+fprintf(llogfile, RSYMLINK: ();
+pprint_qid(pdu, 1, offset, qid);
+break;
case P9_TREAD:
fprintf(llogfile, TREAD: ();
pprint_int32(pdu, 0, offset, fid);
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index e2d841c..b048527 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -200,15 +200,16 @@ static int v9fs_do_open2(V9fsState *s, V9fsCreateState
*vs)
return s-ops-open2(s-ctx, vs-fullname.data, flags, cred);
}
-static int v9fs_do_symlink(V9fsState *s, V9fsCreateState *vs)
+static int v9fs_do_symlink(V9fsState *s, V9fsFidState *fidp,
+const char *oldpath, const char *newpath, gid_t gid)
{
FsCred cred;
cred_init(cred);
-cred.fc_uid = vs-fidp-uid;
-cred.fc_mode = vs-perm | 0777;
+cred.fc_uid = fidp-uid;
+cred.fc_gid = gid;
+cred.fc_mode = 0777;
-return s-ops-symlink(s-ctx, vs-extension.data, vs-fullname.data,
-cred);
+return s-ops-symlink(s-ctx, oldpath, newpath, cred);
}
static int v9fs_do_link(V9fsState *s, V9fsString *oldpath, V9fsString *newpath)
@@ -2212,7 +2213,8 @@ static void v9fs_create_post_lstat(V9fsState *s,
V9fsCreateState *vs, int err)
err = v9fs_do_mkdir(s, vs);
v9fs_create_post_mkdir(s, vs, err);
} else if (vs-perm P9_STAT_MODE_SYMLINK) {
-err = v9fs_do_symlink(s, vs);
+err = v9fs_do_symlink(s, vs-fidp, vs-extension.data,
+vs-fullname.data, -1);
v9fs_create_post_perms(s, vs, err);
} else if (vs-perm P9_STAT_MODE_LINK) {
int32_t nfid = atoi(vs-extension.data);
@@ -2301,6 +2303,69 @@ out:
qemu_free(vs);
}
+static void v9fs_post_symlink(V9fsState *s, V9fsSymlinkState *vs, int err)
+{
+if (err == 0) {
+stat_to_qid(vs-stbuf, vs-qid);
+vs-offset += pdu_marshal(vs-pdu, vs-offset, Q, vs-qid);
+err = vs-offset;
+} else {
+err = -errno;
+}
+complete_pdu(s, vs-pdu, err);
+v9fs_string_free(vs-name);
+v9fs_string_free(vs-symname);
+v9fs_string_free(vs-fullname);
+qemu_free(vs);
+}
+
+static void v9fs_symlink_post_do_symlink(V9fsState *s, V9fsSymlinkState *vs,
+int err)
+{
+if (err) {
+goto out;
+}
+err = v9fs_do_lstat(s, vs-fullname, vs-stbuf);
+out:
+v9fs_post_symlink(s, vs, err);
+}
+
+static void v9fs_symlink(V9fsState *s, V9fsPDU *pdu)
+{
+int32_t dfid;
+V9fsSymlinkState *vs;
+int err = 0;
+gid_t gid;
+
+vs = qemu_malloc(sizeof(*vs));
+vs-pdu = pdu;
+vs-offset = 7;
+
+v9fs_string_init(vs-fullname);
+
+pdu_unmarshal(vs-pdu, vs-offset, dssd, dfid, vs-name,
+vs-symname, gid);
+
+vs-dfidp = lookup_fid(s, dfid);
+if (vs-dfidp == NULL) {
+err = -EINVAL;
+goto out;
+}
+
+v9fs_string_sprintf(vs-fullname, %s/%s, vs-dfidp-path.data,
+vs-name.data);
+err = v9fs_do_symlink(s, vs-dfidp, vs-symname.data,
+vs-fullname.data, gid);
+v9fs_symlink_post_do_symlink(s, vs, err);
+return;
+
+out:
+complete_pdu(s, vs-pdu, err);
+v9fs_string_free(vs-name);
+v9fs_string_free(vs-symname);
+qemu_free(vs);
+}
+
static void v9fs_flush(V9fsState *s, V9fsPDU *pdu)
{
/* A nop call with no return */
@@ -2719,6 +2784,7 @@ static pdu_handler_t *pdu_handlers[] = {
#endif
[P9_TFLUSH] = v9fs_flush,
[P9_TLINK] = v9fs_link,
+[P9_TSYMLINK] = v9fs_symlink,
[P9_TCREATE] = v9fs_create,
[P9_TWRITE] = v9fs_write,
[P9_TWSTAT] = v9fs_wstat,
diff --git a/hw/virtio-9p.h b/hw/virtio-9p.h
index d48776f..3671863 100644
--- a/hw/virtio-9p.h
+++ b/hw/virtio-9p.h
@@ -15,6 +15,8 @@
[Qemu-devel] [PATCH-V2 12/24] [virtio-9p] This patch implements TLCREATE for 9p2000.L protocol.
SYNOPSIS
size[4] Tlcreate tag[2] fid[4] name[s] flags[4] mode[4] gid[4]
size[4] Rlcreate tag[2] qid[13] iounit[4]
DESCRIPTION
The Tlreate request asks the file server to create a new regular file with the
name supplied, in the directory (dir) represented by fid.
The mode argument specifies the permissions to use. New file is created with
the uid if the fid and with supplied gid.
The flags argument represent Linux access mode flags with which the caller
is requesting to open the file with. Protocol allows all the Linux access
modes but it is upto the server to allow/disallow any of these acess modes.
If the server doesn't support any of the access mode, it is expected to
return error.
To start with we will not restricit/limit any Linux flags on this server.
If needed, We can start restricting as we move forward with various use cases.
Signed-off-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
---
hw/virtio-9p-debug.c | 13 ++
hw/virtio-9p.c | 100 ++---
hw/virtio-9p.h | 13 ++
3 files changed, 119 insertions(+), 7 deletions(-)
diff --git a/hw/virtio-9p-debug.c b/hw/virtio-9p-debug.c
index 54179aa..a8abdd2 100644
--- a/hw/virtio-9p-debug.c
+++ b/hw/virtio-9p-debug.c
@@ -475,6 +475,19 @@ void pprint_pdu(V9fsPDU *pdu)
fprintf(llogfile, RSYMLINK: ();
pprint_qid(pdu, 1, offset, qid);
break;
+case P9_TLCREATE:
+fprintf(llogfile, TLCREATE: ();
+pprint_int32(pdu, 0, offset, dfid);
+pprint_str(pdu, 0, offset, , name);
+pprint_int32(pdu, 0, offset, , flags);
+pprint_int32(pdu, 0, offset, , mode);
+pprint_int32(pdu, 0, offset, , gid);
+break;
+case P9_RLCREATE:
+fprintf(llogfile, RLCREATE: ();
+pprint_qid(pdu, 1, offset, qid);
+pprint_int32(pdu, 1, offset, , iounit);
+break;
case P9_TREAD:
fprintf(llogfile, TREAD: ();
pprint_int32(pdu, 0, offset, fid);
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index b048527..3944548 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -187,17 +187,18 @@ static int v9fs_do_fstat(V9fsState *s, int fd, struct
stat *stbuf)
return s-ops-fstat(s-ctx, fd, stbuf);
}
-static int v9fs_do_open2(V9fsState *s, V9fsCreateState *vs)
+static int v9fs_do_open2(V9fsState *s, char *fullname, uid_t uid, gid_t gid,
+int flags, int mode)
{
FsCred cred;
-int flags;
cred_init(cred);
-cred.fc_uid = vs-fidp-uid;
-cred.fc_mode = vs-perm 0777;
-flags = omode_to_uflags(vs-mode) | O_CREAT;
+cred.fc_uid = uid;
+cred.fc_gid = gid;
+cred.fc_mode = mode 0;
+flags = flags;
-return s-ops-open2(s-ctx, vs-fullname.data, flags, cred);
+return s-ops-open2(s-ctx, fullname, flags, cred);
}
static int v9fs_do_symlink(V9fsState *s, V9fsFidState *fidp,
@@ -1671,6 +1672,88 @@ out:
qemu_free(vs);
}
+static void v9fs_post_lcreate(V9fsState *s, V9fsLcreateState *vs, int err)
+{
+if (err == 0) {
+v9fs_string_copy(vs-fidp-path, vs-fullname);
+stat_to_qid(vs-stbuf, vs-qid);
+vs-offset += pdu_marshal(vs-pdu, vs-offset, Qd, vs-qid,
+vs-iounit);
+err = vs-offset;
+} else {
+err = -errno;
+}
+
+complete_pdu(s, vs-pdu, err);
+v9fs_string_free(vs-name);
+v9fs_string_free(vs-fullname);
+qemu_free(vs);
+}
+
+static void v9fs_lcreate_post_get_iounit(V9fsState *s, V9fsLcreateState *vs,
+int err)
+{
+if (err) {
+err = -errno;
+goto out;
+}
+err = v9fs_do_lstat(s, vs-fullname, vs-stbuf);
+
+out:
+v9fs_post_lcreate(s, vs, err);
+}
+
+static void v9fs_lcreate_post_do_open2(V9fsState *s, V9fsLcreateState *vs,
+int err)
+{
+if (vs-fidp-fd == -1) {
+err = -errno;
+goto out;
+}
+vs-iounit = get_iounit(s, vs-fullname);
+v9fs_lcreate_post_get_iounit(s, vs, err);
+return;
+
+out:
+v9fs_post_lcreate(s, vs, err);
+}
+
+static void v9fs_lcreate(V9fsState *s, V9fsPDU *pdu)
+{
+int32_t dfid, flags, mode;
+gid_t gid;
+V9fsLcreateState *vs;
+ssize_t err = 0;
+
+vs = qemu_malloc(sizeof(*vs));
+vs-pdu = pdu;
+vs-offset = 7;
+
+v9fs_string_init(vs-fullname);
+
+pdu_unmarshal(vs-pdu, vs-offset, dsddd, dfid, vs-name, flags,
+mode, gid);
+
+vs-fidp = lookup_fid(s, dfid);
+if (vs-fidp == NULL) {
+err = -ENOENT;
+goto out;
+}
+
+v9fs_string_sprintf(vs-fullname, %s/%s, vs-fidp-path.data,
+ vs-name.data);
+
+vs-fidp-fd = v9fs_do_open2(s, vs-fullname.data, vs-fidp-uid,
+gid, flags, mode);
+v9fs_lcreate_post_do_open2(s, vs, err);
+return;
+
+out:
+complete_pdu(s, vs-pdu, err);
+v9fs_string_free(vs-name);
+qemu_free(vs);
+}
+
static void v9fs_clunk(V9fsState *s, V9fsPDU *pdu)
{
int32_t fid;
@@ -2258,7 +2341,9 @@ static void
[Qemu-devel] [PATCH-V2 14/24] qemu: virtio-9p: Implement TMKDIR
From: M. Mohan Kumar mo...@in.ibm.com
Synopsis
size[4] Tmkdir tag[2] fid[4] name[s] mode[4] gid[4]
size[4] Rmkdir tag[2] qid[13]
Description
mkdir asks the file server to create a directory with given name,
mode and gid. The qid for the new directory is returned with
the mkdir reply message.
Note: 72 is selected as the opcode for TMKDIR from the reserved list.
Signed-off-by: M. Mohan Kumar mo...@in.ibm.com
[jv...@linux.vnet.ibm.com: Fix perm handling when creating directory]
Signed-off-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
---
hw/virtio-9p-debug.c | 11 ++
hw/virtio-9p.c | 83 +++---
hw/virtio-9p.h |2 +
3 files changed, 91 insertions(+), 5 deletions(-)
diff --git a/hw/virtio-9p-debug.c b/hw/virtio-9p-debug.c
index 6a527ce..949a4bf 100644
--- a/hw/virtio-9p-debug.c
+++ b/hw/virtio-9p-debug.c
@@ -367,6 +367,17 @@ void pprint_pdu(V9fsPDU *pdu)
pprint_data(pdu, 1, offset, , data);
#endif
break;
+case P9_TMKDIR:
+fprintf(llogfile, TMKDIR: ();
+pprint_int32(pdu, 0, offset, fid);
+pprint_str(pdu, 0, offset, name);
+pprint_int32(pdu, 0, offset, mode);
+pprint_int32(pdu, 0, offset, gid);
+break;
+case P9_RMKDIR:
+fprintf(llogfile, RMKDIR: ();
+pprint_qid(pdu, 0, offset, qid);
+break;
case P9_TVERSION:
fprintf(llogfile, TVERSION: ();
pprint_int32(pdu, 0, offset, msize);
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 24adaec..c853eca 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -172,15 +172,17 @@ static int v9fs_do_mknod(V9fsState *s, char *name,
return s-ops-mknod(s-ctx, name, cred);
}
-static int v9fs_do_mkdir(V9fsState *s, V9fsCreateState *vs)
+static int v9fs_do_mkdir(V9fsState *s, char *name, mode_t mode,
+uid_t uid, gid_t gid)
{
FsCred cred;
cred_init(cred);
-cred.fc_uid = vs-fidp-uid;
-cred.fc_mode = vs-perm 0777;
+cred.fc_uid = uid;
+cred.fc_gid = gid;
+cred.fc_mode = mode;
-return s-ops-mkdir(s-ctx, vs-fullname.data, cred);
+return s-ops-mkdir(s-ctx, name, cred);
}
static int v9fs_do_fstat(V9fsState *s, int fd, struct stat *stbuf)
@@ -2294,7 +2296,8 @@ static void v9fs_create_post_lstat(V9fsState *s,
V9fsCreateState *vs, int err)
}
if (vs-perm P9_STAT_MODE_DIR) {
-err = v9fs_do_mkdir(s, vs);
+err = v9fs_do_mkdir(s, vs-fullname.data, vs-perm 0777,
+vs-fidp-uid, -1);
v9fs_create_post_mkdir(s, vs, err);
} else if (vs-perm P9_STAT_MODE_SYMLINK) {
err = v9fs_do_symlink(s, vs-fidp, vs-extension.data,
@@ -2925,6 +2928,75 @@ out:
qemu_free(vs);
}
+static void v9fs_mkdir_post_lstat(V9fsState *s, V9fsMkState *vs, int err)
+{
+if (err == -1) {
+err = -errno;
+goto out;
+}
+
+stat_to_qid(vs-stbuf, vs-qid);
+vs-offset += pdu_marshal(vs-pdu, vs-offset, Q, vs-qid);
+err = vs-offset;
+out:
+complete_pdu(s, vs-pdu, err);
+v9fs_string_free(vs-fullname);
+v9fs_string_free(vs-name);
+qemu_free(vs);
+}
+
+static void v9fs_mkdir_post_mkdir(V9fsState *s, V9fsMkState *vs, int err)
+{
+if (err == -1) {
+err = -errno;
+goto out;
+}
+
+err = v9fs_do_lstat(s, vs-fullname, vs-stbuf);
+v9fs_mkdir_post_lstat(s, vs, err);
+return;
+out:
+complete_pdu(s, vs-pdu, err);
+v9fs_string_free(vs-fullname);
+v9fs_string_free(vs-name);
+qemu_free(vs);
+}
+
+static void v9fs_mkdir(V9fsState *s, V9fsPDU *pdu)
+{
+int32_t fid;
+V9fsMkState *vs;
+int err = 0;
+V9fsFidState *fidp;
+gid_t gid;
+int mode;
+
+vs = qemu_malloc(sizeof(*vs));
+vs-pdu = pdu;
+vs-offset = 7;
+
+v9fs_string_init(vs-fullname);
+pdu_unmarshal(vs-pdu, vs-offset, dsdd, fid, vs-name, mode,
+gid);
+
+fidp = lookup_fid(s, fid);
+if (fidp == NULL) {
+err = -ENOENT;
+goto out;
+}
+
+v9fs_string_sprintf(vs-fullname, %s/%s, fidp-path.data,
vs-name.data);
+err = v9fs_do_mkdir(s, vs-fullname.data, mode, fidp-uid, gid);
+v9fs_mkdir_post_mkdir(s, vs, err);
+return;
+
+out:
+complete_pdu(s, vs-pdu, err);
+v9fs_string_free(vs-fullname);
+v9fs_string_free(vs-name);
+qemu_free(vs);
+}
+
typedef void (pdu_handler_t)(V9fsState *s, V9fsPDU *pdu);
static pdu_handler_t *pdu_handlers[] = {
@@ -2933,6 +3005,7 @@ static pdu_handler_t *pdu_handlers[] = {
[P9_TGETATTR] = v9fs_getattr,
[P9_TSETATTR] = v9fs_setattr,
[P9_TMKNOD] = v9fs_mknod,
+[P9_TMKDIR] = v9fs_mkdir,
[P9_TVERSION] = v9fs_version,
[P9_TATTACH] = v9fs_attach,
[P9_TSTAT] = v9fs_stat,
diff --git a/hw/virtio-9p.h b/hw/virtio-9p.h
index 8ba45ac..91cc0ae 100644
--- a/hw/virtio-9p.h
+++ b/hw/virtio-9p.h
@@ -29,6 +29,8 @@ enum {
P9_RREADDIR,
P9_TLINK = 70,
P9_RLINK,
+P9_TMKDIR = 72,
+
[Qemu-devel] [PATCH-V2 06/24] virtio-9p: getattr server implementation for 9P2000.L protocol.
From: Sripathi Kodi sripa...@sripathi.in.ibm.com SYNOPSIS size[4] Tgetattr tag[2] fid[4] request_mask[8] size[4] Rgetattr tag[2] lstat[n] DESCRIPTION The getattr transaction inquires about the file identified by fid. request_mask is a bit mask that specifies which fields of the stat structure is the client interested in. The reply will contain a machine-independent directory entry, laid out as follows: st_result_mask[8] Bit mask that indicates which fields in the stat structure have been populated by the server qid.type[1] the type of the file (directory, etc.), represented as a bit vector corresponding to the high 8 bits of the file's mode word. qid.vers[4] version number for given path qid.path[8] the file server's unique identification for the file st_mode[4] Permission and flags st_uid[4] User id of owner st_gid[4] Group ID of owner st_nlink[8] Number of hard links st_rdev[8] Device ID (if special file) st_size[8] Size, in bytes st_blksize[8] Block size for file system IO st_blocks[8] Number of file system blocks allocated st_atime_sec[8] Time of last access, seconds st_atime_nsec[8] Time of last access, nanoseconds st_mtime_sec[8] Time of last modification, seconds st_mtime_nsec[8] Time of last modification, nanoseconds st_ctime_sec[8] Time of last status change, seconds st_ctime_nsec[8] Time of last status change, nanoseconds st_btime_sec[8] Time of creation (birth) of file, seconds st_btime_nsec[8] Time of creation (birth) of file, nanoseconds st_gen[8] Inode generation st_data_version[8] Data version number request_mask and result_mask bit masks contain the following bits #define P9_STATS_MODE 0x0001ULL #define P9_STATS_NLINK 0x0002ULL #define P9_STATS_UID 0x0004ULL #define P9_STATS_GID 0x0008ULL #define P9_STATS_RDEV 0x0010ULL #define P9_STATS_ATIME 0x0020ULL #define P9_STATS_MTIME 0x0040ULL #define P9_STATS_CTIME 0x0080ULL #define P9_STATS_INO 0x0100ULL #define P9_STATS_SIZE 0x0200ULL #define P9_STATS_BLOCKS0x0400ULL #define P9_STATS_BTIME 0x0800ULL #define P9_STATS_GEN 0x1000ULL #define P9_STATS_DATA_VERSION 0x2000ULL #define P9_STATS_BASIC 0x07ffULL #define P9_STATS_ALL 0x3fffULL This patch implements the client side of getattr implementation for 9P2000.L. It introduces a new structure p9_stat_dotl for getting Linux stat information along with QID. The data layout is similar to stat structure in Linux user space with the following major differences: inode (st_ino) is not part of data. Instead qid is. device (st_dev) is not part of data because this doesn't make sense on the client. All time variables are 64 bit wide on the wire. The kernel seems to use 32 bit variables for these variables. However, some of the architectures have used 64 bit variables and glibc exposes 64 bit variables to user space on some architectures. Hence to be on the safer side we have made these 64 bit in the protocol. Refer to the comments in include/asm-generic/stat.h There are some additional fields: st_btime_sec, st_btime_nsec, st_gen, st_data_version apart from the bitmask, st_result_mask. The bit mask is filled by the server to indicate which stat fields have been populated by the server. Currently there is no clean way for the server to obtain these additional fields, so it sends back just the basic fields. Signed-off-by: M. Mohan Kumar mo...@in.ibm.com
[Qemu-devel] [PATCH-V2 24/24] virtio-9p: Fix formatting issues in v9fs_wstat_post_chown()
Signed-off-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
---
hw/virtio-9p.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 1621dab..e278cc1 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -2822,15 +2822,15 @@ static void v9fs_wstat_post_chown(V9fsState *s,
V9fsWstatState *vs, int err)
}
if (vs-v9stat.name.size != 0) {
- V9fsRenameState *vr;
+V9fsRenameState *vr;
vr = qemu_mallocz(sizeof(V9fsRenameState));
- vr-newdirfid = -1;
- vr-pdu = vs-pdu;
- vr-fidp = vs-fidp;
- vr-offset = vs-offset;
- vr-name.size = vs-v9stat.name.size;
- vr-name.data = qemu_strdup(vs-v9stat.name.data);
+vr-newdirfid = -1;
+vr-pdu = vs-pdu;
+vr-fidp = vs-fidp;
+vr-offset = vs-offset;
+vr-name.size = vs-v9stat.name.size;
+vr-name.data = qemu_strdup(vs-v9stat.name.data);
err = v9fs_complete_rename(s, vr);
qemu_free(vr);
--
1.6.5.2
[Qemu-devel] [PATCH-V2 05/24] virtio-9p: Compute iounit based on host filesystem block size
From: M. Mohan Kumar mo...@in.ibm.com
Compute iounit based on the host filesystem block size and pass it to
client with open/create response. Also return iounit as statfs's f_bsize
for optimal block size transfers.
Signed-off-by: M. Mohan Kumar mo...@in.ibm.com
Reviewd-by: Sripathi Kodi sripat...@in.ibm.com
Signed-off-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
---
hw/virtio-9p.c | 96 +---
hw/virtio-9p.h |9 +
2 files changed, 86 insertions(+), 19 deletions(-)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 2918194..00527c4 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -253,6 +253,11 @@ static int v9fs_do_fsync(V9fsState *s, int fd)
return s-ops-fsync(s-ctx, fd);
}
+static int v9fs_do_statfs(V9fsState *s, V9fsString *path, struct statfs *stbuf)
+{
+return s-ops-statfs(s-ctx, path-data, stbuf);
+}
+
static void v9fs_string_init(V9fsString *str)
{
str-data = NULL;
@@ -1019,11 +1024,10 @@ static void v9fs_fix_path(V9fsString *dst, V9fsString
*src, int len)
static void v9fs_version(V9fsState *s, V9fsPDU *pdu)
{
-int32_t msize;
V9fsString version;
size_t offset = 7;
-pdu_unmarshal(pdu, offset, ds, msize, version);
+pdu_unmarshal(pdu, offset, ds, s-msize, version);
if (!strcmp(version.data, 9P2000.u)) {
s-proto_version = V9FS_PROTO_2000U;
@@ -1033,7 +1037,7 @@ static void v9fs_version(V9fsState *s, V9fsPDU *pdu)
v9fs_string_sprintf(version, unknown);
}
-offset += pdu_marshal(pdu, offset, ds, msize, version);
+offset += pdu_marshal(pdu, offset, ds, s-msize, version);
complete_pdu(s, pdu, offset);
v9fs_string_free(version);
@@ -1288,6 +1292,26 @@ out:
v9fs_walk_complete(s, vs, err);
}
+static int32_t get_iounit(V9fsState *s, V9fsString *name)
+{
+struct statfs stbuf;
+int32_t iounit = 0;
+
+/*
+ * iounit should be multiples of f_bsize (host filesystem block size
+ * and as well as less than (client msize - P9_IOHDRSZ))
+ */
+if (!v9fs_do_statfs(s, name, stbuf)) {
+iounit = stbuf.f_bsize;
+iounit *= (s-msize - P9_IOHDRSZ)/stbuf.f_bsize;
+}
+
+if (!iounit) {
+iounit = s-msize - P9_IOHDRSZ;
+}
+return iounit;
+}
+
static void v9fs_open_post_opendir(V9fsState *s, V9fsOpenState *vs, int err)
{
if (vs-fidp-dir == NULL) {
@@ -1303,6 +1327,15 @@ out:
}
+static void v9fs_open_post_getiounit(V9fsState *s, V9fsOpenState *vs)
+{
+int err;
+vs-offset += pdu_marshal(vs-pdu, vs-offset, Qd, vs-qid, vs-iounit);
+err = vs-offset;
+complete_pdu(s, vs-pdu, err);
+qemu_free(vs);
+}
+
static void v9fs_open_post_open(V9fsState *s, V9fsOpenState *vs, int err)
{
if (vs-fidp-fd == -1) {
@@ -1310,8 +1343,9 @@ static void v9fs_open_post_open(V9fsState *s,
V9fsOpenState *vs, int err)
goto out;
}
-vs-offset += pdu_marshal(vs-pdu, vs-offset, Qd, vs-qid, 0);
-err = vs-offset;
+vs-iounit = get_iounit(s, vs-fidp-path);
+v9fs_open_post_getiounit(s, vs);
+return;
out:
complete_pdu(s, vs-pdu, err);
qemu_free(vs);
@@ -1794,15 +1828,28 @@ out:
qemu_free(vs);
}
-static void v9fs_post_create(V9fsState *s, V9fsCreateState *vs, int err)
+static void v9fs_create_post_getiounit(V9fsState *s, V9fsCreateState *vs)
{
-if (err == 0) {
-v9fs_string_copy(vs-fidp-path, vs-fullname);
-stat_to_qid(vs-stbuf, vs-qid);
+int err;
+v9fs_string_copy(vs-fidp-path, vs-fullname);
+stat_to_qid(vs-stbuf, vs-qid);
-vs-offset += pdu_marshal(vs-pdu, vs-offset, Qd, vs-qid, 0);
+vs-offset += pdu_marshal(vs-pdu, vs-offset, Qd, vs-qid, vs-iounit);
+err = vs-offset;
-err = vs-offset;
+complete_pdu(s, vs-pdu, err);
+v9fs_string_free(vs-name);
+v9fs_string_free(vs-extension);
+v9fs_string_free(vs-fullname);
+qemu_free(vs);
+}
+
+static void v9fs_post_create(V9fsState *s, V9fsCreateState *vs, int err)
+{
+if (err == 0) {
+vs-iounit = get_iounit(s, vs-fidp-path);
+v9fs_create_post_getiounit(s, vs);
+return;
}
complete_pdu(s, vs-pdu, err);
@@ -2267,23 +2314,34 @@ out:
qemu_free(vs);
}
-static int v9fs_do_statfs(V9fsState *s, V9fsString *path, struct statfs *stbuf)
-{
-return s-ops-statfs(s-ctx, path-data, stbuf);
-}
-
static void v9fs_statfs_post_statfs(V9fsState *s, V9fsStatfsState *vs, int err)
{
+int32_t bsize_factor;
+
if (err) {
err = -errno;
goto out;
}
+/*
+ * compute bsize factor based on host file system block size
+ * and client msize
+ */
+bsize_factor = (s-msize - P9_IOHDRSZ)/vs-stbuf.f_bsize;
+if (!bsize_factor) {
+bsize_factor = 1;
+}
vs-v9statfs.f_type = vs-stbuf.f_type;
vs-v9statfs.f_bsize = vs-stbuf.f_bsize;
-vs-v9statfs.f_blocks = vs-stbuf.f_blocks;
-vs-v9statfs.f_bfree = vs-stbuf.f_bfree;
-
[Qemu-devel] [PATCH-V2 13/24] qemu: virtio-9p: Implement TMKNOD
From: M. Mohan Kumar mo...@in.ibm.com
Implement TMKNOD as part of 2000.L Work
Synopsis
size[4] Tmknod tag[2] fid[4] name[s] mode[4] major[4] minor[4] gid[4]
size[4] Rmknod tag[2] qid[13]
Description
mknod asks the file server to create a device node with given device
type, mode and gid. The qid for the new device node is returned with
the mknod reply message.
Signed-off-by: M. Mohan Kumar mo...@in.ibm.com
Signed-off-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
---
hw/virtio-9p-debug.c | 13 +++
hw/virtio-9p.c | 90 ++
hw/virtio-9p.h | 11 ++
3 files changed, 107 insertions(+), 7 deletions(-)
diff --git a/hw/virtio-9p-debug.c b/hw/virtio-9p-debug.c
index a8abdd2..6a527ce 100644
--- a/hw/virtio-9p-debug.c
+++ b/hw/virtio-9p-debug.c
@@ -488,6 +488,19 @@ void pprint_pdu(V9fsPDU *pdu)
pprint_qid(pdu, 1, offset, qid);
pprint_int32(pdu, 1, offset, , iounit);
break;
+case P9_TMKNOD:
+ fprintf(llogfile, TMKNOD: ();
+pprint_int32(pdu, 0, offset, fid);
+pprint_str(pdu, 0, offset, name);
+pprint_int32(pdu, 0, offset, mode);
+pprint_int32(pdu, 0, offset, major);
+pprint_int32(pdu, 0, offset, minor);
+pprint_int32(pdu, 0, offset, gid);
+break;
+case P9_RMKNOD:
+fprintf(llogfile, RMKNOD: ));
+pprint_qid(pdu, 0, offset, qid);
+break;
case P9_TREAD:
fprintf(llogfile, TREAD: ();
pprint_int32(pdu, 0, offset, fid);
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 3944548..24adaec 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -160,15 +160,16 @@ static int v9fs_do_chmod(V9fsState *s, V9fsString *path,
mode_t mode)
return s-ops-chmod(s-ctx, path-data, cred);
}
-static int v9fs_do_mknod(V9fsState *s, V9fsCreateState *vs, mode_t mode,
-dev_t dev)
+static int v9fs_do_mknod(V9fsState *s, char *name,
+mode_t mode, dev_t dev, uid_t uid, gid_t gid)
{
FsCred cred;
cred_init(cred);
-cred.fc_uid = vs-fidp-uid;
+cred.fc_uid = uid;
+cred.fc_gid = gid;
cred.fc_mode = mode;
cred.fc_rdev = dev;
-return s-ops-mknod(s-ctx, vs-fullname.data, cred);
+return s-ops-mknod(s-ctx, name, cred);
}
static int v9fs_do_mkdir(V9fsState *s, V9fsCreateState *vs)
@@ -2332,13 +2333,16 @@ static void v9fs_create_post_lstat(V9fsState *s,
V9fsCreateState *vs, int err)
}
nmode |= vs-perm 0777;
-err = v9fs_do_mknod(s, vs, nmode, makedev(major, minor));
+err = v9fs_do_mknod(s, vs-fullname.data, nmode,
+makedev(major, minor), vs-fidp-uid, -1);
v9fs_create_post_perms(s, vs, err);
} else if (vs-perm P9_STAT_MODE_NAMED_PIPE) {
-err = v9fs_do_mknod(s, vs, S_IFIFO | (vs-perm 0777), 0);
+err = v9fs_do_mknod(s, vs-fullname.data, S_IFIFO | (vs-perm 0777),
+0, vs-fidp-uid, -1);
v9fs_post_create(s, vs, err);
} else if (vs-perm P9_STAT_MODE_SOCKET) {
-err = v9fs_do_mknod(s, vs, S_IFSOCK | (vs-perm 0777), 0);
+err = v9fs_do_mknod(s, vs-fullname.data, S_IFSOCK | (vs-perm 0777),
+0, vs-fidp-uid, -1);
v9fs_post_create(s, vs, err);
} else {
vs-fidp-fd = v9fs_do_open2(s, vs-fullname.data, vs-fidp-uid,
@@ -2850,6 +2854,77 @@ out:
qemu_free(vs);
}
+static void v9fs_mknod_post_lstat(V9fsState *s, V9fsMkState *vs, int err)
+{
+if (err == -1) {
+err = -errno;
+goto out;
+}
+
+stat_to_qid(vs-stbuf, vs-qid);
+vs-offset += pdu_marshal(vs-pdu, vs-offset, Q, vs-qid);
+err = vs-offset;
+out:
+complete_pdu(s, vs-pdu, err);
+v9fs_string_free(vs-fullname);
+v9fs_string_free(vs-name);
+qemu_free(vs);
+}
+
+static void v9fs_mknod_post_mknod(V9fsState *s, V9fsMkState *vs, int err)
+{
+if (err == -1) {
+err = -errno;
+goto out;
+}
+
+err = v9fs_do_lstat(s, vs-fullname, vs-stbuf);
+v9fs_mknod_post_lstat(s, vs, err);
+return;
+out:
+complete_pdu(s, vs-pdu, err);
+v9fs_string_free(vs-fullname);
+v9fs_string_free(vs-name);
+qemu_free(vs);
+}
+
+static void v9fs_mknod(V9fsState *s, V9fsPDU *pdu)
+{
+int32_t fid;
+V9fsMkState *vs;
+int err = 0;
+V9fsFidState *fidp;
+gid_t gid;
+int mode;
+int major, minor;
+
+vs = qemu_malloc(sizeof(*vs));
+vs-pdu = pdu;
+vs-offset = 7;
+
+v9fs_string_init(vs-fullname);
+pdu_unmarshal(vs-pdu, vs-offset, ds, fid, vs-name, mode,
+major, minor, gid);
+
+fidp = lookup_fid(s, fid);
+if (fidp == NULL) {
+err = -ENOENT;
+goto out;
+}
+
+v9fs_string_sprintf(vs-fullname, %s/%s, fidp-path.data,
vs-name.data);
+err = v9fs_do_mknod(s, vs-fullname.data, mode, makedev(major, minor),
+fidp-uid, gid);
+v9fs_mknod_post_mknod(s, vs, err);
+return;
+
+out:
+
[Qemu-devel] [PATCH-V2 08/24] [virtio-9p] Make v9fs_do_utimensat accept timespec structures instead of v9stat.
From: Sripathi Kodi sripat...@in.ibm.com
Currently v9fs_do_utimensat takes a V9fsStat argument and builds
timespec structures. It sets tv_nsec values to 0 by default. Instead
of this it should take struct timespec[2] and pass it down to the
system directly. This will make it more generic and useful
elsewhere.
Signed-off-by: Sripathi Kodi sripat...@in.ibm.com
Signed-off-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
---
hw/virtio-9p.c | 37 ++---
1 files changed, 18 insertions(+), 19 deletions(-)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index bb59c0c..e4754b8 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -237,25 +237,10 @@ static int v9fs_do_chown(V9fsState *s, V9fsString *path,
uid_t uid, gid_t gid)
return s-ops-chown(s-ctx, path-data, cred);
}
-static int v9fs_do_utimensat(V9fsState *s, V9fsString *path, V9fsStat v9stat)
+static int v9fs_do_utimensat(V9fsState *s, V9fsString *path,
+ const struct timespec times[2])
{
-struct timespec ts[2];
-
-if (v9stat.atime != -1) {
-ts[0].tv_sec = v9stat.atime;
-ts[0].tv_nsec = 0;
-} else {
-ts[0].tv_nsec = UTIME_OMIT;
-}
-
-if (v9stat.mtime != -1) {
-ts[1].tv_sec = v9stat.mtime;
-ts[1].tv_nsec = 0;
-} else {
-ts[1].tv_nsec = UTIME_OMIT;
-}
-
-return s-ops-utimensat(s-ctx, path-data, ts);
+return s-ops-utimensat(s-ctx, path-data, times);
}
static int v9fs_do_remove(V9fsState *s, V9fsString *path)
@@ -2342,7 +2327,21 @@ static void v9fs_wstat_post_chmod(V9fsState *s,
V9fsWstatState *vs, int err)
}
if (vs-v9stat.mtime != -1 || vs-v9stat.atime != -1) {
-if (v9fs_do_utimensat(s, vs-fidp-path, vs-v9stat)) {
+struct timespec times[2];
+if (vs-v9stat.atime != -1) {
+times[0].tv_sec = vs-v9stat.atime;
+times[0].tv_nsec = 0;
+} else {
+times[0].tv_nsec = UTIME_OMIT;
+}
+if (vs-v9stat.mtime != -1) {
+times[1].tv_sec = vs-v9stat.mtime;
+times[1].tv_nsec = 0;
+} else {
+times[1].tv_nsec = UTIME_OMIT;
+}
+
+if (v9fs_do_utimensat(s, vs-fidp-path, times)) {
err = -errno;
}
}
--
1.6.5.2
[Qemu-devel] [PATCH-V2 20/24] virtio-9p: Hide user.virtfs xattr in case of mapped security.
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
With mapped security mode we use user.virtfs namespace is used
to store the virtFs related attributes. So hide it from user.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Signed-off-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
---
hw/virtio-9p-local.c | 75 --
1 files changed, 72 insertions(+), 3 deletions(-)
diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
index 3944cf3..87ff953 100644
--- a/hw/virtio-9p-local.c
+++ b/hw/virtio-9p-local.c
@@ -480,18 +480,87 @@ static int local_statfs(FsContext *s, const char *path,
struct statfs *stbuf)
static ssize_t local_lgetxattr(FsContext *ctx, const char *path,
const char *name, void *value, size_t size)
{
+if ((ctx-fs_sm == SM_MAPPED)
+(strncmp(name, user.virtfs., 12) == 0)) {
+/*
+ * Don't allow fetch of user.virtfs namesapce
+ * in case of mapped security
+ */
+errno = ENOATTR;
+return -1;
+}
+
return lgetxattr(rpath(ctx, path), name, value, size);
}
static ssize_t local_llistxattr(FsContext *ctx, const char *path,
void *value, size_t size)
{
-return llistxattr(rpath(ctx, path), value, size);
+ssize_t retval;
+ssize_t actual_len = 0;
+char *orig_value, *orig_value_start;
+char *temp_value, *temp_value_start;
+ssize_t xattr_len, parsed_len = 0, attr_len;
+
+if (ctx-fs_sm != SM_MAPPED) {
+return llistxattr(rpath(ctx, path), value, size);
+}
+
+/* Get the actual len */
+xattr_len = llistxattr(rpath(ctx, path), value, 0);
+
+/* Now fetch the xattr and find the actual size */
+orig_value = qemu_malloc(xattr_len);
+xattr_len = llistxattr(rpath(ctx, path), orig_value, xattr_len);
+
+/*
+ * For mapped security model drop user.virtfs namespace
+ * from the list
+ */
+temp_value = qemu_mallocz(xattr_len);
+temp_value_start = temp_value;
+orig_value_start = orig_value;
+while (xattr_len parsed_len) {
+attr_len = strlen(orig_value) + 1;
+if (strncmp(orig_value, user.virtfs., 12) != 0) {
+/* Copy this entry */
+strcat(temp_value, orig_value);
+temp_value += attr_len;
+actual_len += attr_len;
+}
+parsed_len += attr_len;
+orig_value += attr_len;
+}
+if (!size) {
+retval = actual_len;
+goto out;
+} else if (size = actual_len) {
+/* now copy the parsed attribute list back */
+memset(value, 0, size);
+memcpy(value, temp_value_start, actual_len);
+retval = actual_len;
+goto out;
+}
+errno = ERANGE;
+retval = -1;
+out:
+qemu_free(orig_value_start);
+qemu_free(temp_value_start);
+return retval;
}
static int local_lsetxattr(FsContext *ctx, const char *path, const char *name,
- void *value, size_t size, int flags)
-{
+ void *value, size_t size, int flags)
+{
+if ((ctx-fs_sm == SM_MAPPED)
+(strncmp(name, user.virtfs., 12) == 0)) {
+/*
+ * Don't allow fetch of user.virtfs namesapce
+ * in case of mapped security
+ */
+errno = EACCES;
+return -1;
+}
return lsetxattr(rpath(ctx, path), name, value, size, flags);
}
--
1.6.5.2
[Qemu-devel] [PATCH-V2 04/24] [V4] virtio-9p: readdir implementation for 9p2000.L
From: Sripathi Kodi sripat...@in.ibm.com
This patch implements the server part of readdir() implementation for
9p2000.L
SYNOPSIS
size[4] Treaddir tag[2] fid[4] offset[8] count[4]
size[4] Rreaddir tag[2] count[4] data[count]
DESCRIPTION
The readdir request asks the server to read the directory specified by 'fid'
at an offset specified by 'offset' and return as many dirent structures as
possible that fit into count bytes. Each dirent structure is laid out as
follows.
qid.type[1]
the type of the file (directory, etc.), represented as a bit
vector corresponding to the high 8 bits of the file's mode
word.
qid.vers[4]
version number for given path
qid.path[8]
the file server's unique identification for the file
offset[8]
offset into the next dirent.
type[1]
type of this directory entry.
name[256]
name of this directory entry.
Signed-off-by: Sripathi Kodi sripat...@in.ibm.com
Reviewed-by: M. Mohan Kumar mo...@in.ibm.com
Signed-off-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
---
hw/virtio-9p-debug.c | 13 +
hw/virtio-9p.c | 122 ++
hw/virtio-9p.h |2 +
3 files changed, 137 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-9p-debug.c b/hw/virtio-9p-debug.c
index c1b0e6f..240bec8 100644
--- a/hw/virtio-9p-debug.c
+++ b/hw/virtio-9p-debug.c
@@ -330,6 +330,19 @@ void pprint_pdu(V9fsPDU *pdu)
BUG_ON(!llogfile);
switch (pdu-id) {
+case P9_TREADDIR:
+fprintf(llogfile, TREADDIR: ();
+pprint_int32(pdu, 0, offset, fid);
+pprint_int64(pdu, 0, offset, , initial offset);
+pprint_int32(pdu, 0, offset, , max count);
+break;
+case P9_RREADDIR:
+fprintf(llogfile, RREADDIR: ();
+pprint_int32(pdu, 1, offset, count);
+#ifdef DEBUG_DATA
+pprint_data(pdu, 1, offset, , data);
+#endif
+break;
case P9_TVERSION:
fprintf(llogfile, TVERSION: ();
pprint_int32(pdu, 0, offset, msize);
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 0540a74..2918194 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -1577,6 +1577,127 @@ out:
qemu_free(vs);
}
+typedef struct V9fsReadDirState {
+V9fsPDU *pdu;
+V9fsFidState *fidp;
+V9fsQID qid;
+off_t saved_dir_pos;
+struct dirent *dent;
+int32_t count;
+int32_t max_count;
+size_t offset;
+int64_t initial_offset;
+V9fsString name;
+} V9fsReadDirState;
+
+static void v9fs_readdir_post_seekdir(V9fsState *s, V9fsReadDirState *vs)
+{
+vs-offset += pdu_marshal(vs-pdu, vs-offset, d, vs-count);
+vs-offset += vs-count;
+complete_pdu(s, vs-pdu, vs-offset);
+qemu_free(vs);
+return;
+}
+
+/* Size of each dirent on the wire: size of qid (13) + size of offset (8)
+ * size of type (1) + size of name.size (2) + strlen(name.data)
+ */
+#define V9_READDIR_DATA_SZ (24 + strlen(vs-name.data))
+
+static void v9fs_readdir_post_readdir(V9fsState *s, V9fsReadDirState *vs)
+{
+int len;
+size_t size;
+
+if (vs-dent) {
+v9fs_string_init(vs-name);
+v9fs_string_sprintf(vs-name, %s, vs-dent-d_name);
+
+if ((vs-count + V9_READDIR_DATA_SZ) vs-max_count) {
+/* Ran out of buffer. Set dir back to old position and return */
+v9fs_do_seekdir(s, vs-fidp-dir, vs-saved_dir_pos);
+v9fs_readdir_post_seekdir(s, vs);
+return;
+}
+
+/* Fill up just the path field of qid because the client uses
+ * only that. To fill the entire qid structure we will have
+ * to stat each dirent found, which is expensive
+ */
+size = MIN(sizeof(vs-dent-d_ino), sizeof(vs-qid.path));
+memcpy(vs-qid.path, vs-dent-d_ino, size);
+/* Fill the other fields with dummy values */
+vs-qid.type = 0;
+vs-qid.version = 0;
+
+len = pdu_marshal(vs-pdu, vs-offset+4+vs-count, Qqbs,
+ vs-qid, vs-dent-d_off,
+ vs-dent-d_type, vs-name);
+vs-count += len;
+v9fs_string_free(vs-name);
+vs-saved_dir_pos = vs-dent-d_off;
+vs-dent = v9fs_do_readdir(s, vs-fidp-dir);
+v9fs_readdir_post_readdir(s, vs);
+return;
+}
+
+vs-offset += pdu_marshal(vs-pdu, vs-offset, d, vs-count);
+vs-offset += vs-count;
+complete_pdu(s, vs-pdu, vs-offset);
+qemu_free(vs);
+return;
+}
+
+static void v9fs_readdir_post_telldir(V9fsState *s, V9fsReadDirState *vs)
+{
+vs-dent = v9fs_do_readdir(s, vs-fidp-dir);
+v9fs_readdir_post_readdir(s, vs);
+return;
+}
+
+static void v9fs_readdir_post_setdir(V9fsState *s, V9fsReadDirState *vs)
+{
+vs-saved_dir_pos = v9fs_do_telldir(s, vs-fidp-dir);
+v9fs_readdir_post_telldir(s, vs);
+
[Qemu-devel] [PATCH-V2 16/24] qemu: virtio-9p: Implement LOPEN
From: M. Mohan Kumar mo...@in.ibm.com
Implement 9p2000.L version of open(LOPEN) interface in qemu 9p server.
For LOPEN, no need to convert the flags to and from 9p mode to VFS mode.
Synopsis:
size[4] Tlopen tag[2] fid[4] mode[4]
size[4] Rlopen tag[2] qid[13] iounit[4]
Current qemu 9p server does not support following flags:
O_NOCTTY, O_NONBLOCK, O_ASYNC O_CLOEXEC
Signed-off-by: M. Mohan Kumar mo...@in.ibm.com
Signed-off-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
---
hw/virtio-9p.c | 24 ++--
hw/virtio-9p.h |2 ++
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 4594f48..b4badc1 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -1621,8 +1621,19 @@ out:
qemu_free(vs);
}
+static inline int valid_flags(int flag)
+{
+if (flag O_NOCTTY || flag O_NONBLOCK || flag O_ASYNC ||
+flag O_CLOEXEC)
+return 0;
+else
+return 1;
+}
+
static void v9fs_open_post_lstat(V9fsState *s, V9fsOpenState *vs, int err)
{
+int flags;
+
if (err) {
err = -errno;
goto out;
@@ -1634,8 +1645,16 @@ static void v9fs_open_post_lstat(V9fsState *s,
V9fsOpenState *vs, int err)
vs-fidp-dir = v9fs_do_opendir(s, vs-fidp-path);
v9fs_open_post_opendir(s, vs, err);
} else {
-vs-fidp-fd = v9fs_do_open(s, vs-fidp-path,
-omode_to_uflags(vs-mode));
+if (s-proto_version == V9FS_PROTO_2000L) {
+if (!valid_flags(vs-mode)) {
+err = -EINVAL;
+goto out;
+}
+flags = vs-mode;
+} else {
+flags = omode_to_uflags(vs-mode);
+}
+vs-fidp-fd = v9fs_do_open(s, vs-fidp-path, flags);
v9fs_open_post_open(s, vs, err);
}
return;
@@ -3076,6 +3095,7 @@ static pdu_handler_t *pdu_handlers[] = {
[P9_TRENAME] = v9fs_rename,
[P9_TMKDIR] = v9fs_mkdir,
[P9_TVERSION] = v9fs_version,
+[P9_TLOPEN] = v9fs_open,
[P9_TATTACH] = v9fs_attach,
[P9_TSTAT] = v9fs_stat,
[P9_TWALK] = v9fs_walk,
diff --git a/hw/virtio-9p.h b/hw/virtio-9p.h
index 4d179b7..542d0bf 100644
--- a/hw/virtio-9p.h
+++ b/hw/virtio-9p.h
@@ -15,6 +15,8 @@
enum {
P9_TSTATFS = 8,
P9_RSTATFS,
+P9_TLOPEN = 12,
+P9_RLOPEN,
P9_TLCREATE = 14,
P9_RLCREATE,
P9_TSYMLINK = 16,
--
1.6.5.2
[Qemu-devel] [PATCH-V2 15/24] rename - change name of file or directory
From: M. Mohan Kumar mo...@in.ibm.com
size[4] Trename tag[2] fid[4] newdirfid[4] name[s]
size[4] Rrename tag[2]
Implement the 2000.L rename operation. A new function
v9fs_complete_rename is introduced that acts as a common entry point
for 2000.L rename operation and 2000.U rename opearation (via wstat).
As part of this change the field 'nname' (used only for rename) is
removed from the structure V9fsWstatState. Instead a new structure
V9fsRenameState is used for rename operations both by 2000.U and 2000.L
code paths. Both 2000.U and 2000.L rename code paths construct the
V9fsRenameState structure and passes that to v9fs_complete_rename
function.
Changes from previous version:
Use qemu_mallocz to initialize
Use strcpy,strcat functions instead of memcpy
Changed the variable name to newdirfid
Introduced post rename function
Error checking
Removed nname field from V9fsWstatState
Signed-off-by: M. Mohan Kumar mo...@in.ibm.com
Signed-off-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
---
hw/virtio-9p.c | 157
hw/virtio-9p.h | 11 -
2 files changed, 123 insertions(+), 45 deletions(-)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index c853eca..4594f48 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -2563,11 +2563,6 @@ static void v9fs_wstat_post_rename(V9fsState *s,
V9fsWstatState *vs, int err)
if (err 0) {
goto out;
}
-
-if (vs-v9stat.name.size != 0) {
-v9fs_string_free(vs-nname);
-}
-
if (vs-v9stat.length != -1) {
if (v9fs_do_truncate(s, vs-fidp-path, vs-v9stat.length) 0) {
err = -errno;
@@ -2582,17 +2577,30 @@ out:
qemu_free(vs);
}
-static void v9fs_wstat_post_chown(V9fsState *s, V9fsWstatState *vs, int err)
+static int v9fs_complete_rename(V9fsState *s, V9fsRenameState *vs)
{
-V9fsFidState *fidp;
-if (err 0) {
-goto out;
-}
+int err = 0;
+char *old_name, *new_name;
+char *end;
-if (vs-v9stat.name.size != 0) {
-char *old_name, *new_name;
-char *end;
+if (vs-newdirfid != -1) {
+V9fsFidState *dirfidp;
+dirfidp = lookup_fid(s, vs-newdirfid);
+
+if (dirfidp == NULL) {
+err = -ENOENT;
+goto out;
+}
+
+BUG_ON(dirfidp-fd != -1);
+BUG_ON(dirfidp-dir);
+new_name = qemu_mallocz(dirfidp-path.size + vs-name.size + 2);
+
+strcpy(new_name, dirfidp-path.data);
+strcat(new_name, /);
+strcat(new_name + dirfidp-path.size, vs-name.data);
+} else {
old_name = vs-fidp-path.data;
end = strrchr(old_name, '/');
if (end) {
@@ -2600,44 +2608,75 @@ static void v9fs_wstat_post_chown(V9fsState *s,
V9fsWstatState *vs, int err)
} else {
end = old_name;
}
+new_name = qemu_mallocz(end - old_name + vs-name.size + 1);
-new_name = qemu_malloc(end - old_name + vs-v9stat.name.size + 1);
+strncat(new_name, old_name, end - old_name);
+strncat(new_name + (end - old_name), vs-name.data, vs-name.size);
+}
-memset(new_name, 0, end - old_name + vs-v9stat.name.size + 1);
-memcpy(new_name, old_name, end - old_name);
-memcpy(new_name + (end - old_name), vs-v9stat.name.data,
-vs-v9stat.name.size);
-vs-nname.data = new_name;
-vs-nname.size = strlen(new_name);
+v9fs_string_free(vs-name);
+vs-name.data = qemu_strdup(new_name);
+vs-name.size = strlen(new_name);
-if (strcmp(new_name, vs-fidp-path.data) != 0) {
-if (v9fs_do_rename(s, vs-fidp-path, vs-nname)) {
-err = -errno;
-} else {
-/*
- * Fixup fid's pointing to the old name to
- * start pointing to the new name
- */
-for (fidp = s-fid_list; fidp; fidp = fidp-next) {
-
-if (vs-fidp == fidp) {
-/*
- * we replace name of this fid towards the end
- * so that our below strcmp will work
- */
-continue;
-}
-if (!strncmp(vs-fidp-path.data, fidp-path.data,
- strlen(vs-fidp-path.data))) {
-/* replace the name */
-v9fs_fix_path(fidp-path, vs-nname,
- strlen(vs-fidp-path.data));
-}
+if (strcmp(new_name, vs-fidp-path.data) != 0) {
+if (v9fs_do_rename(s, vs-fidp-path, vs-name)) {
+err = -errno;
+} else {
+V9fsFidState *fidp;
+/*
+* Fixup fid's pointing to the old name to
+* start pointing to the new name
+*/
+for (fidp = s-fid_list; fidp; fidp = fidp-next) {
+if (vs-fidp == fidp)
[Qemu-devel] [PATCH-V2 22/24] virtio-9p: Use lchown which won't follow symlink
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
We should always use functions which don't follow
symlink on the server
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Signed-off-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
---
hw/virtio-9p-local.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
index 67f12ad..3aaf4b7 100644
--- a/hw/virtio-9p-local.c
+++ b/hw/virtio-9p-local.c
@@ -101,7 +101,7 @@ static int local_post_create_passthrough(FsContext *fs_ctx,
const char *path,
if (chmod(rpath(fs_ctx, path), credp-fc_mode 0) 0) {
return -1;
}
-if (chown(rpath(fs_ctx, path), credp-fc_uid, credp-fc_gid) 0) {
+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
--
1.6.5.2
[Qemu-devel] FW: Qemu crashes
Can any one help me in that please. Hi! I am trying to run asa 802, asdm 602 with gns3. After long struggle i managed to fixed every thing. But now when i run asdm the Qemu crashes. The reference is on this post - http://www.gns3.net/phpBB/topic2349.html Thanks for any kind of help. Regards,
Re: [Qemu-devel] Release of COREMU, a scalable and portable full-system emulator
Am 21.07.2010 09:03, schrieb Chen Yufei: On 2010-7-21, at 上午5:43, Blue Swirl wrote: On Sat, Jul 17, 2010 at 10:27 AM, Chen Yufeicyfde...@gmail.com wrote: We are pleased to announce COREMU, which is a multicore-on-multicore full-system emulator built on Qemu. (Simply speaking, we made Qemu parallel.) The project web page is located at: http://ppi.fudan.edu.cn/coremu You can also download the source code, images for playing on sourceforge http://sf.net/p/coremu COREMU is composed of 1. a parallel emulation library 2. a set of patches to qemu (We worked on the master branch, commit 54d7cf136f040713095cbc064f62d753bff6f9d2) It currently supports full-system emulation of x64 and ARM MPcore platforms. By leveraging the underlying multicore resources, it can emulate up to 255 cores running commodity operating systems (even on a 4-core machine). Enjoy, Nice work. Do you plan to submit the improvements back to upstream QEMU? It would be great if we can submit our code to QEMU, but we do not know the process. Would you please give us some instructions? -- Best regards, Chen Yufei Some hints can be found here: http://wiki.qemu.org/Contribute/StartHere Kind regards, Stefan Weil
Re: [Qemu-devel] FW: Qemu crashes
Hi, It seems to be a modified version of QEMU. If it is the case you must contact the modifier or test with an unmodified version. If it is not, you must provide more detailed information, like, exact qemu version, command line, and extended fail information as given by Windows. If possible, you must provide also the same guest OS image you're using. Regards, Natalia Portillo El 21/07/2010, a las 17:06, capricorn 80 escribió: Can any one help me in that please. Hi! I am trying to run asa 802, asdm 602 with gns3. After long struggle i managed to fixed every thing. But now when i run asdm the Qemu crashes. The reference is on this post - http://www.gns3.net/phpBB/topic2349.html Thanks for any kind of help. Regards,
[Qemu-devel] Re: [PATCH v3 2/2] monitor: Convert 'info qdm' to QMP
On Mon, 19 Jul 2010 13:51:27 -0300
Miguel Di Ciurcio Filho miguel.fi...@gmail.com wrote:
Converts the 'info qdm' command to QMP, allowing the discovery of all devices
known to the QEMU binary without relying on command line paramaters like
-device ? and -device devtype,?
This change does not modify the output of the 'info qdm' monitor command.
Signed-off-by: Miguel Di Ciurcio Filho miguel.fi...@gmail.com
---
hw/qdev.c | 110 +++-
hw/qdev.h |3 +-
monitor.c |3 +-
3 files changed, 112 insertions(+), 4 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
index e99c73f..d24d42a 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -29,6 +29,7 @@
#include qdev.h
#include sysemu.h
#include monitor.h
+#include qjson.h
static int qdev_hotplug = 0;
@@ -779,13 +780,118 @@ void do_info_qtree(Monitor *mon)
qbus_print(mon, main_system_bus, 0);
}
-void do_info_qdm(Monitor *mon)
+static void qdm_list_iter(QObject *obj, void *opaque)
+{
+
+Monitor *mon = opaque;
+QDict *dev = qobject_to_qdict(obj);
+
+monitor_printf(mon, name \%s\, bus %s, qdict_get_str(dev, name),
+qdict_get_str(dev, bus));
+
+if (qdict_haskey(dev, alias)) {
+monitor_printf(mon, , alias \%s\, qdict_get_str(dev, alias));
+}
+
+if (qdict_haskey(dev, description)) {
+monitor_printf(mon, , desc \%s\, qdict_get_str(dev,
description));
+}
+
+if (!qdict_get_bool(dev, creatable)) {
+monitor_printf(mon, , no-user);
+}
+
+monitor_printf(mon, \n);
+}
+
+void do_info_qdm_print(Monitor *mon, const QObject *ret_data)
+{
+QList *devs;
+
+devs = qobject_to_qlist(ret_data);
+qlist_iter(devs, qdm_list_iter, mon);
+}
+
+static const char *qdev_property_type_to_string(int type)
+{
+switch (type) {
+case PROP_TYPE_UINT8:
+case PROP_TYPE_UINT16:
+case PROP_TYPE_UINT32:
+case PROP_TYPE_INT32:
+case PROP_TYPE_UINT64:
+return integer;
+case PROP_TYPE_TADDR:
+case PROP_TYPE_MACADDR:
+case PROP_TYPE_DRIVE:
+case PROP_TYPE_CHR:
+case PROP_TYPE_STRING:
+case PROP_TYPE_NETDEV:
+return string;
+case PROP_TYPE_BIT:
+ return boolean;
+case PROP_TYPE_UNSPEC:
+case PROP_TYPE_VLAN:
+case PROP_TYPE_PTR:
+return NULL;
Shouldn't you just drop UNSPEC, VLAN and PRT?
+}
+
+return NULL;
+}
+
+void do_info_qdm(Monitor *mon, QObject **ret_data)
{
DeviceInfo *info;
+QList *devs = qlist_new();
for (info = device_info_list; info != NULL; info = info-next) {
-qdev_print_devinfo(info);
+QObject *obj;
+QDict *dev;
+QList *props = qlist_new();
+Property *prop;
+
+for (prop = info-props; prop prop-name; prop++) {
+QObject *entry;
+/*
+ * TODO: skip old and hackish stuff, they will be removed some
day.
+ */
+if (!prop-info-parse || prop-info-type == PROP_TYPE_VLAN
+|| prop-info-type == PROP_TYPE_PTR
+|| prop-info-type == PROP_TYPE_UNSPEC) {
+continue;
+}
+
+const char *type =
qdev_property_type_to_string(prop-info-type);
Variable definitions should be on the top and that function can return
NULL. You should put an assert() here if that's impossible to happen,
otherwise qdev_property_type_to_string() should return unknown and that
should be documented.
I think the assert() is fine.
+
+entry = qobject_from_jsonf({ 'name': %s, 'type': %s },
+ prop-name, type);
+
+qlist_append_obj(props, entry);
+}
+
+obj = qobject_from_jsonf({ 'name': %s, 'bus': %s, 'creatable': %i
},
+ info-name,
+ info-bus_info-name,
+ info-no_user ? 0 : 1);
+
+dev = qobject_to_qdict(obj);
+
+if (!qlist_empty(props)) {
+qdict_put(dev, properties, props);
+}
We'll leak 'props' when it's empty.
+
+if (info-alias) {
+qdict_put(dev, alias, qstring_from_str(info-alias));
+}
+
+if (info-desc) {
+qdict_put(dev, description, qstring_from_str(info-desc));
+}
+
+qlist_append(devs, dev);
}
+
+*ret_data = QOBJECT(devs);
}
int do_device_add(Monitor *mon, const QDict *qdict, QObject **ret_data)
diff --git a/hw/qdev.h b/hw/qdev.h
index 678f8b7..3b0382b 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -184,7 +184,8 @@ void qbus_free(BusState *bus);
/*** monitor commands ***/
void do_info_qtree(Monitor *mon);
-void do_info_qdm(Monitor *mon);
+void do_info_qdm_print(Monitor *mon, const QObject *ret_data);
+void do_info_qdm(Monitor *mon, QObject **ret_data);
int do_device_add(Monitor *mon, const QDict
[Qemu-devel] Re: [PATCH v3 2/2] monitor: Convert 'info qdm' to QMP
On Wed, Jul 21, 2010 at 02:42:28PM -0300, Luiz Capitulino wrote:
On Mon, 19 Jul 2010 13:51:27 -0300
Miguel Di Ciurcio Filho miguel.fi...@gmail.com wrote:
Converts the 'info qdm' command to QMP, allowing the discovery of all
devices
known to the QEMU binary without relying on command line paramaters like
-device ? and -device devtype,?
This change does not modify the output of the 'info qdm' monitor command.
Signed-off-by: Miguel Di Ciurcio Filho miguel.fi...@gmail.com
diff --git a/monitor.c b/monitor.c
index 45fd482..66810f2 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2565,7 +2565,8 @@ static const mon_cmd_t info_cmds[] = {
.args_type = ,
.params = ,
.help = show qdev device model list,
-.mhandler.info = do_info_qdm,
+.user_print = do_info_qdm_print,
+.mhandler.info_new = do_info_qdm,
Haven't we agreed on calling this query-available-devices or something
like that?
That's getting rather verbose for a name ! How about just
'query-dev-types' (anticipating future query-netdev-types,
query-chardev-types, commands etc, too)
Daniel
--
|: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org-o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Re: [Qemu-devel] virtio-9p is not working
On Wed, Jul 21, 2010 at 2:27 AM, Dallas Lee mswpl...@gmail.com wrote: Hi, I have trying to use the virtio-9p for my linux in QEMU, but without success. Here is my option for booting my qemu: i386-softmmu/qemu -kernel bzImage -append console=ttyS0 video=uvesafb:ywrap,overlay:rgb16,480x800...@60 root=/dev/nfs rw nfsroot=10.0.2.2:/root,udp ip=10.0.2.16:eth0:none 5 -net nic,model=virtio -net user -soundhw all -usb -serial telnet:localhost:1200,server -vga std -m 512 -L ./pc-bios -bios bios.bin -virtfs local,path=/home/dallas/nfs,security_model=passthrough,mount_tag=v_tmp The virtio network is working, I could mount the nfs through virio net. And in the guest linux, I tried to mount v9fs by using following command: mount -t 9p -o trans=virtio -o debug=0x v_tmp /mnt but unfortunately I got the error: mount: mounting v_tmp on /mnt failed: No such device And I can't find the v_tmp neither in /sys/devices/virtio-pci/virtio1/ nor in /sys/bus/virtio/drivers/9pnet_virtio/virtio1/ And before building the kernel, I enabled the Plan 9 Ressource Sharing Support under File System/Network File System, I also enabled the following configures: PARAVIRT_GUEST: - Processor type and features - Paravirtualized guest support LGUEST_GUEST: - Processor type and features - Paravirtualized guest support - Lguest guest support VIRTIO_PCI: - Virtualization (VIRTUALIZATION [=y]) - PCI driver for virtio devices VIRTIO_BLK: - Device Drivers - Block devices (BLK_DEV [=y]) - Virtio block driver VIRTIO_NET: - Device Drivers - Network device support (NETDEVICES [=y]) - Virtio network driver Would you please help me to find out the problem why I couldn't mount the v9fs? Thank you very much! BR, Dallas Hi Dallas, what does 'lspci -vv' in the guest show? Is there a device for virtio_9p? do you have CONFIG_NET_9P_VIRTIO=y in your kernel's .config? Cam
[Qemu-devel] Re: [PATCH v3 2/2] monitor: Convert 'info qdm' to QMP
On Wed, 21 Jul 2010 18:51:19 +0100
Daniel P. Berrange berra...@redhat.com wrote:
On Wed, Jul 21, 2010 at 02:42:28PM -0300, Luiz Capitulino wrote:
On Mon, 19 Jul 2010 13:51:27 -0300
Miguel Di Ciurcio Filho miguel.fi...@gmail.com wrote:
Converts the 'info qdm' command to QMP, allowing the discovery of all
devices
known to the QEMU binary without relying on command line paramaters like
-device ? and -device devtype,?
This change does not modify the output of the 'info qdm' monitor command.
Signed-off-by: Miguel Di Ciurcio Filho miguel.fi...@gmail.com
diff --git a/monitor.c b/monitor.c
index 45fd482..66810f2 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2565,7 +2565,8 @@ static const mon_cmd_t info_cmds[] = {
.args_type = ,
.params = ,
.help = show qdev device model list,
-.mhandler.info = do_info_qdm,
+.user_print = do_info_qdm_print,
+.mhandler.info_new = do_info_qdm,
Haven't we agreed on calling this query-available-devices or something
like that?
That's getting rather verbose for a name ! How about just
'query-dev-types' (anticipating future query-netdev-types,
query-chardev-types, commands etc, too)
I don't mind long names in the protocol, but I'm ok with your suggestion.
[Qemu-devel] Re: [PATCH v3 2/2] monitor: Convert 'info qdm' to QMP
On 07/21/2010 12:51 PM, Daniel P. Berrange wrote:
On Wed, Jul 21, 2010 at 02:42:28PM -0300, Luiz Capitulino wrote:
On Mon, 19 Jul 2010 13:51:27 -0300
Miguel Di Ciurcio Filhomiguel.fi...@gmail.com wrote:
Converts the 'info qdm' command to QMP, allowing the discovery of all devices
known to the QEMU binary without relying on command line paramaters like
-device ? and -device devtype,?
This change does not modify the output of the 'info qdm' monitor command.
Signed-off-by: Miguel Di Ciurcio Filhomiguel.fi...@gmail.com
diff --git a/monitor.c b/monitor.c
index 45fd482..66810f2 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2565,7 +2565,8 @@ static const mon_cmd_t info_cmds[] = {
.args_type = ,
.params = ,
.help = show qdev device model list,
-.mhandler.info = do_info_qdm,
+.user_print = do_info_qdm_print,
+.mhandler.info_new = do_info_qdm,
Haven't we agreed on calling this query-available-devices or something
like that?
That's getting rather verbose for a name ! How about just
'query-dev-types' (anticipating future query-netdev-types,
query-chardev-types, commands etc, too)
I know we're still trying to recover from the great bit shortage of '09
but I think we can afford to spare some here to make the names readable :-)
Good names are part of good documentation. If it's not entirely obvious
what the function does from it's name, it's probably a bad name (in the
context of a wire protocol).
Regards,
Anthony Liguori
Daniel
Re: [Qemu-devel] [PATCH] Monitor: Convert do_sendkey() to QObject, QError
On Sun, 18 Jul 2010 15:43:55 +0300
Michael Goldish mgold...@redhat.com wrote:
Signed-off-by: Michael Goldish mgold...@redhat.com
Do you need this for 0.13? I think the development window is already closed.
---
monitor.c | 15 ---
qemu-monitor.hx | 22 +-
qerror.c| 12
qerror.h|9 +
4 files changed, 50 insertions(+), 8 deletions(-)
diff --git a/monitor.c b/monitor.c
index d5377de..082c29d 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1614,7 +1614,7 @@ static void release_keys(void *opaque)
}
}
-static void do_sendkey(Monitor *mon, const QDict *qdict)
+static int do_sendkey(Monitor *mon, const QDict *qdict, QObject **ret_data)
{
char keyname_buf[16];
char *separator;
@@ -1636,18 +1636,18 @@ static void do_sendkey(Monitor *mon, const QDict
*qdict)
if (keyname_len 0) {
pstrcpy(keyname_buf, sizeof(keyname_buf), string);
if (keyname_len sizeof(keyname_buf) - 1) {
-monitor_printf(mon, invalid key: '%s...'\n, keyname_buf);
-return;
+qerror_report(QERR_INVALID_KEY, keyname_buf);
+return -1;
}
if (i == MAX_KEYCODES) {
-monitor_printf(mon, too many keys\n);
-return;
+qerror_report(QERR_TOO_MANY_KEYS);
+return -1;
}
keyname_buf[keyname_len] = 0;
keycode = get_keycode(keyname_buf);
if (keycode 0) {
-monitor_printf(mon, unknown key: '%s'\n, keyname_buf);
-return;
+qerror_report(QERR_UNKNOWN_KEY, keyname_buf);
+return -1;
}
keycodes[i++] = keycode;
}
@@ -1666,6 +1666,7 @@ static void do_sendkey(Monitor *mon, const QDict *qdict)
/* delayed key up events */
qemu_mod_timer(key_timer, qemu_get_clock(vm_clock) +
muldiv64(get_ticks_per_sec(), hold_time, 1000));
+return 0;
}
static int mouse_button_state;
diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index f7e46c4..8b6cf09 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -532,7 +532,8 @@ ETEXI
.args_type = string:s,hold_time:i?,
.params = keys [hold_ms],
.help = send keys to the VM (e.g. 'sendkey ctrl-alt-f1',
default hold time=100 ms),
-.mhandler.cmd = do_sendkey,
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = do_sendkey,
},
STEXI
@@ -549,6 +550,25 @@ sendkey ctrl-alt-f1
This command is useful to send keys that your graphical user interface
intercepts at low level, such as @code{ctrl-alt-f1} in X Window.
ETEXI
+SQMP
+sendkey
+---
+
+Send keys to the emulator.
+
+Arguments:
+
+- string: key names or key codes in hexadecimal format separated by dashes
(json-string)
This is leaking bad stuff from the user monitor into QMP.
I think we should have a keys key, which accepts an array of keys. Strings
are key names, integers are key codes. Unfortunately, key codes will have to
be specified in decimal.
Example:
{ execute: sendkey, arguments: { keys: [foo, 10, bar, 15] } }
However, in order to maintain the current user monitor behavior, you will
have to add a new args_type so that you can move the current parsing out
of the handler to the user monitor parser. Then you'll have to change the
handler to work with an array.
A bit of work.
Another related issue is that, this probably should an async handler. But
as we don't have the proper infrastructure yet, I'm ok with having this in
its current form.
+- hold_time: duration in milliseconds to hold the keys down (json-int,
optional, default=100)
+
+Example:
+
+- { execute: sendkey, arguments: { string: ctrl-alt-f1 } }
+- { return: {} }
+
+Note: if several keys are given they are pressed simultaneously.
+
+EQMP
{
.name = system_reset,
diff --git a/qerror.c b/qerror.c
index 44d0bf8..34a698e 100644
--- a/qerror.c
+++ b/qerror.c
Please, split this into two patches: the errors first, then the conversion.
That helps reviewing and reverting.
@@ -117,6 +117,10 @@ static const QErrorStringTable qerror_table[] = {
.desc = Invalid block format '%(name)',
},
{
+.error_fmt = QERR_INVALID_KEY,
+.desc = Invalid key '%(key)...',
+},
+{
.error_fmt = QERR_INVALID_PARAMETER,
.desc = Invalid parameter '%(name)',
},
@@ -185,10 +189,18 @@ static const QErrorStringTable qerror_table[] = {
.desc = Too many open files,
},
{
+.error_fmt = QERR_TOO_MANY_KEYS,
+.desc = Too many keys,
+},
+{
.error_fmt = QERR_UNDEFINED_ERROR,
.desc = An undefined error has ocurred,
},
{
+
Re: [Qemu-devel] [PATCH] Monitor: Convert do_sendkey() to QObject, QError
On Wed, Jul 21, 2010 at 03:44:14PM -0300, Luiz Capitulino wrote:
On Sun, 18 Jul 2010 15:43:55 +0300
Michael Goldish mgold...@redhat.com wrote:
Signed-off-by: Michael Goldish mgold...@redhat.com
Do you need this for 0.13? I think the development window is already closed.
---
monitor.c | 15 ---
qemu-monitor.hx | 22 +-
qerror.c| 12
qerror.h|9 +
4 files changed, 50 insertions(+), 8 deletions(-)
diff --git a/monitor.c b/monitor.c
index d5377de..082c29d 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1614,7 +1614,7 @@ static void release_keys(void *opaque)
}
}
-static void do_sendkey(Monitor *mon, const QDict *qdict)
+static int do_sendkey(Monitor *mon, const QDict *qdict, QObject **ret_data)
{
char keyname_buf[16];
char *separator;
@@ -1636,18 +1636,18 @@ static void do_sendkey(Monitor *mon, const QDict
*qdict)
if (keyname_len 0) {
pstrcpy(keyname_buf, sizeof(keyname_buf), string);
if (keyname_len sizeof(keyname_buf) - 1) {
-monitor_printf(mon, invalid key: '%s...'\n, keyname_buf);
-return;
+qerror_report(QERR_INVALID_KEY, keyname_buf);
+return -1;
}
if (i == MAX_KEYCODES) {
-monitor_printf(mon, too many keys\n);
-return;
+qerror_report(QERR_TOO_MANY_KEYS);
+return -1;
}
keyname_buf[keyname_len] = 0;
keycode = get_keycode(keyname_buf);
if (keycode 0) {
-monitor_printf(mon, unknown key: '%s'\n, keyname_buf);
-return;
+qerror_report(QERR_UNKNOWN_KEY, keyname_buf);
+return -1;
}
keycodes[i++] = keycode;
}
@@ -1666,6 +1666,7 @@ static void do_sendkey(Monitor *mon, const QDict
*qdict)
/* delayed key up events */
qemu_mod_timer(key_timer, qemu_get_clock(vm_clock) +
muldiv64(get_ticks_per_sec(), hold_time, 1000));
+return 0;
}
static int mouse_button_state;
diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index f7e46c4..8b6cf09 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -532,7 +532,8 @@ ETEXI
.args_type = string:s,hold_time:i?,
.params = keys [hold_ms],
.help = send keys to the VM (e.g. 'sendkey ctrl-alt-f1',
default hold time=100 ms),
-.mhandler.cmd = do_sendkey,
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = do_sendkey,
},
STEXI
@@ -549,6 +550,25 @@ sendkey ctrl-alt-f1
This command is useful to send keys that your graphical user interface
intercepts at low level, such as @code{ctrl-alt-f1} in X Window.
ETEXI
+SQMP
+sendkey
+---
+
+Send keys to the emulator.
+
+Arguments:
+
+- string: key names or key codes in hexadecimal format separated by
dashes (json-string)
This is leaking bad stuff from the user monitor into QMP.
I think we should have a keys key, which accepts an array of keys. Strings
are key names, integers are key codes. Unfortunately, key codes will have to
be specified in decimal.
I can see why keynames are nice in the text monitor, but is there a need
for JSON mode to accept keynames too ? If we're focusing on providing a
machine protocol, then keycodes seem like they sufficient to me. Apps can
using the command can provide symbol constants for the keycodes, or string
if actually needed by their end users
Example:
{ execute: sendkey, arguments: { keys: [foo, 10, bar, 15] } }
However, in order to maintain the current user monitor behavior, you will
have to add a new args_type so that you can move the current parsing out
of the handler to the user monitor parser. Then you'll have to change the
handler to work with an array.
A bit of work.
Another related issue is that, this probably should an async handler. But
as we don't have the proper infrastructure yet, I'm ok with having this in
its current form.
+- hold_time: duration in milliseconds to hold the keys down (json-int,
optional, default=100)
Having 'hold-time' which applies to the full list of keys is limiting
the flexibility of apps. eg, it means you can only do
down ctrl
down alt
down f1
wait 100ms
up ctrl
up alt
up f1
Again I can see why the impl works this way currently, because it is
clearly a nicer option for humans. For a machine protocol though it
seems sub-optimal. What if app needed more flexibility over ordering
of press+release events eg to release in a different order
down ctrl
down alt
down f1
wait 100ms
up f1
up ctrl
up alt
Should we just follow VNC and explicitly have a up/down flag in
the protocol let
Re: [Qemu-devel] virtio-9p is not working
Cam Macdonell wrote: On Wed, Jul 21, 2010 at 2:27 AM, Dallas Lee mswpl...@gmail.com wrote: Hi, I have trying to use the virtio-9p for my linux in QEMU, but without success. Here is my option for booting my qemu: i386-softmmu/qemu -kernel bzImage -append console=ttyS0 video=uvesafb:ywrap,overlay:rgb16,480x800...@60 root=/dev/nfs rw nfsroot=10.0.2.2:/root,udp ip=10.0.2.16:eth0:none 5 -net nic,model=virtio -net user -soundhw all -usb -serial telnet:localhost:1200,server -vga std -m 512 -L ./pc-bios -bios bios.bin -virtfs local,path=/home/dallas/nfs,security_model=passthrough,mount_tag=v_tmp The virtio network is working, I could mount the nfs through virio net. And in the guest linux, I tried to mount v9fs by using following command: mount -t 9p -o trans=virtio -o debug=0x v_tmp /mnt but unfortunately I got the error: mount: mounting v_tmp on /mnt failed: No such device And I can't find the v_tmp neither in /sys/devices/virtio-pci/virtio1/ nor in /sys/bus/virtio/drivers/9pnet_virtio/virtio1/ And before building the kernel, I enabled the Plan 9 Ressource Sharing Support under File System/Network File System, I also enabled the following configures: PARAVIRT_GUEST: - Processor type and features - Paravirtualized guest support LGUEST_GUEST: - Processor type and features - Paravirtualized guest support - Lguest guest support VIRTIO_PCI: - Virtualization (VIRTUALIZATION [=y]) - PCI driver for virtio devices VIRTIO_BLK: - Device Drivers - Block devices (BLK_DEV [=y]) - Virtio block driver VIRTIO_NET: - Device Drivers - Network device support (NETDEVICES [=y]) - Virtio network driver Would you please help me to find out the problem why I couldn't mount the v9fs? Thank you very much! BR, Dallas Hi Dallas, what does 'lspci -vv' in the guest show? Is there a device for virtio_9p? do you have CONFIG_NET_9P_VIRTIO=y in your kernel's .config? Can you please check if /proc/filesystems has 9P in it? Check if you have '9' in any of the following files cat /sys/devices/virtio-pci/virtio*/device Also in that directory you will have a mount_tag file. If any of the above are missing, please make sure that you have following options enabled in the guest kernel config. CONFIG_NET_9P=y CONFIG_NET_9P_VIRTIO=y CONFIG_NET_9P_DEBUG=y CONFIG_9P_FS=y Thanks, JV Cam
[Qemu-devel] [PATCH] block: Use error codes from lower levels for error message
No such file or directory is a misleading error message
when a user tries to open a file with wrong permissions.
v2: return an 0/-errno int and pass the BlockDriver* by reference
as suggested by Kevin Wolf
Cc: Kevin Wolf kw...@redhat.com
Signed-off-by: Stefan Weil w...@mail.berlios.de
---
block.c | 27 +++
1 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/block.c b/block.c
index b133b70..b49abf2 100644
--- a/block.c
+++ b/block.c
@@ -330,7 +330,7 @@ BlockDriver *bdrv_find_protocol(const char *filename)
return NULL;
}
-static BlockDriver *find_image_format(const char *filename)
+static int find_image_format(const char *filename, BlockDriver **pdrv)
{
int ret, score, score_max;
BlockDriver *drv1, *drv;
@@ -338,19 +338,27 @@ static BlockDriver *find_image_format(const char
*filename)
BlockDriverState *bs;
ret = bdrv_file_open(bs, filename, 0);
-if (ret 0)
-return NULL;
+if (ret 0) {
+*pdrv = NULL;
+return ret;
+}
/* Return the raw BlockDriver * to scsi-generic devices or empty drives */
if (bs-sg || !bdrv_is_inserted(bs)) {
bdrv_delete(bs);
-return bdrv_find_format(raw);
+drv = bdrv_find_format(raw);
+if (!drv) {
+ret = -ENOENT;
+}
+*pdrv = drv;
+return ret;
}
ret = bdrv_pread(bs, 0, buf, sizeof(buf));
bdrv_delete(bs);
if (ret 0) {
-return NULL;
+*pdrv = NULL;
+return ret;
}
score_max = 0;
@@ -364,7 +372,11 @@ static BlockDriver *find_image_format(const char *filename)
}
}
}
-return drv;
+if (!drv) {
+ret = -ENOENT;
+}
+*pdrv = drv;
+return ret;
}
/**
@@ -571,12 +583,11 @@ int bdrv_open(BlockDriverState *bs, const char *filename,
int flags,
/* Find the right image format driver */
if (!drv) {
-drv = find_image_format(filename);
+ret = find_image_format(filename, drv);
probed = 1;
}
if (!drv) {
-ret = -ENOENT;
goto unlink_and_fail;
}
--
1.7.1
[Qemu-devel] [PATCH 1/3] remove dead code from hw/loader.c
Removing dead code. Above we already continued when
rom-addr + valuegreaterthan0 addr so this condition is always false.
Signed-off-by: Joel Schopp jsch...@austin.ibm.com
---
hw/loader.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/hw/loader.c b/hw/loader.c
index 79a6f95..49ac1fa 100644
--- a/hw/loader.c
+++ b/hw/loader.c
@@ -733,11 +733,6 @@ int rom_copy(uint8_t *dest, target_phys_addr_t addr,
size_t size)
s = rom-data;
l = rom-romsize;
-if (rom-addr addr) {
-d = dest;
-s += (addr - rom-addr);
-l -= (addr - rom-addr);
-}
if ((d + l) (dest + size)) {
l = dest - d;
}
--
1.7.0.4
[Qemu-devel] [PATCH 2/3] fix variable type in qemu-io.c
The variable len can get a negative return value from cvtnum,
which we check for, but which is impossible with the current
unsigned variable type. Currently the if(len 0) check is
pointless. This patch fixes that.
Signed-off-by: Joel Schopp jsch...@austin.ibm.com
---
qemu-io.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/qemu-io.c b/qemu-io.c
index 9adda4c..1a9c13d 100644
--- a/qemu-io.c
+++ b/qemu-io.c
@@ -135,7 +135,7 @@ create_iovec(QEMUIOVector *qiov, char **argv, int nr_iov,
int pattern)
for (i = 0; i nr_iov; i++) {
char *arg = argv[i];
-uint64_t len;
+int64_t len;
len = cvtnum(arg);
if (len 0) {
@@ -144,7 +144,7 @@ create_iovec(QEMUIOVector *qiov, char **argv, int nr_iov,
int pattern)
}
/* should be SIZE_T_MAX, but that doesn't exist */
- if (len UINT_MAX) {
+ if (len INT_MAX) {
printf(too large length argument -- %s\n, arg);
goto fail;
}
--
1.7.0.4
[Qemu-devel] [PATCH 3/3] remove pointless if from vl.c
We already set sockets to nonzero in the code above.
So this if statement always evaluates true. Remove it.
Signed-off-by: Joel Schopp jsch...@austin.ibm.com
---
vl.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/vl.c b/vl.c
index 8a5de9f..a0c28b6 100644
--- a/vl.c
+++ b/vl.c
@@ -801,9 +801,7 @@ static void smp_parse(const char *optarg)
threads = threads 0 ? threads : 1;
cores = smp / (sockets * threads);
} else {
-if (sockets) {
-threads = smp / (cores * sockets);
-}
+threads = smp / (cores * sockets);
}
}
smp_cpus = smp;
--
1.7.0.4
[Qemu-devel] [PATCH 0/3] Fix broken if statements
I have decided to apply the broken window theory of crime http://en.wikipedia.org/wiki/Broken_windows_theory to code, and more specifically to qemu. I'm hoping that fixing seemingly trivial bugs will actually fix some more serious bugs, make the code run just a bit smoother, or at the very least leave us with easier to maintain code. Joel Schopp (3): remove dead code from hw/loader.c fix variable type in qemu-io.c remove pointless if from vl.c hw/loader.c |5 - qemu-io.c |4 ++-- vl.c|4 +--- 3 files changed, 3 insertions(+), 10 deletions(-)
[Qemu-devel] Qemu latest version for window
Hi! Can i get latest version of qemu for windows ? Regards,
Re: [Qemu-devel] [PATCH] Monitor: Convert do_sendkey() to QObject, QError
On 07/21/2010 09:44 PM, Luiz Capitulino wrote:
On Sun, 18 Jul 2010 15:43:55 +0300
Michael Goldish mgold...@redhat.com wrote:
Signed-off-by: Michael Goldish mgold...@redhat.com
Do you need this for 0.13? I think the development window is already closed.
No, it's not urgent.
---
monitor.c | 15 ---
qemu-monitor.hx | 22 +-
qerror.c| 12
qerror.h|9 +
4 files changed, 50 insertions(+), 8 deletions(-)
diff --git a/monitor.c b/monitor.c
index d5377de..082c29d 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1614,7 +1614,7 @@ static void release_keys(void *opaque)
}
}
-static void do_sendkey(Monitor *mon, const QDict *qdict)
+static int do_sendkey(Monitor *mon, const QDict *qdict, QObject **ret_data)
{
char keyname_buf[16];
char *separator;
@@ -1636,18 +1636,18 @@ static void do_sendkey(Monitor *mon, const QDict
*qdict)
if (keyname_len 0) {
pstrcpy(keyname_buf, sizeof(keyname_buf), string);
if (keyname_len sizeof(keyname_buf) - 1) {
-monitor_printf(mon, invalid key: '%s...'\n, keyname_buf);
-return;
+qerror_report(QERR_INVALID_KEY, keyname_buf);
+return -1;
}
if (i == MAX_KEYCODES) {
-monitor_printf(mon, too many keys\n);
-return;
+qerror_report(QERR_TOO_MANY_KEYS);
+return -1;
}
keyname_buf[keyname_len] = 0;
keycode = get_keycode(keyname_buf);
if (keycode 0) {
-monitor_printf(mon, unknown key: '%s'\n, keyname_buf);
-return;
+qerror_report(QERR_UNKNOWN_KEY, keyname_buf);
+return -1;
}
keycodes[i++] = keycode;
}
@@ -1666,6 +1666,7 @@ static void do_sendkey(Monitor *mon, const QDict
*qdict)
/* delayed key up events */
qemu_mod_timer(key_timer, qemu_get_clock(vm_clock) +
muldiv64(get_ticks_per_sec(), hold_time, 1000));
+return 0;
}
static int mouse_button_state;
diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index f7e46c4..8b6cf09 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -532,7 +532,8 @@ ETEXI
.args_type = string:s,hold_time:i?,
.params = keys [hold_ms],
.help = send keys to the VM (e.g. 'sendkey ctrl-alt-f1',
default hold time=100 ms),
-.mhandler.cmd = do_sendkey,
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = do_sendkey,
},
STEXI
@@ -549,6 +550,25 @@ sendkey ctrl-alt-f1
This command is useful to send keys that your graphical user interface
intercepts at low level, such as @code{ctrl-alt-f1} in X Window.
ETEXI
+SQMP
+sendkey
+---
+
+Send keys to the emulator.
+
+Arguments:
+
+- string: key names or key codes in hexadecimal format separated by
dashes (json-string)
This is leaking bad stuff from the user monitor into QMP.
I think we should have a keys key, which accepts an array of keys. Strings
are key names, integers are key codes. Unfortunately, key codes will have to
be specified in decimal.
Example:
{ execute: sendkey, arguments: { keys: [foo, 10, bar, 15] } }
However, in order to maintain the current user monitor behavior, you will
have to add a new args_type so that you can move the current parsing out
of the handler to the user monitor parser. Then you'll have to change the
handler to work with an array.
What do you mean by add a new args_type? Do you mean I should add a
new type 'a', similar to 's' and 'i', that represents a dash separated
string/int array? If so, I suppose obtaining the array in do_sendkey()
would involve something like
QList *keys = qdict_get_qlist(qdict, keys);
Is this correct? I'm just asking to be sure.
A bit of work.
Another related issue is that, this probably should an async handler. But
as we don't have the proper infrastructure yet, I'm ok with having this in
its current form.
What's an async handler? Feel free to point me to some documentation if
there is any.
+- hold_time: duration in milliseconds to hold the keys down (json-int,
optional, default=100)
+
+Example:
+
+- { execute: sendkey, arguments: { string: ctrl-alt-f1 } }
+- { return: {} }
+
+Note: if several keys are given they are pressed simultaneously.
+
+EQMP
{
.name = system_reset,
diff --git a/qerror.c b/qerror.c
index 44d0bf8..34a698e 100644
--- a/qerror.c
+++ b/qerror.c
Please, split this into two patches: the errors first, then the conversion.
That helps reviewing and reverting.
OK. Thanks for the comments.
@@ -117,6 +117,10 @@ static const QErrorStringTable qerror_table[] = {
.desc = Invalid block format '%(name)',
},
{
+.error_fmt
[Qemu-devel] [PATCH] move 'unsafe' to end of caching modes in help
Libvirt parses qemu help output to determine qemu features. In particular it probes for the following: cache=writethrough|writeback|none. The addition of the unsafe cache mode was inserted within this string, as opposed to being added to the end, which impacted libvirt's probe. Unbreak libvirt by keeping the existing cache modes intact and add unsafe to the end. This problem only manifests itself if a caching mode is explicitly specified in the libvirt xml, in which case older syntax for caching is passed to qemu, which it no longer understands. Signed-off-by: Bruce Rogers brog...@novell.com --- qemu-options.hx |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/qemu-options.hx b/qemu-options.hx index 0d7dd90..9ecc54e 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -118,7 +118,7 @@ ETEXI DEF(drive, HAS_ARG, QEMU_OPTION_drive, -drive [file=file][,if=type][,bus=n][,unit=m][,media=d][,index=i]\n [,cyls=c,heads=h,secs=s[,trans=t]][,snapshot=on|off]\n - [,cache=writethrough|writeback|unsafe|none][,format=f]\n + [,cache=writethrough|writeback|none|unsafe][,format=f]\n [,serial=s][,addr=A][,id=name][,aio=threads|native]\n [,readonly=on|off]\n use 'file' as a drive image\n, QEMU_ARCH_ALL) -- 1.6.2.4
Re: [Qemu-devel] [PATCH] move 'unsafe' to end of caching modes in help
On 07/21/2010 03:32 PM, Bruce Rogers wrote: Libvirt parses qemu help output to determine qemu features. In particular it probes for the following: cache=writethrough|writeback|none. The addition of the unsafe cache mode was inserted within this string, as opposed to being added to the end, which impacted libvirt's probe. Unbreak libvirt by keeping the existing cache modes intact and add unsafe to the end. This problem only manifests itself if a caching mode is explicitly specified in the libvirt xml, in which case older syntax for caching is passed to qemu, which it no longer understands. Signed-off-by: Bruce Rogersbrog...@novell.com Errr, libvirt is still doing this? This comes up frequently and it's a real PITA. Help text is not a feature probing interface. This is a libvirt bug and it needs to be fixed in libvirt. Regards, Anthony Liguori --- qemu-options.hx |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/qemu-options.hx b/qemu-options.hx index 0d7dd90..9ecc54e 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -118,7 +118,7 @@ ETEXI DEF(drive, HAS_ARG, QEMU_OPTION_drive, -drive [file=file][,if=type][,bus=n][,unit=m][,media=d][,index=i]\n [,cyls=c,heads=h,secs=s[,trans=t]][,snapshot=on|off]\n - [,cache=writethrough|writeback|unsafe|none][,format=f]\n + [,cache=writethrough|writeback|none|unsafe][,format=f]\n [,serial=s][,addr=A][,id=name][,aio=threads|native]\n [,readonly=on|off]\n use 'file' as a drive image\n, QEMU_ARCH_ALL)
Re: [Qemu-devel] [PATCH] move 'unsafe' to end of caching modes in help
On Wed, Jul 21, 2010 at 03:55:28PM -0500, Anthony Liguori wrote: On 07/21/2010 03:32 PM, Bruce Rogers wrote: Libvirt parses qemu help output to determine qemu features. In particular it probes for the following: cache=writethrough|writeback|none. The addition of the unsafe cache mode was inserted within this string, as opposed to being added to the end, which impacted libvirt's probe. Unbreak libvirt by keeping the existing cache modes intact and add unsafe to the end. This problem only manifests itself if a caching mode is explicitly specified in the libvirt xml, in which case older syntax for caching is passed to qemu, which it no longer understands. Signed-off-by: Bruce Rogersbrog...@novell.com Errr, libvirt is still doing this? This comes up frequently and it's a real PITA. Help text is not a feature probing interface. This is a libvirt bug and it needs to be fixed in libvirt Of course, there is no viable alternative yet. The QMP patches I sent a few weeks back now to add ability to query capabilities were intended to provide the neccessary support in QEMU for us to use instead of -help. Given that QMP isn't going to be declared stable in 0.13 though, it looks like we'll be continuing to use -help until the 0.14 release of QEMU. Regards, Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Re: [Qemu-devel] [PATCH] move 'unsafe' to end of caching modes in help
On 07/21/2010 04:32 PM, Daniel P. Berrange wrote: On Wed, Jul 21, 2010 at 03:55:28PM -0500, Anthony Liguori wrote: On 07/21/2010 03:32 PM, Bruce Rogers wrote: Libvirt parses qemu help output to determine qemu features. In particular it probes for the following: cache=writethrough|writeback|none. The addition of the unsafe cache mode was inserted within this string, as opposed to being added to the end, which impacted libvirt's probe. Unbreak libvirt by keeping the existing cache modes intact and add unsafe to the end. This problem only manifests itself if a caching mode is explicitly specified in the libvirt xml, in which case older syntax for caching is passed to qemu, which it no longer understands. Signed-off-by: Bruce Rogersbrog...@novell.com Errr, libvirt is still doing this? This comes up frequently and it's a real PITA. Help text is not a feature probing interface. This is a libvirt bug and it needs to be fixed in libvirt Of course, there is no viable alternative yet. Yes there is. Use the version number. Regards, Anthony Liguori The QMP patches I sent a few weeks back now to add ability to query capabilities were intended to provide the neccessary support in QEMU for us to use instead of -help. Given that QMP isn't going to be declared stable in 0.13 though, it looks like we'll be continuing to use -help until the 0.14 release of QEMU. Regards, Daniel
Re: [Qemu-devel] [PATCH] move 'unsafe' to end of caching modes in help
On Wed, Jul 21, 2010 at 04:45:46PM -0500, Anthony Liguori wrote: On 07/21/2010 04:32 PM, Daniel P. Berrange wrote: On Wed, Jul 21, 2010 at 03:55:28PM -0500, Anthony Liguori wrote: On 07/21/2010 03:32 PM, Bruce Rogers wrote: Libvirt parses qemu help output to determine qemu features. In particular it probes for the following: cache=writethrough|writeback|none. The addition of the unsafe cache mode was inserted within this string, as opposed to being added to the end, which impacted libvirt's probe. Unbreak libvirt by keeping the existing cache modes intact and add unsafe to the end. This problem only manifests itself if a caching mode is explicitly specified in the libvirt xml, in which case older syntax for caching is passed to qemu, which it no longer understands. Signed-off-by: Bruce Rogersbrog...@novell.com Errr, libvirt is still doing this? This comes up frequently and it's a real PITA. Help text is not a feature probing interface. This is a libvirt bug and it needs to be fixed in libvirt Of course, there is no viable alternative yet. Yes there is. Use the version number. The version number is not suitable, because features can be removed at compile time and/or added via patch backports. The only reliable way is to query the QEMU binary to ask it what it actually supports. Regards, Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Re: [Qemu-devel] [PATCH] move 'unsafe' to end of caching modes in help
On 07/21/2010 04:58 PM, Daniel P. Berrange wrote: Yes there is. Use the version number. The version number is not suitable, because features can be removed at compile time and/or I don't see any features that libvirt would need to know about that are disabled at compile time that aren't disabled by platform features (i.e. being on a Linux vs. Windows host). added via patch backports. If a distro backports a feature, it should change the QEMU version string. If it doesn't, that's a distro problem. The only reliable way is to query the QEMU binary to ask it what it actually supports. And you do that by asking QEMU what it's version number is. If the version number isn't reliable because a distro backported features without changing it, then the distro is broken. It's no different than if we had a capabilities system and a distro added a feature without adjusting the advertises capabilities. Regards, Anthony Liguori Regards, Daniel
[Qemu-devel] [PATCH] Use existing config check when including eventfd.h
Signed-off-by: Mike McCormack mi...@ring3k.org --- hw/vhost.c |2 ++ hw/vhost_net.c |2 ++ 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/hw/vhost.c b/hw/vhost.c index d37a66e..e1cd4d2 100644 --- a/hw/vhost.c +++ b/hw/vhost.c @@ -11,7 +11,9 @@ */ #include sys/ioctl.h +#ifdef CONFIG_EVENTFD #include sys/eventfd.h +#endif #include vhost.h #include hw/hw.h /* For range_get_last */ diff --git a/hw/vhost_net.c b/hw/vhost_net.c index 606aa0c..f4bddd4 100644 --- a/hw/vhost_net.c +++ b/hw/vhost_net.c @@ -20,7 +20,9 @@ #ifdef CONFIG_VHOST_NET #include linux/vhost.h +#ifdef CONFIG_EVENTFD #include sys/eventfd.h +#endif #include sys/socket.h #include linux/kvm.h #include fcntl.h -- 1.5.6.5
Re: [Qemu-devel] [PATCH] move 'unsafe' to end of caching modes in help
Anthony Liguori wrote: On 07/21/2010 04:58 PM, Daniel P. Berrange wrote: Yes there is. Use the version number. The version number is not suitable, because features can be removed at compile time and/or I don't see any features that libvirt would need to know about that are disabled at compile time that aren't disabled by platform features (i.e. being on a Linux vs. Windows host). added via patch backports. If a distro backports a feature, it should change the QEMU version string. If it doesn't, that's a distro problem. To what version? It can't use the newer version if it only backports a subset of features; it would have to use a distro-specific version number or a version string that somehow encodes feature independent of the version number itself, by some agreed libvirt standard. Which isn't far off advertising features in the help string :-) -- Jamie
[Qemu-devel] [Bug 586175] Re: Windows XP/2003 doesn't boot
I agree to #10. Today I installed qemu-kvm-0.12.4-r3 and I still can't boot Windows XP/2003 without booting the install cd at first. But now: After I tried to boot the Windows installation I get the same odd char in the screen as described by #10. Plus, I can install Windows without problems, but it doesn't boot AFTER the setup, whether I use IDE or VirtIO as hard disk bus. Ergo: Booting from install cd, the setup copies the files on the hard disk, reboot, booting from hard disk, the setup installs Windows, reboot, and then: it hangs. Seems to be an BIOS issue. -- Windows XP/2003 doesn't boot https://bugs.launchpad.net/bugs/586175 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Incomplete Status in Debian GNU/Linux: New Status in Fedora: Unknown Bug description: Hello everyone, my qemu doesn't boot any Windows XP/2003 installations if I try to boot the image. If I boot the install cd first, it's boot manager counts down and triggers the boot on it's own. That's kinda stupid. I'm using libvirt, but even by a simple qemu-kvm -drive file=image.img,media=disk,if=ide,boot=on it won't boot. Qemu hangs at the message Booting from Hard Disk... I'm using qemu-kvm-0.12.4 with SeaBIOS 0.5.1 on Gentoo (No-Multilib and AMD64). It's a server, that means I'm using VNC as the primary graphic output but i don't think it should be an issue.
[Qemu-devel] [Bug 586175] Re: Windows XP/2003 doesn't boot
P.S.: Of course I can't boot Windows XP/2003 from a VirtIO drive at all, because the install cd only checks the IDE bus for an existing Windows installation... -- Windows XP/2003 doesn't boot https://bugs.launchpad.net/bugs/586175 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Incomplete Status in Debian GNU/Linux: New Status in Fedora: Unknown Bug description: Hello everyone, my qemu doesn't boot any Windows XP/2003 installations if I try to boot the image. If I boot the install cd first, it's boot manager counts down and triggers the boot on it's own. That's kinda stupid. I'm using libvirt, but even by a simple qemu-kvm -drive file=image.img,media=disk,if=ide,boot=on it won't boot. Qemu hangs at the message Booting from Hard Disk... I'm using qemu-kvm-0.12.4 with SeaBIOS 0.5.1 on Gentoo (No-Multilib and AMD64). It's a server, that means I'm using VNC as the primary graphic output but i don't think it should be an issue.
[Qemu-devel] [Bug 586420] Re: WinXP install cd hangs at boot time if machine started with floppy
Today I merged the new release qemu-kvm-0.12.4-r3 and, o, wonder, I can use floppy and cd at the same time! This bug seems to be fixed finally. thx for your support! -- WinXP install cd hangs at boot time if machine started with floppy https://bugs.launchpad.net/bugs/586420 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Incomplete Bug description: I have a second problem: I wanted to install Windows Server 2003 on a virtio drive, so I tried to start the machine with the install cd as the boot drive and a floppy image with the viostor drivers. The problem is, the install cd hangs at boot time. If I start VNC I just see a black ground with 640x480. I've also tried this with the install cd of Windows Server 2008 R2 and it works! Could it be that the BIOS screws up because the older install cds are using the floppy emulation to boot the setup?
[Qemu-devel] regs_to_env() ?
Hi, Function regs_to_env() in target-i386/exec.h has a code like below: ... #ifdef reg_EAX env-regs[R_EAX] = EAX #endif ... However, elsewhere we have EAX defined as: #define EAX (env-regs[R_EAX]) This means effectively, we have code like: env-regs[R_EAX] = env-regs[R_EAX]; What is the meaning of this code? That looks pointless to me, but I guess I must be wrong here... Thanks, Jun
Re: [Qemu-devel] [PATCH v3 0/4] pci: split out bridge code into pci_bridge and make it library
Ping?
On Tue, Jul 13, 2010 at 01:01:38PM +0900, Isaku Yamahata wrote:
Changes v2 - v1:
v3
- dropped first patch as it is merdged.
- rebased to mst's pci branch.
- eliminated pci_brdige_qdev_register(), pci_brdige_create(),
pci_brdige_create_simple() by exporting PCIBus and PCIBridge.
Patch description:
Now pci.c has grown. So split bridge related code into dedicated file
for further extension to pci bridge. Further clean up and pcie port emulator.
This make patch conflict less possible in future.
Clean up of pci host bus ans piix pci as discussed with v1
will be addressed after this patch set is accepted.
changes v1 - v2:
- introduce pci_internals.h to accomodate pci internal strcutures to
share between pci.c and pci_bridge.c
- don't make PCIBridge::bus pointer as suggested by
Michael S. Tsirkin m...@redhat.com
- rename PCIBridge::bus - PCIBridge::sec_bus
- eliminate pci_reguster_secondary_bus()/pci_unregister_secondary_bus()
- document pci bridge library functions.
- introduced pci bridge library.
Isaku Yamahata (4):
pci/bridge: split out pci bridge code into pci_bridge.c from pci.c
pci_bridge: rename PCIBridge::bus - PCIBridge::sec_bus.
pci_bridge: clean up: remove pci_{register,
unregister}_secondary_bus()
pci_bridge: introduce pci bridge library.
Makefile.objs |2 +-
hw/apb_pci.c | 56 +++---
hw/dec_pci.c | 46 +--
hw/pci.c | 177 +---
hw/pci.h |5 +-
hw/pci_bridge.c| 210
hw/pci_bridge.h| 62 +++
hw/pci_internals.h | 17 +++-
qemu-common.h |1 +
9 files changed, 369 insertions(+), 207 deletions(-)
create mode 100644 hw/pci_bridge.c
create mode 100644 hw/pci_bridge.h
--
yamahata
Re: [Qemu-devel] Qemu latest version for window
On Thu, Jul 22, 2010 at 03:29, capricorn 80 cool_capricor...@hotmail.com wrote: Hi! Can i get latest version of qemu for windows ? Yes, why not? -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
