Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On 25.03.2010, at 07:37, Avi Kivity wrote: On 03/24/2010 10:32 PM, Anthony Liguori wrote: So far, a libqemu.so with a flexible transport that could be used directly by a libvirt user (ala cairo/gdk type interactions) seems like the best solution to me. libqemu.so would be a C API. C is not the first choice for writing GUIs or management applications. So it would need to be further wrapped. We also need to allow qemu to control the display directly, without going through vnc. For the current functionality I tend to disagree. All that we need is an shm vnc extension that allows the GUI and qemu to not send image data over the wire, but only the dirtyness information. As soon as we get to 3D things might start to look different. Alex
[Qemu-devel] Re: [PATCH] update bochs vbe interface
On 03/24/10 23:28, Juan Quintela wrote: Humm, I think it means. Can you migrate from a new vga to an old one, and maintain it working? Depends on the vgabios version. vgabios 0.6c will not support vesa gfx modes on older qemu, no matter whenever you started fresh or migrated to it. -s-vbe_regs[VBE_DISPI_INDEX_ID] = VBE_DISPI_ID0; +s-vbe_regs[VBE_DISPI_INDEX_ID] = VBE_DISPI_ID5; +s-vbe_regs[VBE_DISPI_INDEX_VIDEO_MEMORY_64K] = s-vram_size / (64 * 1024); After migration, vbe_regs[VBE_DISPI_INDEX_ID] would have the value VBE_DISPI_ID5, but vbe_regs[VBE_DISPI_INDEX_VIDEO_MEMORY_64K] will have any random value, no? vgabios uses both once at init time. resetting vga will reset the vbe regs too. So when migrating from new to old qemu: Before reset vgabios will have the video memory size saved somewhere. After reset ID will reset to ID0, and in case you are running vgabios 0.6c vesa gfx modes will stop working. cheers, Gerd
Re: [Qemu-devel] Re: Compile files only once: some planning
On Wed, Mar 24, 2010 at 06:07:35PM -0500, Anthony Liguori wrote: On 03/24/2010 06:05 PM, Paul Brook wrote: On 03/24/2010 05:33 PM, Paul Brook wrote: But now there is a bigger problem, how to pass the property to the device. It's not fair to require the user to remember to set it. It should not be a property of the device. All devices have a native endianness (for PCI this is little-endian), and the intermediate busses/interconnects should determine whether byteswapping occurs. Right, the byte swapping needs to happen at the bus level which requires that the PCI regions use a different callback mechanism (and don't register directly with the cpu). Not necessarily a different callback mechanism, but probably a different registration mechanism. Problem with the current scheme is that it's tied to target_phys_addr_t. It's not a target_phys_addr_t and cannot be used with functions that take target_phys_addr_ts. We can either introduce a generic address type or we can introduce bus specific addresses and have different callbacks. The later has better type safety and since this isn't an obvious issue to most developers, that's probably an important feature. Regards, Anthony Liguori Paul I'd prefer a generic address type since this makes it easier to share code: for example virtio devices can use different busses, it's common for pci host bridges to have common code for i/o and memory, etc. -- MST
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On 24/03/10 21:40, Anthony Liguori wrote: If so, what C clients you expected beyond libvirt? Users want a C API. I don't agree that libvirt is the only C interface consumer out there. (I've seen this written too many times ...) How do you know that ? did you do a poll or something where *actual* users vote/tell ? From my point of view, i wouldn't want to write a high level management toolstack in C, specially since the API is well defined JSON which is easily available in all high level language out there. -- Vincent
[Qemu-devel] Re: [PATCH v2] update bochs vbe interface
/mnt/kvm/qemu/qemu-negotiate/hw/vga.c:2219: error: invalid operands to binary - (have ‘uint16_t (*)[10]’ and ‘uint16_t (*)[11]’) Huh? I was pretty sure I've compiled it, but obviously I didn't ... /me goes look for a brown paperbag. cheers, Gerd
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On 03/25/2010 10:26 AM, Vincent Hanquez wrote: On 24/03/10 21:40, Anthony Liguori wrote: If so, what C clients you expected beyond libvirt? Users want a C API. I don't agree that libvirt is the only C interface consumer out there. (I've seen this written too many times ...) How do you know that ? did you do a poll or something where *actual* users vote/tell ? From my point of view, i wouldn't want to write a high level management toolstack in C, specially since the API is well defined JSON which is easily available in all high level language out there. Strongly agreed. Even the managementy bits of qemu (anything around QObject) are suffering from the lowleveledness of C. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH] Fix 64-bit off_t syscall argument passing in linux-user
Hello,
I am evaluating the possibility to use linux-user emulation in qemu for
automatic regression testing for some embedded linux projects in the
company I work for. I've encountered some problems with syscall interface
while testing mips(el), powerpc and arm code, and I am willing to fix them.
This is the first patch, I'd appeciate any comments.
Best regards,
Tomasz Lukaszewski
In 32-bit ABIs 64-bit arguments are passed in a pair of registers
(ra, rb), where ra is an odd numbered one. This patch fixes such
case for truncate64, ftruncate64, pread64 and pwrite64 for mips,
ppc and arm-eabi.
---
linux-user/syscall.c | 64 -
1 files changed, 62 insertions(+), 2 deletions(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 80d8633..0bf146d 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -3922,6 +3922,7 @@ static inline abi_long target_truncate64(void *cpu_env,
const char *arg1,
abi_long arg3,
abi_long arg4)
{
+#if TARGET_ABI_BITS == 32
#ifdef TARGET_ARM
if (((CPUARMState *)cpu_env)-eabi)
{
@@ -3929,6 +3930,11 @@ static inline abi_long target_truncate64(void *cpu_env,
const char *arg1,
arg3 = arg4;
}
#endif
+#if defined TARGET_PPC || defined TARGET_MIPS
+arg2 = arg3;
+arg3 = arg4;
+#endif
+#endif
return get_errno(truncate64(arg1, target_offset64(arg2, arg3)));
}
#endif
@@ -3939,6 +3945,7 @@ static inline abi_long target_ftruncate64(void *cpu_env,
abi_long arg1,
abi_long arg3,
abi_long arg4)
{
+#if TARGET_ABI_BITS == 32
#ifdef TARGET_ARM
if (((CPUARMState *)cpu_env)-eabi)
{
@@ -3946,10 +3953,63 @@ static inline abi_long target_ftruncate64(void
*cpu_env, abi_long arg1,
arg3 = arg4;
}
#endif
+#if defined TARGET_PPC || defined TARGET_MIPS
+arg2 = arg3;
+arg3 = arg4;
+#endif
+#endif
return get_errno(ftruncate64(arg1, target_offset64(arg2, arg3)));
}
#endif
+#ifdef TARGET_NR_pread64
+static inline abi_long target_pread64(void *cpu_env, abi_long arg1,
+ void *arg2,
+ abi_long arg3,
+ abi_long arg4,
+ abi_long arg5,
+ abi_long arg6)
+{
+#if TARGET_ABI_BITS == 32
+#ifdef TARGET_ARM
+if (((CPUARMState *)cpu_env)-eabi)
+ {
+arg4 = arg5;
+arg5 = arg6;
+ }
+#endif
+#if defined TARGET_PPC || defined TARGET_MIPS
+arg4 = arg5;
+arg5 = arg6;
+#endif
+#endif
+return get_errno(pread64(arg1, arg2, arg3, target_offset64(arg4, arg5)));
+}
+
+static inline abi_long target_pwrite64(void *cpu_env, abi_long arg1,
+ const void *arg2,
+ abi_long arg3,
+ abi_long arg4,
+ abi_long arg5,
+ abi_long arg6)
+{
+#if TARGET_ABI_BITS == 32
+#ifdef TARGET_ARM
+if (((CPUARMState *)cpu_env)-eabi)
+ {
+arg4 = arg5;
+arg5 = arg6;
+ }
+#endif
+#if defined TARGET_PPC || defined TARGET_MIPS
+arg4 = arg5;
+arg5 = arg6;
+#endif
+#endif
+return get_errno(pwrite64(arg1, arg2, arg3, target_offset64(arg4, arg5)));
+}
+#endif
+
static inline abi_long target_to_host_timespec(struct timespec *host_ts,
abi_ulong target_addr)
{
@@ -6166,13 +6226,13 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
arg1,
case TARGET_NR_pread64:
if (!(p = lock_user(VERIFY_WRITE, arg2, arg3, 0)))
goto efault;
-ret = get_errno(pread64(arg1, p, arg3, target_offset64(arg4, arg5)));
+ret = target_pread64(cpu_env, arg1, p, arg3, arg4, arg5, arg6);
unlock_user(p, arg2, ret);
break;
case TARGET_NR_pwrite64:
if (!(p = lock_user(VERIFY_READ, arg2, arg3, 1)))
goto efault;
-ret = get_errno(pwrite64(arg1, p, arg3, target_offset64(arg4, arg5)));
+ret = target_pwrite64(cpu_env, arg1, p, arg3, arg4, arg5, arg6);
unlock_user(p, arg2, 0);
break;
#endif
--
1.6.4.2
[Qemu-devel] Re: [PATCH v3 0/2] Inter-VM shared memory PCI device
On 03/25/2010 08:08 AM, Cam Macdonell wrote:
Support an inter-vm shared memory device that maps a shared-memory object
as a PCI device in the guest. This patch also supports interrupts between
guest by communicating over a unix domain socket. This patch applies to the
qemu-kvm repository.
Changes in this version are using the qdev format and optional use of MSI and
ioeventfd/irqfd.
The non-interrupt version is supported by passing the shm parameter
-device ivshmem,size=size in MB,[shm=shm_name]
which will simply map the shm object into a BAR.
Interrupts are supported between multiple VMs by using a shared memory server
that is connected to with a socket character device
-device ivshmem,size=size in MB[,chardev=chardev name][,irqfd=on]
[,msi=on][,nvectors=n]
-chardev socket,path=path,id=chardev name
The server passes file descriptors for the shared memory object and eventfds
(our
interrupt mechanism) to the respective qemu instances.
When using interrupts, VMs communicate with a shared memory server that passes
the shared memory object file descriptor using SCM_RIGHTS. The server assigns
each VM an ID number and sends this ID number to the Qemu process along with a
series of eventfd file descriptors, one per guest using the shared memory
server. These eventfds will be used to send interrupts between guests. Each
guest listens on the eventfd corresponding to their ID and may use the others
for sending interrupts to other guests.
Please put the spec somewhere publicly accessible with a permanent URL.
I suggest a new qemu.git directory specs/. It's more important than the
code IMO.
enum ivshmem_registers {
IntrMask = 0,
IntrStatus = 4,
IVPosition = 8,
Doorbell = 12
};
The first two registers are the interrupt mask and status registers. Mask and
status are only used with pin-based interrupts. They are unused with MSI
interrupts. The IVPosition register is read-only and reports the guest's ID
number. Interrupts are triggered when a message is received on the guest's
eventfd from another VM. To trigger an event, a guest must write to another
guest's Doorbell. The Doorbells begin at offset 12. A particular guest's
doorbell offset in the MMIO region is equal to
guest_id * 32 + Doorbell
The doorbell register for each guest is 32-bits. The doorbell-per-guest
design was motivated for use with ioeventfd.
You can also use a single doorbell register with ioeventfd, as it can
match against the data written. If you go this route, you'd have two
doorbells, one where you write a guest ID to send an interrupt to that
guest, and one where any write generates a multicast.
Possible later extensions:
- multiple doorbells that trigger different vectors
- multicast doorbells
The semantics of the value written to the doorbell depends on whether the
device is using MSI or a regular pin-based interrupt.
I recommend against making the semantics interrupt-style dependent. It
means the application needs to know whether MSI is in use or not, while
it is generally the OS that is in control of that.
Regular Interrupts
--
If regular interrupts are used (due to either a guest not supporting MSI or the
user specifying not to use them on the command-line) then the value written to
a guest's doorbell is what the guest's status register will be set to.
An status of (2^32 - 1) indicates that a new guest has joined. Guests
should not send a message of this value for any other reason.
Message Signalled Interrupts
The important thing to remember with MSI is that it is only a signal, no
status is set (since MSI interrupts are not shared). All information other
than the interrupt itself should be communicated via the shared memory region.
MSI is on by default. It can be turned off with the msi=off to the parameter.
If the device uses MSI then the value written to the doorbell is the MSI vector
that will be raised. Vector 0 is used to notify that a new guest has joined.
Vector 0 cannot be triggered by another guest since a value of 0 does not
trigger an eventfd.
Ah, looks like we approached the vector/guest matrix from different
directions.
ioeventfd/irqfd
---
ioeventfd/irqfd is turned on by irqfd=on passed to the device parameter (it is
off by default). When using ioeventfd/irqfd the only interrupt value that can
be passed to another guest is 1 despite what value is written to a guest's
Doorbell.
ioeventfd/irqfd are an implementation detail. The spec should not
depend on it. It needs to be written as if qemu and kvm do not exist.
Again, I recommend Rusty's virtio-pci for inspiration.
Applications should see exactly the same thing whether ioeventfd is
enabled or not.
Sample programs, init scripts and the shared memory server are available in a
git repo here:
www.gitorious.org/nahanni
Cam Macdonell (2):
Support adding a file to
[Qemu-devel] Re: [PATCH v3 1/1] Shared memory uio_pci driver
On Thu, Mar 25, 2010 at 12:09:36AM -0600, Cam Macdonell wrote:
This patch adds a driver for my shared memory PCI device using the uio_pci
interface. The driver has three memory regions. The first memory region is
for
device registers for sending interrupts. The second BAR is for receiving MSI-X
interrupts and the third memory region maps the shared memory. The device
only
exports the first and third memory regions to userspace.
This driver supports MSI-X and regular pin interrupts. Currently, the number
of
MSI vectors is set to 4 which could be increased, but the driver will work
with
fewer vectors. If MSI is not available, then regular interrupts will be used.
---
drivers/uio/Kconfig |8 ++
drivers/uio/Makefile |1 +
drivers/uio/uio_ivshmem.c | 235
+
3 files changed, 244 insertions(+), 0 deletions(-)
create mode 100644 drivers/uio/uio_ivshmem.c
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 1da73ec..b92cded 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -74,6 +74,14 @@ config UIO_SERCOS3
If you compile this as a module, it will be called uio_sercos3.
+config UIO_IVSHMEM
+ tristate KVM shared memory PCI driver
+ default n
+ help
+ Userspace I/O interface for the KVM shared memory device. This
+ driver will make available two memory regions, the first is
+ registers and the second is a region for sharing between VMs.
+
config UIO_PCI_GENERIC
tristate Generic driver for PCI 2.3 and PCI Express cards
depends on PCI
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index 18fd818..25c1ca5 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_UIO_AEC) += uio_aec.o
obj-$(CONFIG_UIO_SERCOS3)+= uio_sercos3.o
obj-$(CONFIG_UIO_PCI_GENERIC)+= uio_pci_generic.o
obj-$(CONFIG_UIO_NETX) += uio_netx.o
+obj-$(CONFIG_UIO_IVSHMEM) += uio_ivshmem.o
diff --git a/drivers/uio/uio_ivshmem.c b/drivers/uio/uio_ivshmem.c
new file mode 100644
index 000..607435b
--- /dev/null
+++ b/drivers/uio/uio_ivshmem.c
@@ -0,0 +1,235 @@
+/*
+ * UIO IVShmem Driver
+ *
+ * (C) 2009 Cam Macdonell
+ * based on Hilscher CIF card driver (C) 2007 Hans J. Koch
h...@linutronix.de
+ *
+ * Licensed under GPL version 2 only.
+ *
+ */
+
+#include linux/device.h
+#include linux/module.h
+#include linux/pci.h
+#include linux/uio_driver.h
+
+#include asm/io.h
+
+#define IntrStatus 0x04
+#define IntrMask 0x00
+
+struct ivshmem_info {
+struct uio_info *uio;
+struct pci_dev *dev;
+char (*msix_names)[256];
+struct msix_entry *msix_entries;
+int nvectors;
+};
+
+static irqreturn_t ivshmem_handler(int irq, struct uio_info *dev_info)
+{
+
+void __iomem *plx_intscr = dev_info-mem[0].internal_addr
++ IntrStatus;
+u32 val;
+
+val = readl(plx_intscr);
+if (val == 0)
+return IRQ_NONE;
+
+printk(KERN_INFO Regular interrupt (val = %d)\n, val);
+return IRQ_HANDLED;
+}
+
+static irqreturn_t ivshmem_msix_handler(int irq, void *opaque)
+{
+
+struct uio_info * dev_info = (struct uio_info *) opaque;
+
+/* we have to do this explicitly when using MSI-X */
+uio_event_notify(dev_info);
How does userspace know which vector was triggered?
+printk(KERN_INFO MSI-X interrupt (%d)\n, irq);
+return IRQ_HANDLED;
+
extra empty line
+}
+
+static int request_msix_vectors(struct ivshmem_info *ivs_info, int nvectors)
+{
+int i, err;
+const char *name = ivshmem;
+
+printk(KERN_INFO devname is %s\n, name);
These KERN_INFO messages need to be cleaned up, they would be
look confusing in the log.
+ivs_info-nvectors = nvectors;
+
+
+ivs_info-msix_entries = kmalloc(nvectors * sizeof
*ivs_info-msix_entries,
+GFP_KERNEL);
+ivs_info-msix_names = kmalloc(nvectors * sizeof *ivs_info-msix_names,
+GFP_KERNEL);
+
need to handle errors
+for (i = 0; i nvectors; ++i)
+ivs_info-msix_entries[i].entry = i;
+
+err = pci_enable_msix(ivs_info-dev, ivs_info-msix_entries,
+ivs_info-nvectors);
+if (err 0) {
+ivs_info-nvectors = err; /* msi-x positive error code
+ returns the number available*/
+err = pci_enable_msix(ivs_info-dev, ivs_info-msix_entries,
+ivs_info-nvectors);
+if (err 0) {
+printk(KERN_INFO no MSI (%d). Back to INTx.\n, err);
+return -ENOSPC;
+}
+}
we can also get err 0.
+
+printk(KERN_INFO err is %d\n, err);
+if (err) return err;
coding style rule violation
+
+for (i = 0; i ivs_info-nvectors; i++) {
+
+snprintf(ivs_info-msix_names[i], sizeof *ivs_info-msix_names,
+%s-config, name);
+
+
[Qemu-devel] Re: [PATCH] update bochs vbe interface
Hi, Then our big problem is migration between read of the 1st register and of the 2nd register, no? big? The window is quite small, and I think we have a bunch of simliar issues elsewhere in qemu. They are hardly avoidable for new - old migration when adding new features to emulated devices. Well, maybe sections can fix it, but probably only in case the old qemu is new enougth that it can handle sections too. Furthermore, older vga bios, seing VBE_DISPI_ID5, what are they going to do? Work as they did before ;) So when migrating from new to old qemu: Before reset vgabios will have the video memory size saved somewhere. After reset ID will reset to ID0, and in case you are running vgabios 0.6c vesa gfx modes will stop working. I see this part, but I still think that we have a window where we can be in very bad shape, no? I guess that we don't support anything different that vgabios, so See above. Worst case is that vesa graphics modes stop working, even if you hit the race window (vgabios will think you have 0 MB video ram then and refuse all gfx modes). cheers, Gerd
[Qemu-devel] Re: [PATCH v3 1/1] Shared memory uio_pci driver
On Thu, Mar 25, 2010 at 12:09:36AM -0600, Cam Macdonell wrote:
This patch adds a driver for my shared memory PCI device using the uio_pci
interface. The driver has three memory regions. The first memory region is
for
device registers for sending interrupts. The second BAR is for receiving MSI-X
interrupts and the third memory region maps the shared memory. The device
only
exports the first and third memory regions to userspace.
This driver supports MSI-X and regular pin interrupts. Currently, the number
of
MSI vectors is set to 4 which could be increased, but the driver will work
with
fewer vectors. If MSI is not available, then regular interrupts will be used.
Some high level questions, sorry if they have been raised in the past:
- Can this device use virtio framework?
This gives us some standards to work off, with feature negotiation,
ability to detect config changes, support for non-PCI
platforms, decent documentation that is easy to extend,
legal id range to use.
You would thus have your driver in uio/uio_virtio_shmem.c
- Why are you using 32 bit long memory accesses for interrupts?
16 bit IO eould be enough and it's faster. This what virtio-pci does.
- How was the driver tested?
---
drivers/uio/Kconfig |8 ++
drivers/uio/Makefile |1 +
drivers/uio/uio_ivshmem.c | 235
+
3 files changed, 244 insertions(+), 0 deletions(-)
create mode 100644 drivers/uio/uio_ivshmem.c
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 1da73ec..b92cded 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -74,6 +74,14 @@ config UIO_SERCOS3
If you compile this as a module, it will be called uio_sercos3.
+config UIO_IVSHMEM
+ tristate KVM shared memory PCI driver
+ default n
+ help
+ Userspace I/O interface for the KVM shared memory device. This
+ driver will make available two memory regions, the first is
+ registers and the second is a region for sharing between VMs.
+
config UIO_PCI_GENERIC
tristate Generic driver for PCI 2.3 and PCI Express cards
depends on PCI
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index 18fd818..25c1ca5 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_UIO_AEC) += uio_aec.o
obj-$(CONFIG_UIO_SERCOS3)+= uio_sercos3.o
obj-$(CONFIG_UIO_PCI_GENERIC)+= uio_pci_generic.o
obj-$(CONFIG_UIO_NETX) += uio_netx.o
+obj-$(CONFIG_UIO_IVSHMEM) += uio_ivshmem.o
diff --git a/drivers/uio/uio_ivshmem.c b/drivers/uio/uio_ivshmem.c
new file mode 100644
index 000..607435b
--- /dev/null
+++ b/drivers/uio/uio_ivshmem.c
@@ -0,0 +1,235 @@
+/*
+ * UIO IVShmem Driver
+ *
+ * (C) 2009 Cam Macdonell
+ * based on Hilscher CIF card driver (C) 2007 Hans J. Koch
h...@linutronix.de
+ *
+ * Licensed under GPL version 2 only.
+ *
+ */
+
+#include linux/device.h
+#include linux/module.h
+#include linux/pci.h
+#include linux/uio_driver.h
+
+#include asm/io.h
+
+#define IntrStatus 0x04
+#define IntrMask 0x00
+
+struct ivshmem_info {
+struct uio_info *uio;
+struct pci_dev *dev;
+char (*msix_names)[256];
+struct msix_entry *msix_entries;
+int nvectors;
+};
+
+static irqreturn_t ivshmem_handler(int irq, struct uio_info *dev_info)
+{
+
+void __iomem *plx_intscr = dev_info-mem[0].internal_addr
++ IntrStatus;
+u32 val;
+
+val = readl(plx_intscr);
+if (val == 0)
+return IRQ_NONE;
+
+printk(KERN_INFO Regular interrupt (val = %d)\n, val);
+return IRQ_HANDLED;
+}
+
+static irqreturn_t ivshmem_msix_handler(int irq, void *opaque)
+{
+
+struct uio_info * dev_info = (struct uio_info *) opaque;
+
+/* we have to do this explicitly when using MSI-X */
+uio_event_notify(dev_info);
+printk(KERN_INFO MSI-X interrupt (%d)\n, irq);
+return IRQ_HANDLED;
+
+}
+
+static int request_msix_vectors(struct ivshmem_info *ivs_info, int nvectors)
+{
+int i, err;
+const char *name = ivshmem;
+
+printk(KERN_INFO devname is %s\n, name);
+ivs_info-nvectors = nvectors;
+
+
+ivs_info-msix_entries = kmalloc(nvectors * sizeof
*ivs_info-msix_entries,
+GFP_KERNEL);
+ivs_info-msix_names = kmalloc(nvectors * sizeof *ivs_info-msix_names,
+GFP_KERNEL);
+
+for (i = 0; i nvectors; ++i)
+ivs_info-msix_entries[i].entry = i;
+
+err = pci_enable_msix(ivs_info-dev, ivs_info-msix_entries,
+ivs_info-nvectors);
+if (err 0) {
+ivs_info-nvectors = err; /* msi-x positive error code
+ returns the number available*/
+err = pci_enable_msix(ivs_info-dev, ivs_info-msix_entries,
+ivs_info-nvectors);
+if (err 0) {
+printk(KERN_INFO no MSI (%d). Back to
Re: [Qemu-devel] Significant performance regression in qemu-system-mips.
2010/3/24 Rob Landley r...@landley.net: I have a native build under qemu that gets killed if it doesn't produce a line of output for 60 seconds (hang detection enforced by the host monitoring qemu's stdout with --nographic, not from within qemu). In the most recent release version, it never came close to triggering on mips with a 30 second timeout. In the current -git version (well, as of Thursday anyway), it triggers frequently (about 90% of the time) even with a 60 second timeout. Are other platforms affected as well? Do your automated tests run against qemu-sparc meanwhile? -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/
[Qemu-devel] Re: [PATCH v3 0/2] Inter-VM shared memory PCI device
Avi Kivity a...@redhat.com writes: Please put the spec somewhere publicly accessible with a permanent URL. I suggest a new qemu.git directory specs/. It's more important than the code IMO. What about docs/? It already exists. [...]
[Qemu-devel] Re: [PATCH v3 0/2] Inter-VM shared memory PCI device
On 03/25/2010 11:26 AM, Markus Armbruster wrote: Avi Kivitya...@redhat.com writes: Please put the spec somewhere publicly accessible with a permanent URL. I suggest a new qemu.git directory specs/. It's more important than the code IMO. What about docs/? It already exists. docs/ would be internal qemu documentation. I want it to be clear this is external documentation. docs/specs/ would work for that. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [PATCH v3 1/1] Shared memory uio_pci driver
On 03/25/2010 11:15 AM, Michael S. Tsirkin wrote: - Why are you using 32 bit long memory accesses for interrupts? 16 bit IO eould be enough and it's faster. This what virtio-pci does. Why is 16 bit io faster? -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Re: KVM call agenda for Mar 23
On 03/25/10 10:39, Jan Kiszka wrote: Zhang, Xiantao wrote: For ia64 part, maybe we can keep the current qemu-kvm.git for the users. And it is not a must to push it into Qemu upstream. Xiantao Does it still build work? Does someone test it at least infrequently? Or are there users? There were a few changes recently due to cleanups and/or switches to upstream code. There will be more in the future. And at some point heavy work will be needed when there are no more qemu-kvm* files. That could be a point ia64 breaks forever unless someone jumps in. BTW, I'm also carrying ia64 bits in kvm-kmod. I never compiled them (except for the make headers_install which throws tons of warnings at me), I'm just keeping them for now to enforce architecture separation in case someone once wishes to add another arch to this wrapper. I think the end result will be that an older version of qemu-kvm will be around, and if someone decides to pick up on it, they will have to work from that. At this point I only see some of the Japanese vendors potentially being interested, but I think they have mostly been looking at Xen/ia64. Then again, I have no idea what the state is for Xen/ia64 patches for QEMU, in theory a lot of it should be shared. As long as the bits are sitting in the tree without disturbing other parts, then I just think we should let them sit there. Cheers, Jes
[Qemu-devel] Re: [PATCH v3 1/1] Shared memory uio_pci driver
On 03/25/2010 08:09 AM, Cam Macdonell wrote: This patch adds a driver for my shared memory PCI device using the uio_pci interface. The driver has three memory regions. The first memory region is for device registers for sending interrupts. The second BAR is for receiving MSI-X interrupts and the third memory region maps the shared memory. The device only exports the first and third memory regions to userspace. This driver supports MSI-X and regular pin interrupts. Currently, the number of MSI vectors is set to 4 which could be increased, but the driver will work with fewer vectors. If MSI is not available, then regular interrupts will be used. There is now a generic PCI 2.3 driver that can handle all PCI devices. It doesn't support MSI, but if we add MSI support then it can be used without the need for a specialized driver. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [PATCH v3 1/1] Shared memory uio_pci driver
On 03/25/2010 11:05 AM, Michael S. Tsirkin wrote: coding style rule violation Plus it uses spaces instead of tabs for indents. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [PATCH v3 1/1] Shared memory uio_pci driver
On Thu, Mar 25, 2010 at 11:40:09AM +0200, Avi Kivity wrote: On 03/25/2010 11:15 AM, Michael S. Tsirkin wrote: - Why are you using 32 bit long memory accesses for interrupts? 16 bit IO eould be enough and it's faster. This what virtio-pci does. Why is 16 bit io faster? Something to do with need for emulation to get address/data for pci memory accesses? -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Re: KVM call agenda for Mar 23
Zhang, Xiantao wrote: Jes Sorensen wrote: On 03/23/10 13:45, Anthony Liguori wrote: I don't think we can pull in: - extboot - ia64 - in-kernel pit[1] - associated command line options - device passthrough The question is, if we dropped those things, would people actually use qemu.git instead of qemu-kvm.git. If the answer is no, what set of things do we need in order for people to focus on qemu.git instead of qemu-kvm.git. I am not sure if anyone is still actively working on ia64. According to the qemu-kvm.git logs, there hasn't been any real ia64 changes to the code since my last commit in June of last year and then a couple of minor configure bits. IMHO we can just let it rot - not sure if Xiantao is still interested? For ia64 part, maybe we can keep the current qemu-kvm.git for the users. And it is not a must to push it into Qemu upstream. Xiantao Does it still build work? Does someone test it at least infrequently? Or are there users? There were a few changes recently due to cleanups and/or switches to upstream code. There will be more in the future. And at some point heavy work will be needed when there are no more qemu-kvm* files. That could be a point ia64 breaks forever unless someone jumps in. BTW, I'm also carrying ia64 bits in kvm-kmod. I never compiled them (except for the make headers_install which throws tons of warnings at me), I'm just keeping them for now to enforce architecture separation in case someone once wishes to add another arch to this wrapper. Jan signature.asc Description: OpenPGP digital signature
[Qemu-devel] Re: [PATCH v3 1/1] Shared memory uio_pci driver
On 03/25/2010 11:44 AM, Michael S. Tsirkin wrote: On Thu, Mar 25, 2010 at 11:40:09AM +0200, Avi Kivity wrote: On 03/25/2010 11:15 AM, Michael S. Tsirkin wrote: - Why are you using 32 bit long memory accesses for interrupts? 16 bit IO eould be enough and it's faster. This what virtio-pci does. Why is 16 bit io faster? Something to do with need for emulation to get address/data for pci memory accesses? pio is definitely faster than mmio (all that is needed is to set one bit on the BAR). But 32 vs. 16 makes no difference. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [PATCH v3 1/1] Shared memory uio_pci driver
On Thu, Mar 25, 2010 at 11:58:30AM +0200, Avi Kivity wrote: On 03/25/2010 11:44 AM, Michael S. Tsirkin wrote: On Thu, Mar 25, 2010 at 11:40:09AM +0200, Avi Kivity wrote: On 03/25/2010 11:15 AM, Michael S. Tsirkin wrote: - Why are you using 32 bit long memory accesses for interrupts? 16 bit IO eould be enough and it's faster. This what virtio-pci does. Why is 16 bit io faster? Something to do with need for emulation to get address/data for pci memory accesses? pio is definitely faster than mmio (all that is needed is to set one bit on the BAR). But 32 vs. 16 makes no difference. Right. That's what I meant. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] QEMU state of ARM NEON support.
juha.riihim...@nokia.com wrote: Hi, Thanks for the testing. I fixed all of the issues found by your test programs except: Great! This is very good news. Please look at my comments below regarding specific issues. - vmull.p8 is not implemented in QEMU. So seems this is now the only NEON instruction variant left that QEMU doesn't handle. - vrecpe/vrsqrte returns exact reciprocal/root in QEMU instead of estimate. A simple algorithm used in hardware is described in the ARMv7 ARM* (see function 'recip_estimate' on page A2-59) but I don't think this is a big issue as exact computations may be even better. - Using subnormal floating point input values yields wrong results (this is visible in your vceq/vcgt/vcle tests against zero), I guess this would need to be corrected in the softfloat library which QEMU uses. This is actually a Flush-to-zero feature which is always on for NEON instructions (see FZ field description of FPSCR in A2.6.4 chapter of ARMv7 ARM). Before attempting to perform an action on the floating-point data NEON first checks if it is close to zero (zero exponent, bits 23-30 for F32, see FPUnpack function at page A2-48) and behaves as if it was zero if the check succeeds. - vqdmlsl yields different results for some specific input values, however I think QEMU is producing correct results. For example, 1431655765-(2*-32768*-32768)=-715827883 but your reference hardware results say it should be -715827882. From what I understand hardware gets such result because saturation occurs on the (2*-32768*-32768) step. The result is not 0x8000 as expected but because of overflow is set as the largest 32-bit signed integer 0x7FFF. It seems that QEMU just doesn't perform saturation (in this particular case at least). Anyway, many thanks for the testing you did and especially for posting the test programs as well. All these fixes along with many others are now in the Maemo QEMU repository. We'll try to make a new set of ARM emulation patches against upstream QEMU in the near future. We'll be waiting for this. Thanks a lot for your work. Regards, Juha * I am referring to the ARM Architecture Reference Manual, ARMv7-A and ARMv7-R edition version ARM_2009_Q3. Regards, Dmitry
[Qemu-devel] [PATCH v3] update bochs vbe interface
The bochs vbe interface got a new register a while back, which specifies
the linear framebuffer size in 64k units. This patch adds support for
the new register to qemu. With this patch applied vgabios 0.6c works
with qemu.
[ v2: Don't savevm the new register. Doing so breaks migration,
and as it carries read-only information for the guest there
is no need to save it. ]
[ v3: Don't put the new register into vbe_regs. ]
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/vga.c |6 --
hw/vga_int.h |4 +++-
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/hw/vga.c b/hw/vga.c
index 6a1a059..bb65677 100644
--- a/hw/vga.c
+++ b/hw/vga.c
@@ -522,7 +522,7 @@ static uint32_t vbe_ioport_read_data(void *opaque, uint32_t
addr)
VGACommonState *s = opaque;
uint32_t val;
-if (s-vbe_index = VBE_DISPI_INDEX_NB) {
+if (s-vbe_index VBE_DISPI_INDEX_NB) {
if (s-vbe_regs[VBE_DISPI_INDEX_ENABLE] VBE_DISPI_GETCAPS) {
switch(s-vbe_index) {
/* XXX: do not hardcode ? */
@@ -542,6 +542,8 @@ static uint32_t vbe_ioport_read_data(void *opaque, uint32_t
addr)
} else {
val = s-vbe_regs[s-vbe_index];
}
+} else if (s-vbe_index == VBE_DISPI_INDEX_VIDEO_MEMORY_64K) {
+val = s-vram_size / (64 * 1024);
} else {
val = 0;
}
@@ -1955,7 +1957,7 @@ void vga_common_reset(VGACommonState *s)
#ifdef CONFIG_BOCHS_VBE
s-vbe_index = 0;
memset(s-vbe_regs, '\0', sizeof(s-vbe_regs));
-s-vbe_regs[VBE_DISPI_INDEX_ID] = VBE_DISPI_ID0;
+s-vbe_regs[VBE_DISPI_INDEX_ID] = VBE_DISPI_ID5;
s-vbe_start_addr = 0;
s-vbe_line_offset = 0;
s-vbe_bank_mask = (s-vram_size 16) - 1;
diff --git a/hw/vga_int.h b/hw/vga_int.h
index 23a42ef..6a46a43 100644
--- a/hw/vga_int.h
+++ b/hw/vga_int.h
@@ -47,13 +47,15 @@
#define VBE_DISPI_INDEX_VIRT_HEIGHT 0x7
#define VBE_DISPI_INDEX_X_OFFSET0x8
#define VBE_DISPI_INDEX_Y_OFFSET0x9
-#define VBE_DISPI_INDEX_NB 0xa
+#define VBE_DISPI_INDEX_NB 0xa /* size of vbe_regs[] */
+#define VBE_DISPI_INDEX_VIDEO_MEMORY_64K 0xa /* read-only, not in vbe_regs */
#define VBE_DISPI_ID0 0xB0C0
#define VBE_DISPI_ID1 0xB0C1
#define VBE_DISPI_ID2 0xB0C2
#define VBE_DISPI_ID3 0xB0C3
#define VBE_DISPI_ID4 0xB0C4
+#define VBE_DISPI_ID5 0xB0C5
#define VBE_DISPI_DISABLED 0x00
#define VBE_DISPI_ENABLED 0x01
--
1.6.6.1
Re: [Qemu-devel] QEMU state of ARM NEON support.
On Mar 25, 2010, at 12:27, ext Dmitry Zhurikhin wrote: juha.riihim...@nokia.com wrote: - vqdmlsl yields different results for some specific input values, however I think QEMU is producing correct results. For example, 1431655765-(2*-32768*-32768)=-715827883 but your reference hardware results say it should be -715827882. From what I understand hardware gets such result because saturation occurs on the (2*-32768*-32768) step. The result is not 0x8000 as expected but because of overflow is set as the largest 32-bit signed integer 0x7FFF. It seems that QEMU just doesn't perform saturation (in this particular case at least). Yes I see, I overlooked the fact that -32768*-32768 changes the sign and so doubling the result of that overflows the signed 32-bit integer even if the result still fits in 32 bits. Thanks, I'll fix that as well. Regards, Juha
[Qemu-devel] Re: [PATCH] qemu: jaso-parser: Output the content of invalid keyword
On 03/24/2010 08:12 AM, Amos Kong wrote:
When input some invialid word 'unknowcmd' through QMP port, qemu outputs this
error message:
parse error: invalid keyword `%s'
This patch makes qemu output the content of invalid keyword, like:
parse error: invalid keyword `unknowcmd'
Signed-off-by: Amos Kong ak...@redhat.com
Acked-by: Richard Henderson r...@redhat.com
---
json-parser.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/json-parser.c b/json-parser.c
index 579928f..b55d763 100644
--- a/json-parser.c
+++ b/json-parser.c
@@ -12,6 +12,7 @@
*/
#include stdbool.h
+#include stdarg.h
#include qemu-common.h
#include qstring.h
@@ -93,7 +94,12 @@ static int token_is_escape(QObject *obj, const char *value)
*/
static void parse_error(JSONParserContext *ctxt, QObject *token, const char
*msg, ...)
{
-fprintf(stderr, parse error: %s\n, msg);
+va_list ap;
+va_start(ap, msg);
+fprintf(stderr, parse error: );
+vfprintf(stderr, msg, ap);
+fprintf(stderr, \n);
+va_end(ap);
}
/**
[Qemu-devel] Re: [PATCH] update bochs vbe interface
Gerd Hoffmann kra...@redhat.com wrote:
Hi,
Then our big problem is migration between read of the 1st register and
of the 2nd register, no?
big?
That is why I asked. I have no clue about how many times that register
is read.
The window is quite small, and I think we have a bunch of
simliar issues elsewhere in qemu. They are hardly avoidable for new
-
old migration when adding new features to emulated devices.
yeap, but normally we don't allow migration from new to old for this
very reason. Not allowing from new to old fixes this issue. Sections
can't help here :(
Well, maybe sections can fix it, but probably only in case the old
qemu is new enougth that it can handle sections too.
sections don't help here :(
We are changing how hardware works under the BIOS code, we told 1st that
we have a feature and when BIOS go to use it, feature has disappeared.
Furthermore, older vga bios, seing VBE_DISPI_ID5, what are they going to
do?
Work as they did before ;)
/me just like BIOS :)
So when migrating from new to old qemu: Before reset
vgabios will have the video memory size saved somewhere. After reset
ID will reset to ID0, and in case you are running vgabios 0.6c vesa
gfx modes will stop working.
I see this part, but I still think that we have a window where we can be
in very bad shape, no? I guess that we don't support anything different
that vgabios, so
See above. Worst case is that vesa graphics modes stop working, even
if you hit the race window (vgabios will think you have 0 MB video ram
then and refuse all gfx modes).
If it is only read during startup, once, I think that geting 0 size is
ok. Extra bonus for modifying vgabios to handle this case nicely?
Should be a case of
if (val == 0) {
do like old bios
}
no?
Later, Juan.
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On 03/25/2010 03:26 AM, Vincent Hanquez wrote: On 24/03/10 21:40, Anthony Liguori wrote: If so, what C clients you expected beyond libvirt? Users want a C API. I don't agree that libvirt is the only C interface consumer out there. (I've seen this written too many times ...) How do you know that ? did you do a poll or something where *actual* users vote/tell ? From my point of view, i wouldn't want to write a high level management toolstack in C, specially since the API is well defined JSON which is easily available in all high level language out there. There's a whole world of C based management toolstacks (CIM). Regards, Anthony Liguori
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On 03/25/2010 02:33 PM, Anthony Liguori wrote: From my point of view, i wouldn't want to write a high level management toolstack in C, specially since the API is well defined JSON which is easily available in all high level language out there. There's a whole world of C based management toolstacks (CIM). Gratefully I know very little about CIM, but isn't it language independent? The prominent open source implementation, pegasus, is written in C++. Or are you referring to specific management apps written in C? If they go through CIM, how can they talk qmp? -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH][RESEND] Serial: DOS Plus regression
The commit in r1049 (serial interrupt fix (Hampa Hug)) prevents
booting Digital Research DOSPlus. Following patch partially reverts
that commit and makes DOSPlus booting in QEMU again.
Sign-off-by: Roy Tam roy...@gmail.com
--
diff --git a/hw/serial.c b/hw/serial.c
index f3ec36a..2ae550e 100644
--- a/hw/serial.c
+++ b/hw/serial.c
@@ -401,10 +401,6 @@ static void serial_ioport_write(void *opaque,
s-poll_msl = 0;
}
}
-if (s-lsr UART_LSR_THRE) {
-s-thr_ipending = 1;
-serial_update_irq(s);
-}
}
break;
case 2:
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
Anthony Liguori wrote: On 03/25/2010 03:26 AM, Vincent Hanquez wrote: On 24/03/10 21:40, Anthony Liguori wrote: If so, what C clients you expected beyond libvirt? Users want a C API. I don't agree that libvirt is the only C interface consumer out there. (I've seen this written too many times ...) How do you know that ? did you do a poll or something where *actual* users vote/tell ? From my point of view, i wouldn't want to write a high level management toolstack in C, specially since the API is well defined JSON which is easily available in all high level language out there. There's a whole world of C based management toolstacks (CIM). Regards, Anthony Liguori That huge companies have developped over-complicated c-based management toolstacks doesn't necessarily mean that this is the best way to do it. It just mean that they have enough qualified ressources to do it. A simple, language-neutral API is always preferable in my opinion, since it lowers the prerequisites/entry price, and will allow more people to use it, including system engineers. Ensuring that the new API will be easy to use by new comers will also ensure that it will be easy to use by existing stacks including libvirt. Also I second Avi's opinion in another mail that all command line options [should] have qmp equivalents: it is vital for flexibility/manageability to be able to programatically change setups after a VM was started. To quote the automation part of the James White Manifesto[1], a document that is gaining a lot of traction in the sysadmin/devops community: The provided API must have all functionality that the application provides. The provided API must be tailored to more than one language and platform. Regards, Gildas -- [1] You can find a copy of it here: http://www.kartar.net/2010/03/james-whites-rules-for-infrastructure/
Re: [Qemu-devel] [PATCH 09/10] target-alpha: Implement load-locked/store-conditional properly.
On Wed, Mar 24, 2010 at 05:11:43PM -0700, Richard Henderson wrote: Use __sync_bool_compare_and_swap to yield correctly atomic results. As yet, this assumes running on an strict-memory-ordering host (i.e. x86), since we're still implementing the memory-barrier instructions as nops. Did the approach taken by other targets (arm/mips/ppc) not work on Alpha? -Nathan
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On 03/25/2010 07:37 AM, Avi Kivity wrote: On 03/25/2010 02:33 PM, Anthony Liguori wrote: From my point of view, i wouldn't want to write a high level management toolstack in C, specially since the API is well defined JSON which is easily available in all high level language out there. There's a whole world of C based management toolstacks (CIM). Gratefully I know very little about CIM, but isn't it language independent? The prominent open source implementation, pegasus, is written in C++. There is also SFCB which is written in C. But an awful lot of the providers for pegasus are written in C. The point is, C is a lowest common denominator and it's important to support in a proper way. Regards, Anthony Liguori Or are you referring to specific management apps written in C? If they go through CIM, how can they talk qmp?
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On 03/25/2010 03:44 PM, Anthony Liguori wrote: On 03/25/2010 07:37 AM, Avi Kivity wrote: On 03/25/2010 02:33 PM, Anthony Liguori wrote: From my point of view, i wouldn't want to write a high level management toolstack in C, specially since the API is well defined JSON which is easily available in all high level language out there. There's a whole world of C based management toolstacks (CIM). Gratefully I know very little about CIM, but isn't it language independent? The prominent open source implementation, pegasus, is written in C++. There is also SFCB which is written in C. Ok. But an awful lot of the providers for pegasus are written in C. But we're concerned with only one, the virt provider. None of the others will use libqemu? The point is, C is a lowest common denominator and it's important to support in a proper way. Problem is, it means horrible support for everyone else. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [patch 2/2] virtio-serial-bus: wake up iothread upon guest read notification
Wake up iothread when buffers are consumed.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Index: qemu-ioworker/hw/virtio-serial-bus.c
===
--- qemu-ioworker.orig/hw/virtio-serial-bus.c
+++ qemu-ioworker/hw/virtio-serial-bus.c
@@ -331,6 +331,7 @@ static void handle_output(VirtIODevice *
static void handle_input(VirtIODevice *vdev, VirtQueue *vq)
{
+qemu_notify_event(main_io_worker);
}
static uint32_t get_features(VirtIODevice *vdev, uint32_t features)
[Qemu-devel] [patch 0/2] introduce QEMUIOWorker and wake up iothread on virtio-serial-bus notification (v2)
Rebased to latest qemu.git.
[Qemu-devel] [patch 1/2] Pass QEMUIOWorker to qemu_notify_event
This can be used later to introduce generic iothread workers.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Index: qemu-ioworker/async.c
===
--- qemu-ioworker.orig/async.c
+++ qemu-ioworker/async.c
@@ -180,7 +180,7 @@ void qemu_bh_schedule(QEMUBH *bh)
bh-scheduled = 1;
bh-idle = 0;
/* stop the currently executing CPU to execute the BH ASAP */
-qemu_notify_event();
+qemu_notify_event(main_io_worker);
}
void qemu_bh_cancel(QEMUBH *bh)
Index: qemu-ioworker/hw/mac_dbdma.c
===
--- qemu-ioworker.orig/hw/mac_dbdma.c
+++ qemu-ioworker/hw/mac_dbdma.c
@@ -655,7 +655,7 @@ void DBDMA_register_channel(void *dbdma,
void DBDMA_schedule(void)
{
-qemu_notify_event();
+qemu_notify_event(main_io_worker);
}
static void
Index: qemu-ioworker/hw/virtio-net.c
===
--- qemu-ioworker.orig/hw/virtio-net.c
+++ qemu-ioworker/hw/virtio-net.c
@@ -360,7 +360,7 @@ static void virtio_net_handle_rx(VirtIOD
/* We now have RX buffers, signal to the IO thread to break out of the
* select to re-poll the tap file descriptor */
-qemu_notify_event();
+qemu_notify_event(main_io_worker);
}
static int virtio_net_can_receive(VLANClientState *nc)
Index: qemu-ioworker/qemu-common.h
===
--- qemu-ioworker.orig/qemu-common.h
+++ qemu-ioworker/qemu-common.h
@@ -235,11 +235,17 @@ typedef uint64_t pcibus_t;
void cpu_save(QEMUFile *f, void *opaque);
int cpu_load(QEMUFile *f, void *opaque, int version_id);
+typedef struct QEMUIOWorker {
+void *opaque;
+} QEMUIOWorker;
+
/* Force QEMU to stop what it's doing and service IO */
void qemu_service_io(void);
/* Force QEMU to process pending events */
-void qemu_notify_event(void);
+void qemu_notify_event(QEMUIOWorker *worker);
+
+extern QEMUIOWorker *main_io_worker;
/* Unblock cpu */
void qemu_cpu_kick(void *env);
Index: qemu-ioworker/vl.c
===
--- qemu-ioworker.orig/vl.c
+++ qemu-ioworker/vl.c
@@ -258,6 +258,9 @@ uint8_t qemu_uuid[16];
static QEMUBootSetHandler *boot_set_handler;
static void *boot_set_opaque;
+QEMUIOWorker iothread_worker;
+QEMUIOWorker *main_io_worker = iothread_worker;
+
#ifdef SIGRTMIN
#define SIG_IPI (SIGRTMIN+4)
#else
@@ -1884,7 +1887,7 @@ static int ram_load(QEMUFile *f, void *o
void qemu_service_io(void)
{
-qemu_notify_event();
+qemu_notify_event(main_io_worker);
}
/***/
@@ -2137,19 +2140,19 @@ void qemu_system_reset_request(void)
} else {
reset_requested = 1;
}
-qemu_notify_event();
+qemu_notify_event(main_io_worker);
}
void qemu_system_shutdown_request(void)
{
shutdown_requested = 1;
-qemu_notify_event();
+qemu_notify_event(main_io_worker);
}
void qemu_system_powerdown_request(void)
{
powerdown_requested = 1;
-qemu_notify_event();
+qemu_notify_event(main_io_worker);
}
static int cpu_can_run(CPUState *env)
@@ -2313,7 +2316,7 @@ void qemu_cpu_kick(void *env)
return;
}
-void qemu_notify_event(void)
+void qemu_notify_event(QEMUIOWorker *worker)
{
CPUState *env = cpu_single_env;
@@ -2701,7 +2704,7 @@ void qemu_init_vcpu(void *_env)
tcg_init_vcpu(env);
}
-void qemu_notify_event(void)
+void qemu_notify_event(QEMUIOWorker *worker)
{
qemu_event_increment();
}
@@ -2709,7 +2712,7 @@ void qemu_notify_event(void)
static void qemu_system_vmstop_request(int reason)
{
vmstop_requested = reason;
-qemu_notify_event();
+qemu_notify_event(main_io_worker);
}
void vm_stop(int reason)
Index: qemu-ioworker/qemu-timer.c
===
--- qemu-ioworker.orig/qemu-timer.c
+++ qemu-ioworker/qemu-timer.c
@@ -547,7 +547,7 @@ void qemu_mod_timer(QEMUTimer *ts, int64
}
/* Interrupt execution to force deadline recalculation. */
if (use_icount)
-qemu_notify_event();
+qemu_notify_event(main_io_worker);
}
}
@@ -775,7 +775,7 @@ static void host_alarm_handler(int host_
t-expired = alarm_has_dynticks(t);
t-pending = 1;
-qemu_notify_event();
+qemu_notify_event(main_io_worker);
}
}
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On 03/25/2010 08:23 AM, Luiz Capitulino wrote: On Wed, 24 Mar 2010 16:40:18 -0500 Anthony Liguorianth...@codemonkey.ws wrote: We need to have a common management interface for third party tools. QMP? :-) Only if QMP is compatible with libvirt. I don't want a user to have to choose between QMP and libvirt. Why not? If all they want is a simple qemu session, they can use QMP directly, on the other hand if what they want is more complex, what's the problem of using a management API like libivrt? My point is that libvirt should not be a separate management API but effectively an add-on API that provides higher level features, better integration with Linux host services, etc. You mentioned dynamic dispatch, but this is useful only for C clients right? If so, what C clients you expected beyond libvirt? Users want a C API. I don't agree that libvirt is the only C interface consumer out there. Actually, I do agree. Maybe, we don't have other C consumers because they weren't crazy enough to parse the crap of the user Monitor (or they do, but for simple things). One possible future client is perf, for example. Here is my solution (actually it's not mine, you have suggested it some time ago): let's provide a convenient way for C clients to use QMP. That is, let's have an overly simple library which takes QDitcs, sends them to qemu through QMP and returns others QDicts. Something like the _sketch_ below: // Open a connection int qmp_open(..., QDict **greeting); // Register a callback for async messages, BUT note that the async message // object is passed verbatim void qmp_async_mes_handler(..., void (*async_mes_handler)(QDict *mes)); // Send a QMP command int qmp_send(..., const char *command, QDict *params, QDict **res); Yes, this is the core API. It's missing a mechanism to create a QMPContext. I'll also argue that we want a set of auto generated wrappers like: QError *qmp_last_error(QMPContext *context); int qmp_set_link(QMPContext *context, const char *name, bool up); That's a thin wrapper around qmp_send(). You can autogenerate this fairly easy with an IDL like: None:qmp_set_link:String:name,Boolean:up Which is fairly easy to output using introspection on a QMP session. Obviously that we'll need a QMPContext and maybe additional functions, And for a QMPContext, we need functions like: /* use qemu's default advertisement mechanism to find a guest */ QMPContext *qmp_context_new_by_uuid(uuid_t uuid); QMPContext *qmp_context_new_by_name(const char *name); /* connect to an already established QMP session */ QMPContext *qmp_context_new_by_fd(int fd); QMPContext *qmp_context_new_by_iops(QMPIOOps *ops); libvirt could use qmp_context_new_by_iops() to implement a virQemuGetQMP(). It can support this either by having a second QMP connection or even by parsing the QMP traffic and relaying commands over it QMP session (which gives it a chance to snoop on anything it's interested in). I think the former approach is less difficult technically. We can certainly make it easier to create dynamic QMP sessions. but the two main ideas are: 1. We don't do management I really believe we need to stop thinking this way. I'm not saying that qemu-devel is the place where we design virt-manager, but we ought to consider the whole stack as part of we. I really think what we want is for a libvirt user to be able to call libqemu functions directly. There shouldn't have to be libvirt specific functions for every operation we expose. Not sure if this is too crazy but, considering this user wants to use qemu features not implemented by libvirt yet, what about using both libqmp (above) and libvirt at the same time? Yes, that's *exactly* what I want. Except I want to call it libqemu because qmp is an implementation detail. Regards, Anthony Liguori
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On 03/25/2010 08:48 AM, Avi Kivity wrote: But an awful lot of the providers for pegasus are written in C. But we're concerned with only one, the virt provider. None of the others will use libqemu? The point is, C is a lowest common denominator and it's important to support in a proper way. Problem is, it means horrible support for everyone else. Why? We can provide a generic QMP dispatch interface that high level languages can use. Then they can do fancy dispatch, treat QErrors as exceptions, etc. We just ought to also provide some simple C wrappers for all of the functions. Yes, the C interface is inferior to the generic interface but that's fine. Regards, Anthony Liguori
[Qemu-devel] [PATCH] balloon: Fix overflow when reporting actual memory size
Beginning with its introduction, the virtio balloon has had an overflow error
that causes 'info balloon' to misreport the actual memory size when the balloon
itself becomes larger than 4G. Use a cast when converting dev-actual from
pages to kB to prevent overflows.
Before:
(qemu) info balloon
balloon: actual=5120
(qemu) balloon 1025
(qemu) info balloon
balloon: actual=1025
(qemu) balloon 1024
(qemu) info balloon
balloon: actual=5120
After:
(qemu) info balloon
balloon: actual=5120
(qemu) balloon 1025
(qemu) info balloon
balloon: actual=1025
(qemu) balloon 1024
(qemu) info balloon
balloon: actual=1024
Signed-off-by: Adam Litke a...@us.ibm.com
---
hw/virtio-balloon.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/hw/virtio-balloon.c b/hw/virtio-balloon.c
index 086d9d1..6eedab1 100644
--- a/hw/virtio-balloon.c
+++ b/hw/virtio-balloon.c
@@ -78,7 +78,8 @@ static void stat_put(QDict *dict, const char *label, uint64_t
val)
static QObject *get_stats_qobject(VirtIOBalloon *dev)
{
QDict *dict = qdict_new();
-uint32_t actual = ram_size - (dev-actual VIRTIO_BALLOON_PFN_SHIFT);
+uint64_t actual = ram_size - ((uint64_t) dev-actual
+ VIRTIO_BALLOON_PFN_SHIFT);
stat_put(dict, actual, actual);
stat_put(dict, mem_swapped_in, dev-stats[VIRTIO_BALLOON_S_SWAP_IN]);
--
1.6.3.3
[Qemu-devel] [PATCH 2/3] S390: Tell user why VM creation failed
The KVM kernel module on S390 refuses to create a VM when the switch_amode
kernel parameter is not used.
Since that is not exactly obvious, let's give the user a nice warning.
Signed-off-by: Alexander Graf ag...@suse.de
---
kvm-all.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 534ead0..acf7e31 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -609,8 +609,13 @@ int kvm_init(int smp_cpus)
}
s-vmfd = kvm_ioctl(s, KVM_CREATE_VM, 0);
-if (s-vmfd 0)
+if (s-vmfd 0) {
+#ifdef TARGET_S390X
+fprintf(stderr, Please add the 'switch_amode' kernel parameter to
+your host kernel command line\n);
+#endif
goto err;
+}
/* initially, KVM allocated its own memory and we had to jump through
* hooks to make phys_ram_base point to this. Modern versions of KVM
--
1.6.0.2
[Qemu-devel] [PATCH 3/3] S390: Don't compile in virtio-pci
As soon as virtio-pci.c gets compiled and used on S390 the internal qdev magic gets confused and tries to give us PCI devices instead of S390 virtio devices. Since we don't have PCI on S390, we can safely not compile virtio-pci at all. In order to do this I added a new config option CONFIG_VIRTIO_PCI that I enabled for every platform except S390. Thanks to this the change should be a complete nop for every other platform. Signed-off-by: Alexander Graf ag...@suse.de --- v1 - v2: - change option to CONFIG_VIRTIO_CPI --- Makefile.objs |3 ++- default-configs/arm-softmmu.mak|1 + default-configs/cris-softmmu.mak |1 + default-configs/i386-softmmu.mak |1 + default-configs/m68k-softmmu.mak |1 + default-configs/microblaze-softmmu.mak |1 + default-configs/mips-softmmu.mak |1 + default-configs/mips64-softmmu.mak |1 + default-configs/mips64el-softmmu.mak |1 + default-configs/mipsel-softmmu.mak |1 + default-configs/ppc-softmmu.mak|1 + default-configs/ppc64-softmmu.mak |1 + default-configs/ppcemb-softmmu.mak |1 + default-configs/sh4-softmmu.mak|1 + default-configs/sh4eb-softmmu.mak |1 + default-configs/sparc-softmmu.mak |1 + default-configs/sparc64-softmmu.mak|1 + default-configs/x86_64-softmmu.mak |1 + 18 files changed, 19 insertions(+), 1 deletions(-) diff --git a/Makefile.objs b/Makefile.objs index 281f7a6..8891931 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -128,7 +128,8 @@ user-obj-y += cutils.o cache-utils.o hw-obj-y = hw-obj-y += loader.o -hw-obj-y += virtio.o virtio-console.o virtio-pci.o +hw-obj-y += virtio.o virtio-console.o +hw-obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o hw-obj-y += fw_cfg.o pci.o pci_host.o pcie_host.o hw-obj-y += watchdog.o hw-obj-$(CONFIG_ISA_MMIO) += isa_mmio.o diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak index 02ad192..2f6ab11 100644 --- a/default-configs/arm-softmmu.mak +++ b/default-configs/arm-softmmu.mak @@ -24,3 +24,4 @@ CONFIG_SSI_SD=y CONFIG_LAN9118=y CONFIG_SMC91C111=y CONFIG_DS1338=y +CONFIG_VIRTIO_PCI=y diff --git a/default-configs/cris-softmmu.mak b/default-configs/cris-softmmu.mak index 8711402..b8c281b 100644 --- a/default-configs/cris-softmmu.mak +++ b/default-configs/cris-softmmu.mak @@ -2,3 +2,4 @@ CONFIG_NAND=y CONFIG_PTIMER=y +CONFIG_VIRTIO_PCI=y diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak index 4dbf656..136ce16 100644 --- a/default-configs/i386-softmmu.mak +++ b/default-configs/i386-softmmu.mak @@ -16,3 +16,4 @@ CONFIG_IDE_PIIX=y CONFIG_NE2000_ISA=y CONFIG_PIIX_PCI=y CONFIG_SOUND=y +CONFIG_VIRTIO_PCI=y diff --git a/default-configs/m68k-softmmu.mak b/default-configs/m68k-softmmu.mak index 0a78375..69ca3ed 100644 --- a/default-configs/m68k-softmmu.mak +++ b/default-configs/m68k-softmmu.mak @@ -2,3 +2,4 @@ CONFIG_GDBSTUB_XML=y CONFIG_PTIMER=y +CONFIG_VIRTIO_PCI=y diff --git a/default-configs/microblaze-softmmu.mak b/default-configs/microblaze-softmmu.mak index c800c16..4a70526 100644 --- a/default-configs/microblaze-softmmu.mak +++ b/default-configs/microblaze-softmmu.mak @@ -1,3 +1,4 @@ # Default configuration for microblaze-softmmu CONFIG_PTIMER=y +CONFIG_VIRTIO_PCI=y diff --git a/default-configs/mips-softmmu.mak b/default-configs/mips-softmmu.mak index 345a093..8ef1c04 100644 --- a/default-configs/mips-softmmu.mak +++ b/default-configs/mips-softmmu.mak @@ -16,3 +16,4 @@ CONFIG_IDE_ISA=y CONFIG_IDE_PIIX=y CONFIG_NE2000_ISA=y CONFIG_SOUND=y +CONFIG_VIRTIO_PCI=y diff --git a/default-configs/mips64-softmmu.mak b/default-configs/mips64-softmmu.mak index 5900ee6..d72299a 100644 --- a/default-configs/mips64-softmmu.mak +++ b/default-configs/mips64-softmmu.mak @@ -16,3 +16,4 @@ CONFIG_IDE_ISA=y CONFIG_IDE_PIIX=y CONFIG_NE2000_ISA=y CONFIG_SOUND=y +CONFIG_VIRTIO_PCI=y diff --git a/default-configs/mips64el-softmmu.mak b/default-configs/mips64el-softmmu.mak index 3e1ba93..8127cfb 100644 --- a/default-configs/mips64el-softmmu.mak +++ b/default-configs/mips64el-softmmu.mak @@ -16,3 +16,4 @@ CONFIG_IDE_ISA=y CONFIG_IDE_PIIX=y CONFIG_NE2000_ISA=y CONFIG_SOUND=y +CONFIG_VIRTIO_PCI=y diff --git a/default-configs/mipsel-softmmu.mak b/default-configs/mipsel-softmmu.mak index 17b83d0..9747f15 100644 --- a/default-configs/mipsel-softmmu.mak +++ b/default-configs/mipsel-softmmu.mak @@ -16,3 +16,4 @@ CONFIG_IDE_ISA=y CONFIG_IDE_PIIX=y CONFIG_NE2000_ISA=y CONFIG_SOUND=y +CONFIG_VIRTIO_PCI=y diff --git a/default-configs/ppc-softmmu.mak b/default-configs/ppc-softmmu.mak index 5fe591c..1865b0b 100644 --- a/default-configs/ppc-softmmu.mak +++ b/default-configs/ppc-softmmu.mak @@ -15,3 +15,4 @@ CONFIG_IDE_ISA=y CONFIG_IDE_CMD646=y CONFIG_NE2000_ISA=y CONFIG_SOUND=y +CONFIG_VIRTIO_PCI=y diff --git a/default-configs/ppc64-softmmu.mak b/default-configs/ppc64-softmmu.mak index
[Qemu-devel] [PATCH 0/3] Fix S390x target v2
We're in a bad situation with the S390 qemu target. It only works with KVM, so people can't test it when they don't have access to a real S390 machine. While trying to build and use s390x-softmmu again I stumbled across a couple of issues, all addressed in this patch set. The patches should all not affect non-s390 targets at all. v1 - v2: - change CONFIG_PCI to CONFIG_VIRTIO_PCI Alexander Graf (3): S390: Add stub for cpu_get_phys_page_debug S390: Tell user why VM creation failed S390: Don't compile in virtio-pci Makefile.objs |3 ++- default-configs/arm-softmmu.mak|1 + default-configs/cris-softmmu.mak |1 + default-configs/i386-softmmu.mak |1 + default-configs/m68k-softmmu.mak |1 + default-configs/microblaze-softmmu.mak |1 + default-configs/mips-softmmu.mak |1 + default-configs/mips64-softmmu.mak |1 + default-configs/mips64el-softmmu.mak |1 + default-configs/mipsel-softmmu.mak |1 + default-configs/ppc-softmmu.mak|1 + default-configs/ppc64-softmmu.mak |1 + default-configs/ppcemb-softmmu.mak |1 + default-configs/sh4-softmmu.mak|1 + default-configs/sh4eb-softmmu.mak |1 + default-configs/sparc-softmmu.mak |1 + default-configs/sparc64-softmmu.mak|1 + default-configs/x86_64-softmmu.mak |1 + kvm-all.c |7 ++- target-s390x/helper.c |5 + 20 files changed, 30 insertions(+), 2 deletions(-)
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On Thu, Mar 25, 2010 at 08:26:09AM +, Vincent Hanquez wrote: On 24/03/10 21:40, Anthony Liguori wrote: If so, what C clients you expected beyond libvirt? Users want a C API. I don't agree that libvirt is the only C interface consumer out there. (I've seen this written too many times ...) How do you know that ? did you do a poll or something where *actual* users vote/tell ? From my point of view, i wouldn't want to write a high level management toolstack in C, specially since the API is well defined JSON which is easily available in all high level language out there. It was pretty straightforward for libvirt to talk to the JSON protocol from C using the YAJL library, so I don't think it is all that much of a barrier for low level languages like C either. If we want to make life easy for app/library developers working against QEMU, then the far more important aspect is to guarentee stability of all the QEMU interfaces since that is where all the serious pain occurs over time. 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] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On Thu, 25 Mar 2010 08:57:36 -0500 Anthony Liguori anth...@codemonkey.ws wrote: On 03/25/2010 08:48 AM, Avi Kivity wrote: But an awful lot of the providers for pegasus are written in C. But we're concerned with only one, the virt provider. None of the others will use libqemu? The point is, C is a lowest common denominator and it's important to support in a proper way. Problem is, it means horrible support for everyone else. Why? Because it's useless for non C clients. QMP is language independent, libqemu is a full machinery for C clients only. We can provide a generic QMP dispatch interface that high level languages can use. Then they can do fancy dispatch, treat QErrors as exceptions, etc. They can do that by accessing QMP directly. Why would a Python developer get in the mess of writing a Python binding for libqemu if they call do the exactly same thing by using its native json module? Man, opening a QMP connection from Python and sending commands can be done with a few lines. We just ought to also provide some simple C wrappers for all of the functions. Yes, the C interface is inferior to the generic interface but that's fine. Why don't we start with my simple lib suggestion and wait one or two releases to see what happens?
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On 03/25/2010 03:57 PM, Anthony Liguori wrote: On 03/25/2010 08:48 AM, Avi Kivity wrote: But an awful lot of the providers for pegasus are written in C. But we're concerned with only one, the virt provider. None of the others will use libqemu? The point is, C is a lowest common denominator and it's important to support in a proper way. Problem is, it means horrible support for everyone else. Why? We can provide a generic QMP dispatch interface that high level languages can use. Then they can do fancy dispatch, treat QErrors as exceptions, etc. Sure, with high level wrappers everything's fine. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On Thu, Mar 25, 2010 at 08:57:36AM -0500, Anthony Liguori wrote: Why? We can provide a generic QMP dispatch interface that high level languages can use. Then they can do fancy dispatch, treat QErrors as exceptions, etc. Because more than likely it will be more efforts than doing the same work in the native language, forcing certains designs [1] up to high-level-language developers throats, and possibly less stability (segfault, memory corruption, memory leak, ..) specially in development phase. [1] lack of separation between IO and pure functions, file descriptor versus stream, C memory functions instead of GC based, and probably lots of other things easily accessible from high level language. -- Vincent
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On Thu, Mar 25, 2010 at 02:56:52PM +, Vincent Hanquez wrote: On Thu, Mar 25, 2010 at 01:59:22PM +, Daniel P. Berrange wrote: From my point of view, i wouldn't want to write a high level management toolstack in C, specially since the API is well defined JSON which is easily available in all high level language out there. It was pretty straightforward for libvirt to talk to the JSON protocol from C using the YAJL library, so I don't think it is all that much of a barrier for low level languages like C either. note, that it's not the talking JSON part that's difficult to do in C (it's just midly annoying compare to a highlevel language), but all the other part of a toolstack. Since there's no performance requirements, writing in C is just a bit of a waste ot time, but that's up to the developpers to choose the tools he wants, even if it's not the most appropriate one ;) If we want to make life easy for app/library developers working against QEMU, then the far more important aspect is to guarentee stability of all the QEMU interfaces since that is where all the serious pain occurs over time. if you're talking about the QMP interface then I agree with you. This need to be back/forward compatible as much as possible and stable. the other interface (i.e. the user monitor) has no business beeing backward-compatible though, since it should never be used to talk a RPC. I agree apps shouldn't use it for RPC, but admins using the interactive user monitor are just as deserving of stable commands args. 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] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On Thu, Mar 25, 2010 at 03:07:20PM +, Daniel P. Berrange wrote: I agree apps shouldn't use it for RPC, but admins using the interactive user monitor are just as deserving of stable commands args. I think, once QMP is completely there, admins would be better using a qemu-cmd that's just serialise it's command line arguments into a JSON command. (something like dbus-send for dbus). -- Vincent
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On Thu, Mar 25, 2010 at 03:14:24PM +, Vincent Hanquez wrote: On Thu, Mar 25, 2010 at 03:07:20PM +, Daniel P. Berrange wrote: I agree apps shouldn't use it for RPC, but admins using the interactive user monitor are just as deserving of stable commands args. I think, once QMP is completely there, admins would be better using a qemu-cmd that's just serialise it's command line arguments into a JSON command. Then, after a qemu-cmd is introduced, we should mark the user monitor deprecated along with a specific date/release its future for removal. 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 09/10] target-alpha: Implement load-locked/store-conditional properly.
On 03/25/2010 06:39 AM, Nathan Froyd wrote: On Wed, Mar 24, 2010 at 05:11:43PM -0700, Richard Henderson wrote: Use __sync_bool_compare_and_swap to yield correctly atomic results. As yet, this assumes running on an strict-memory-ordering host (i.e. x86), since we're still implementing the memory-barrier instructions as nops. Did the approach taken by other targets (arm/mips/ppc) not work on Alpha? Mips doesn't even pretend to be atomic. Powerpc and Arm -- if I've got this straight -- use some sort of stop-the-world mutex+condition and then perform the compare-and-exchange by hand. I can't see how that's better than using an actual compare-and-exchange provided by the host cpu. In fact, I'm mildly horrified by the prospect. Honestly. Even ARM and HPPA which doesn't (always) natively have cmpxchg, have an easy to use kernel trap to perform the operation. I suppose real 80386 and sparc-pre-v9 don't have anything particularly useful, but frankly it wouldn't bother me to deprecate them as hosts since the modern editions all do work. r~
[Qemu-devel] Re: [PATCH] update bochs vbe interface
On 03/25/10 13:14, Juan Quintela wrote: Gerd Hoffmannkra...@redhat.com wrote: Hi, Then our big problem is migration between read of the 1st register and of the 2nd register, no? big? That is why I asked. I have no clue about how many times that register is read. Once at boot. If it is only read during startup, once, I think that geting 0 size is ok. Extra bonus for modifying vgabios to handle this case nicely? I doubt it is worth the trouble. Also note that the current qemu vgabios doesn't care at all. It matters once we actually update vgabios to 0.6c. cheers, Gerd
[Qemu-devel] Re: [PATCH v2 11/11] monitor: New commands netdev_add, netdev_del
Luiz Capitulino lcapitul...@redhat.com writes: On Mon, 22 Mar 2010 10:48:53 +0100 Markus Armbruster arm...@redhat.com wrote: Monitor commands to go with -netdev. Signed-off-by: Markus Armbruster arm...@redhat.com --- net.c | 57 ++- net.h |2 + qemu-monitor.hx | 30 3 files changed, 88 insertions(+), 1 deletions(-) diff --git a/net.c b/net.c index 1f3c39c..80e9025 100644 --- a/net.c +++ b/net.c @@ -1122,7 +1122,7 @@ int net_client_init(Monitor *mon, QemuOpts *opts, int is_netdev) } qerror_report(QERR_INVALID_PARAMETER_VALUE, type, - a network backend type); + a network client type); return -1; } @@ -1186,6 +1186,61 @@ void net_host_device_remove(Monitor *mon, const QDict *qdict) qemu_del_vlan_client(vc); } +/** + * do_netdev_add(): Add a host network device + * + * Argument qdict contains + * - type: the device type, tap, user, ... + * - id: the device's ID (must be unique) Consecutive calls of this command in qmp with the same id succeeds, but I couldn't understand why. Thinko. I'll respin. Other than that looks ok, although I'm not familiar with the device handling machinery in qemu. v3's the charm, I hope. Thanks! [...]
Re: [Qemu-devel] [PATCH] Fix 64-bit off_t syscall argument passing in linux-user
On 03/25/2010 02:04 AM, Tomasz Łukaszewski wrote:
+#if TARGET_ABI_BITS == 32
+#ifdef TARGET_ARM
+if (((CPUARMState *)cpu_env)-eabi)
+ {
+arg4 = arg5;
+arg5 = arg6;
+ }
+#endif
+#if defined TARGET_PPC || defined TARGET_MIPS
+arg4 = arg5;
+arg5 = arg6;
+#endif
+#endif
I wonder if this sequence couldn't be encapsulated in a macro. Something like
#if TARGET_ABI_BITS == 32
# if defined TARGET_ARM
# define FIXUP_64BIT_ARGUMENT_PAIR(a,b,c) \
do { \
if (((CPUARMState *)cpu_env)-eabi) { \
a = b, b = c; \
} \
} while (0)
# elif defined TARGET_PPC || defined TARGET_MIPS
# define FIXUP_64BIT_ARGUMENT_PAIR(a,b,c) \
do { a = b, b = c; } while (0)
# endif
#endif
#ifndef FIXUP_64BIT_ARGUMENT_PAIR
# define FIXUP_64BIT_ARGUMENT_PAIR(a,b,c) \
do { } while (0)
#endif
r~
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On 03/25/2010 09:09 AM, Luiz Capitulino wrote: We can provide a generic QMP dispatch interface that high level languages can use. Then they can do fancy dispatch, treat QErrors as exceptions, etc. They can do that by accessing QMP directly. Why would a Python developer get in the mess of writing a Python binding for libqemu if they call do the exactly same thing by using its native json module? Man, opening a QMP connection from Python and sending commands can be done with a few lines. Problem is, without a libqemu, libvirt cannot return a QMPContext that can be used by python bindings. This is the problem that all high level languages have with respect to RPC transports. You need libqemu to deal with establishing the transport. That code needs to be common and shared across languages. Dispatch can be handled by the high level language. We just ought to also provide some simple C wrappers for all of the functions. Yes, the C interface is inferior to the generic interface but that's fine. Why don't we start with my simple lib suggestion and wait one or two releases to see what happens? I have no problem starting without the generated C wrappers. But we need the core library to have the right abstractions with respect to transports. Regards, Anthony Liguori
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On 03/25/2010 10:16 AM, Daniel P. Berrange wrote: On Thu, Mar 25, 2010 at 03:14:24PM +, Vincent Hanquez wrote: On Thu, Mar 25, 2010 at 03:07:20PM +, Daniel P. Berrange wrote: I agree apps shouldn't use it for RPC, but admins using the interactive user monitor are just as deserving of stable commands args. I think, once QMP is completely there, admins would be better using a qemu-cmd that's just serialise it's command line arguments into a JSON command. Then, after a qemu-cmd is introduced, we should mark the user monitor deprecated along with a specific date/release its future for removal. I'm not sure. The human monitor has some features that are not appropriate for QMP. For instance, the ability to deal with formula input and some commands meant to add debugging. I guess you could do that in qemu-cmd but I don't see a compelling reason to. Regards, Anthony Liguori Daniel
Re: [Qemu-devel] [PATCH 09/10] target-alpha: Implement load-locked/store-conditional properly.
On Thu, Mar 25, 2010 at 08:46:06AM -0700, Richard Henderson wrote: On 03/25/2010 06:39 AM, Nathan Froyd wrote: On Wed, Mar 24, 2010 at 05:11:43PM -0700, Richard Henderson wrote: Use __sync_bool_compare_and_swap to yield correctly atomic results. As yet, this assumes running on an strict-memory-ordering host (i.e. x86), since we're still implementing the memory-barrier instructions as nops. Did the approach taken by other targets (arm/mips/ppc) not work on Alpha? Mips doesn't even pretend to be atomic. It pretends just as much as ppc and arm. See translate.c:OP_ST_ATOMIC. Powerpc and Arm -- if I've got this straight -- use some sort of stop-the-world mutex+condition and then perform the compare-and-exchange by hand. I can't see how that's better than using an actual compare-and-exchange provided by the host cpu. In fact, I'm mildly horrified by the prospect. Oh, I didn't say it was pretty. But it does work fairly well in practice--enough to pass most of glibc's NPTL testsuite, for instance. (The remaining cases are tricky things, like cross-process locks.) I think--though Paul would remember better than I--that the stop-the-world approach might have been taken due to a desire to continue compiling with gcc 4.1. I don't know how much of a desdirata that still is. (stop-the-world is also somewhat less complex than the previous implementation, which involved page protection games.) Certainly using actual compare-and-exchange would be much faster. -Nathan
Re: WIP flush-to-zero patch [was: Re: [Qemu-devel] QEMU state of ARM NEON support.]
On 03/25/2010 07:00 AM, Nathan Froyd wrote: FWIW, below is a WIP progress patch to implement flush-to-zero better. The motivating observation is that many chips feature separate flush-input and flush-output flags and QEMU's fpu/ library only implements flush-output. So the bulk of the patch is: - replacing the ad-hoc unpacking of float values into (sign, exponent, significand) with a centralized routine that will apply flush-to-zero on input values; - splitting float_status.flush_to_zero into separate input/output flags; - modifying targets to set input/output flags appropriately. Excellent. This should allow me to clean up the Alpha port a bit. Specifically wrt helper_ieee_input*. r~
[Qemu-devel] Re: [PATCH v3 0/2] Inter-VM shared memory PCI device
On Thu, Mar 25, 2010 at 3:21 AM, Michael S. Tsirkin m...@redhat.com wrote: On Thu, Mar 25, 2010 at 11:04:54AM +0200, Avi Kivity wrote: Again, I recommend Rusty's virtio-pci for inspiration. Not just inspiration, how about building on virtio-pci? Virtio was discussed at good length last year on a previous version. I did implement a virtio version that extended virtio to use memory regions for importing host memory into a guest. http://www.mail-archive.com/qemu-devel@nongnu.org/msg25784.html However, Anthony thought the memory regions broke the DMA engine model of virtio too much and so I went back to PCI. Cam -- MST
[Qemu-devel] Re: [PATCH v3 1/1] Shared memory uio_pci driver
On Thu, Mar 25, 2010 at 3:15 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Mar 25, 2010 at 12:09:36AM -0600, Cam Macdonell wrote:
This patch adds a driver for my shared memory PCI device using the uio_pci
interface. The driver has three memory regions. The first memory region is
for
device registers for sending interrupts. The second BAR is for receiving
MSI-X
interrupts and the third memory region maps the shared memory. The device
only
exports the first and third memory regions to userspace.
This driver supports MSI-X and regular pin interrupts. Currently, the
number of
MSI vectors is set to 4 which could be increased, but the driver will work
with
fewer vectors. If MSI is not available, then regular interrupts will be
used.
Some high level questions, sorry if they have been raised in the past:
- Can this device use virtio framework?
This gives us some standards to work off, with feature negotiation,
ability to detect config changes, support for non-PCI
platforms, decent documentation that is easy to extend,
legal id range to use.
You would thus have your driver in uio/uio_virtio_shmem.c
There has been previous discussion of virtio, however while virtio is
good for exporting guest memory, it's not ideal for importing memory
into a guest.
- Why are you using 32 bit long memory accesses for interrupts?
16 bit IO eould be enough and it's faster. This what virtio-pci does.
- How was the driver tested?
I have some test programs in the git repo I linked to. I've been
using some simple producer/consumer tests to test the interrupt
framework.
---
drivers/uio/Kconfig | 8 ++
drivers/uio/Makefile | 1 +
drivers/uio/uio_ivshmem.c | 235
+
3 files changed, 244 insertions(+), 0 deletions(-)
create mode 100644 drivers/uio/uio_ivshmem.c
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 1da73ec..b92cded 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -74,6 +74,14 @@ config UIO_SERCOS3
If you compile this as a module, it will be called uio_sercos3.
+config UIO_IVSHMEM
+ tristate KVM shared memory PCI driver
+ default n
+ help
+ Userspace I/O interface for the KVM shared memory device. This
+ driver will make available two memory regions, the first is
+ registers and the second is a region for sharing between VMs.
+
config UIO_PCI_GENERIC
tristate Generic driver for PCI 2.3 and PCI Express cards
depends on PCI
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index 18fd818..25c1ca5 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_UIO_AEC) += uio_aec.o
obj-$(CONFIG_UIO_SERCOS3) += uio_sercos3.o
obj-$(CONFIG_UIO_PCI_GENERIC) += uio_pci_generic.o
obj-$(CONFIG_UIO_NETX) += uio_netx.o
+obj-$(CONFIG_UIO_IVSHMEM) += uio_ivshmem.o
diff --git a/drivers/uio/uio_ivshmem.c b/drivers/uio/uio_ivshmem.c
new file mode 100644
index 000..607435b
--- /dev/null
+++ b/drivers/uio/uio_ivshmem.c
@@ -0,0 +1,235 @@
+/*
+ * UIO IVShmem Driver
+ *
+ * (C) 2009 Cam Macdonell
+ * based on Hilscher CIF card driver (C) 2007 Hans J. Koch
h...@linutronix.de
+ *
+ * Licensed under GPL version 2 only.
+ *
+ */
+
+#include linux/device.h
+#include linux/module.h
+#include linux/pci.h
+#include linux/uio_driver.h
+
+#include asm/io.h
+
+#define IntrStatus 0x04
+#define IntrMask 0x00
+
+struct ivshmem_info {
+ struct uio_info *uio;
+ struct pci_dev *dev;
+ char (*msix_names)[256];
+ struct msix_entry *msix_entries;
+ int nvectors;
+};
+
+static irqreturn_t ivshmem_handler(int irq, struct uio_info *dev_info)
+{
+
+ void __iomem *plx_intscr = dev_info-mem[0].internal_addr
+ + IntrStatus;
+ u32 val;
+
+ val = readl(plx_intscr);
+ if (val == 0)
+ return IRQ_NONE;
+
+ printk(KERN_INFO Regular interrupt (val = %d)\n, val);
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t ivshmem_msix_handler(int irq, void *opaque)
+{
+
+ struct uio_info * dev_info = (struct uio_info *) opaque;
+
+ /* we have to do this explicitly when using MSI-X */
+ uio_event_notify(dev_info);
+ printk(KERN_INFO MSI-X interrupt (%d)\n, irq);
+ return IRQ_HANDLED;
+
+}
+
+static int request_msix_vectors(struct ivshmem_info *ivs_info, int nvectors)
+{
+ int i, err;
+ const char *name = ivshmem;
+
+ printk(KERN_INFO devname is %s\n, name);
+ ivs_info-nvectors = nvectors;
+
+
+ ivs_info-msix_entries = kmalloc(nvectors * sizeof
*ivs_info-msix_entries,
+ GFP_KERNEL);
+ ivs_info-msix_names = kmalloc(nvectors * sizeof *ivs_info-msix_names,
+ GFP_KERNEL);
+
+ for (i = 0; i nvectors; ++i)
+ ivs_info-msix_entries[i].entry = i;
+
+ err = pci_enable_msix(ivs_info-dev, ivs_info-msix_entries,
+
[Qemu-devel] [PATCH v3 04/11] error: New QERR_INVALID_PARAMETER_VALUE
Signed-off-by: Markus Armbruster arm...@redhat.com
---
qerror.c |4
qerror.h |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index 9fb817e..97e8d4a 100644
--- a/qerror.c
+++ b/qerror.c
@@ -121,6 +121,10 @@ static const QErrorStringTable qerror_table[] = {
.desc = Invalid parameter type, expected: %(expected),
},
{
+.error_fmt = QERR_INVALID_PARAMETER_VALUE,
+.desc = Parameter '%(name)' expects %(expected),
+},
+{
.error_fmt = QERR_INVALID_PASSWORD,
.desc = Password incorrect,
},
diff --git a/qerror.h b/qerror.h
index 870cdc3..5625d54 100644
--- a/qerror.h
+++ b/qerror.h
@@ -106,6 +106,9 @@ QError *qobject_to_qerror(const QObject *obj);
#define QERR_INVALID_PARAMETER_TYPE \
{ 'class': 'InvalidParameterType', 'data': { 'name': %s,'expected': %s }
}
+#define QERR_INVALID_PARAMETER_VALUE \
+{ 'class': 'InvalidParameterValue', 'data': { 'name': %s, 'expected': %s
} }
+
#define QERR_INVALID_PASSWORD \
{ 'class': 'InvalidPassword', 'data': {} }
--
1.6.6.1
[Qemu-devel] [PATCH v3 00/11] monitor: New commands netdev_add, netdev_del
v2: Avoid loss of help in parse_option_size(). Rebased. v3: Fix detection of duplicate netdev id. Markus Armbruster (11): error: Put error definitions back in alphabetical order error: New QERR_DUPLICATE_ID error: Convert qemu_opts_create() to QError error: New QERR_INVALID_PARAMETER_VALUE error: Convert qemu_opts_set() to QError error: Drop extra messages after qemu_opts_set() and qemu_opts_parse() error: Use QERR_INVALID_PARAMETER_VALUE instead of QERR_INVALID_PARAMETER error: Convert qemu_opts_validate() to QError error: Convert net_client_init() to QError error: New QERR_DEVICE_IN_USE monitor: New commands netdev_add, netdev_del hw/pci-hotplug.c |2 - hw/qdev.c|2 +- monitor.c|6 ++- net.c| 95 + net.h|2 + qemu-config.c|1 - qemu-monitor.hx | 30 + qemu-option.c| 24 ++ qerror.c | 20 ++- qerror.h | 17 -- vl.c |5 --- 11 files changed, 152 insertions(+), 52 deletions(-)
[Qemu-devel] [PATCH v3 02/11] error: New QERR_DUPLICATE_ID
Signed-off-by: Markus Armbruster arm...@redhat.com
---
qerror.c |4
qerror.h |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index 4520b0d..9fb817e 100644
--- a/qerror.c
+++ b/qerror.c
@@ -97,6 +97,10 @@ static const QErrorStringTable qerror_table[] = {
.desc = Device '%(device)' has no child bus,
},
{
+.error_fmt = QERR_DUPLICATE_ID,
+.desc = Duplicate ID '%(id)' for %(object),
+},
+{
.error_fmt = QERR_FD_NOT_FOUND,
.desc = File descriptor named '%(name)' not found,
},
diff --git a/qerror.h b/qerror.h
index a2664ab..870cdc3 100644
--- a/qerror.h
+++ b/qerror.h
@@ -88,6 +88,9 @@ QError *qobject_to_qerror(const QObject *obj);
#define QERR_DEVICE_NO_BUS \
{ 'class': 'DeviceNoBus', 'data': { 'device': %s } }
+#define QERR_DUPLICATE_ID \
+{ 'class': 'DuplicateId', 'data': { 'id': %s, 'object': %s } }
+
#define QERR_FD_NOT_FOUND \
{ 'class': 'FdNotFound', 'data': { 'name': %s } }
--
1.6.6.1
[Qemu-devel] [PATCH v3 03/11] error: Convert qemu_opts_create() to QError
Fixes device_add to report duplicate ID properly in QMP, as
DuplicateId instead of UndefinedError.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
qemu-option.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/qemu-option.c b/qemu-option.c
index f83d07c..12ce322 100644
--- a/qemu-option.c
+++ b/qemu-option.c
@@ -30,6 +30,7 @@
#include qemu-error.h
#include qemu-objects.h
#include qemu-option.h
+#include qerror.h
/*
* Extracts the name of an option from the parameter string (p points at the
@@ -643,8 +644,7 @@ QemuOpts *qemu_opts_create(QemuOptsList *list, const char
*id, int fail_if_exist
opts = qemu_opts_find(list, id);
if (opts != NULL) {
if (fail_if_exists) {
-fprintf(stderr, tried to create id \%s\ twice for \%s\\n,
-id, list-name);
+qerror_report(QERR_DUPLICATE_ID, id, list-name);
return NULL;
} else {
return opts;
--
1.6.6.1
[Qemu-devel] [PATCH v3 01/11] error: Put error definitions back in alphabetical order
Add suitable comments to help keerp them in order.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
qerror.c | 12
qerror.h |8 +---
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/qerror.c b/qerror.c
index eaa1deb..4520b0d 100644
--- a/qerror.c
+++ b/qerror.c
@@ -38,6 +38,10 @@ static const QType qerror_type = {
* for example:
*
* running out of foo: %(foo)%%
+ *
+ * Please keep the entries in alphabetical order.
+ * Use sed -n '/^static.*qerror_table\[\]/,/^};/s/QERR_//gp' qerror.c | sort
-c
+ * to check.
*/
static const QErrorStringTable qerror_table[] = {
{
@@ -65,10 +69,6 @@ static const QErrorStringTable qerror_table[] = {
.desc = Device '%(device)' could not be initialized,
},
{
-.error_fmt = QERR_DEVICE_NOT_ENCRYPTED,
-.desc = Device '%(device)' is not encrypted,
-},
-{
.error_fmt = QERR_DEVICE_LOCKED,
.desc = Device '%(device)' is locked,
},
@@ -81,6 +81,10 @@ static const QErrorStringTable qerror_table[] = {
.desc = Device '%(device)' has not been activated by the guest,
},
{
+.error_fmt = QERR_DEVICE_NOT_ENCRYPTED,
+.desc = Device '%(device)' is not encrypted,
+},
+{
.error_fmt = QERR_DEVICE_NOT_FOUND,
.desc = Device '%(device)' not found,
},
diff --git a/qerror.h b/qerror.h
index dd298d4..a2664ab 100644
--- a/qerror.h
+++ b/qerror.h
@@ -46,6 +46,8 @@ QError *qobject_to_qerror(const QObject *obj);
/*
* QError class list
+ * Please keep the definitions in alphabetical order.
+ * Use grep '^#define QERR_' qerror.h | sort -c to check.
*/
#define QERR_BAD_BUS_FOR_DEVICE \
{ 'class': 'BadBusForDevice', 'data': { 'device': %s, 'bad_bus_type': %s
} }
@@ -62,9 +64,6 @@ QError *qobject_to_qerror(const QObject *obj);
#define QERR_DEVICE_ENCRYPTED \
{ 'class': 'DeviceEncrypted', 'data': { 'device': %s } }
-#define QERR_DEVICE_NOT_ENCRYPTED \
-{ 'class': 'DeviceNotEncrypted', 'data': { 'device': %s } }
-
#define QERR_DEVICE_INIT_FAILED \
{ 'class': 'DeviceInitFailed', 'data': { 'device': %s } }
@@ -77,6 +76,9 @@ QError *qobject_to_qerror(const QObject *obj);
#define QERR_DEVICE_NOT_ACTIVE \
{ 'class': 'DeviceNotActive', 'data': { 'device': %s } }
+#define QERR_DEVICE_NOT_ENCRYPTED \
+{ 'class': 'DeviceNotEncrypted', 'data': { 'device': %s } }
+
#define QERR_DEVICE_NOT_FOUND \
{ 'class': 'DeviceNotFound', 'data': { 'device': %s } }
--
1.6.6.1
[Qemu-devel] [PATCH v3 07/11] error: Use QERR_INVALID_PARAMETER_VALUE instead of QERR_INVALID_PARAMETER
Signed-off-by: Markus Armbruster arm...@redhat.com
---
hw/qdev.c |2 +-
monitor.c |6 --
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
index 17a46a7..f45ed0f 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -207,7 +207,7 @@ DeviceState *qdev_device_add(QemuOpts *opts)
/* find driver */
info = qdev_find_info(NULL, driver);
if (!info || info-no_user) {
-qerror_report(QERR_INVALID_PARAMETER, driver);
+qerror_report(QERR_INVALID_PARAMETER_VALUE, driver, a driver name);
error_printf_unless_qmp(Try with argument '?' for a list.\n);
return NULL;
}
diff --git a/monitor.c b/monitor.c
index 822dc27..35cbce7 100644
--- a/monitor.c
+++ b/monitor.c
@@ -970,7 +970,8 @@ static int do_cpu_set(Monitor *mon, const QDict *qdict,
QObject **ret_data)
{
int index = qdict_get_int(qdict, index);
if (mon_set_cpu(index) 0) {
-qerror_report(QERR_INVALID_PARAMETER, index);
+qerror_report(QERR_INVALID_PARAMETER_VALUE, index,
+ a CPU number);
return -1;
}
return 0;
@@ -2489,7 +2490,8 @@ static int do_getfd(Monitor *mon, const QDict *qdict,
QObject **ret_data)
}
if (qemu_isdigit(fdname[0])) {
-qerror_report(QERR_INVALID_PARAMETER, fdname);
+qerror_report(QERR_INVALID_PARAMETER_VALUE, fdname,
+ a name not starting with a digit);
return -1;
}
--
1.6.6.1
[Qemu-devel] [PATCH v3 08/11] error: Convert qemu_opts_validate() to QError
Signed-off-by: Markus Armbruster arm...@redhat.com
---
qemu-option.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/qemu-option.c b/qemu-option.c
index 394c763..1ffc497 100644
--- a/qemu-option.c
+++ b/qemu-option.c
@@ -877,8 +877,7 @@ int qemu_opts_validate(QemuOpts *opts, const QemuOptDesc
*desc)
}
}
if (desc[i].name == NULL) {
-fprintf(stderr, option \%s\ is not valid for %s\n,
-opt-name, opts-list-name);
+qerror_report(QERR_INVALID_PARAMETER, opt-name);
return -1;
}
--
1.6.6.1
[Qemu-devel] [PATCH v3 05/11] error: Convert qemu_opts_set() to QError
Signed-off-by: Markus Armbruster arm...@redhat.com
---
qemu-option.c | 17 +++--
1 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/qemu-option.c b/qemu-option.c
index 12ce322..394c763 100644
--- a/qemu-option.c
+++ b/qemu-option.c
@@ -176,7 +176,7 @@ static int parse_option_bool(const char *name, const char
*value, int *ret)
} else if (!strcmp(value, off)) {
*ret = 0;
} else {
-fprintf(stderr, Option '%s': Use 'on' or 'off'\n, name);
+qerror_report(QERR_INVALID_PARAMETER_VALUE, name, 'on' or 'off');
return -1;
}
} else {
@@ -193,12 +193,12 @@ static int parse_option_number(const char *name, const
char *value, uint64_t *re
if (value != NULL) {
number = strtoull(value, postfix, 0);
if (*postfix != '\0') {
-fprintf(stderr, Option '%s' needs a number as parameter\n, name);
+qerror_report(QERR_INVALID_PARAMETER_VALUE, name, a number);
return -1;
}
*ret = number;
} else {
-fprintf(stderr, Option '%s' needs a parameter\n, name);
+qerror_report(QERR_INVALID_PARAMETER_VALUE, name, a number);
return -1;
}
return 0;
@@ -226,13 +226,13 @@ static int parse_option_size(const char *name, const char
*value, uint64_t *ret)
*ret = (uint64_t) sizef;
break;
default:
-fprintf(stderr, Option '%s' needs size as parameter\n, name);
-fprintf(stderr, You may use k, M, G or T suffixes for
+qerror_report(QERR_INVALID_PARAMETER_VALUE, name, a size);
+error_printf_unless_qmp(You may use k, M, G or T suffixes for
kilobytes, megabytes, gigabytes and terabytes.\n);
return -1;
}
} else {
-fprintf(stderr, Option '%s' needs a parameter\n, name);
+qerror_report(QERR_INVALID_PARAMETER_VALUE, name, a size);
return -1;
}
return 0;
@@ -581,8 +581,7 @@ int qemu_opt_set(QemuOpts *opts, const char *name, const
char *value)
if (i == 0) {
/* empty list - allow any */;
} else {
-fprintf(stderr, option \%s\ is not valid for %s\n,
-name, opts-list-name);
+qerror_report(QERR_INVALID_PARAMETER, name);
return -1;
}
}
@@ -598,8 +597,6 @@ int qemu_opt_set(QemuOpts *opts, const char *name, const
char *value)
opt-str = qemu_strdup(value);
}
if (qemu_opt_parse(opt) 0) {
-fprintf(stderr, Failed to parse \%s\ for \%s.%s\\n, opt-str,
-opts-list-name, opt-name);
qemu_opt_del(opt);
return -1;
}
--
1.6.6.1
[Qemu-devel] [PATCH v3 11/11] monitor: New commands netdev_add, netdev_del
Monitor commands to go with -netdev.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
net.c | 55 +++
net.h |2 ++
qemu-monitor.hx | 30 ++
3 files changed, 87 insertions(+), 0 deletions(-)
diff --git a/net.c b/net.c
index 435997b..ae971ff 100644
--- a/net.c
+++ b/net.c
@@ -1186,6 +1186,61 @@ void net_host_device_remove(Monitor *mon, const QDict
*qdict)
qemu_del_vlan_client(vc);
}
+/**
+ * do_netdev_add(): Add a host network device
+ *
+ * Argument qdict contains
+ * - type: the device type, tap, user, ...
+ * - id: the device's ID (must be unique)
+ * - device options
+ *
+ * Example:
+ *
+ * { type: user, id: netdev1, hostname: a-guest }
+ */
+int do_netdev_add(Monitor *mon, const QDict *qdict, QObject **ret_data)
+{
+QemuOpts *opts;
+int res;
+
+opts = qemu_opts_from_qdict(qemu_netdev_opts, qdict);
+if (!opts) {
+return -1;
+}
+
+res = net_client_init(mon, opts, 1);
+return res;
+}
+
+/**
+ * do_netdev_del(): Delete a host network device
+ *
+ * Argument qdict contains
+ * - id: the device's ID
+ *
+ * Example:
+ *
+ * { id: netdev1 }
+ */
+int do_netdev_del(Monitor *mon, const QDict *qdict, QObject **ret_data)
+{
+const char *id = qdict_get_str(qdict, id);
+VLANClientState *vc;
+
+vc = qemu_find_netdev(id);
+if (!vc || vc-info-type == NET_CLIENT_TYPE_NIC) {
+qerror_report(QERR_DEVICE_NOT_FOUND, id);
+return -1;
+}
+if (vc-peer) {
+qerror_report(QERR_DEVICE_IN_USE, id);
+return -1;
+}
+qemu_del_vlan_client(vc);
+qemu_opts_del(qemu_opts_find(qemu_netdev_opts, id));
+return 0;
+}
+
void net_set_boot_mask(int net_boot_mask)
{
int i;
diff --git a/net.h b/net.h
index 16f19c5..ce9e2c6 100644
--- a/net.h
+++ b/net.h
@@ -166,6 +166,8 @@ void net_cleanup(void);
void net_set_boot_mask(int boot_mask);
void net_host_device_add(Monitor *mon, const QDict *qdict);
void net_host_device_remove(Monitor *mon, const QDict *qdict);
+int do_netdev_add(Monitor *mon, const QDict *qdict, QObject **ret_data);
+int do_netdev_del(Monitor *mon, const QDict *qdict, QObject **ret_data);
#define DEFAULT_NETWORK_SCRIPT /etc/qemu-ifup
#define DEFAULT_NETWORK_DOWN_SCRIPT /etc/qemu-ifdown
diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index 5308f36..ff5f099 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -913,6 +913,36 @@ STEXI
Remove host VLAN client.
ETEXI
+{
+.name = netdev_add,
+.args_type = netdev:O,
+.params = [user|tap|socket],id=str[,prop=value][,...],
+.help = add host network device,
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = do_netdev_add,
+},
+
+STEXI
+...@item netdev_add
+...@findex netdev_add
+Add host network device.
+ETEXI
+
+{
+.name = netdev_del,
+.args_type = id:s,
+.params = id,
+.help = remove host network device,
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = do_netdev_del,
+},
+
+STEXI
+...@item netdev_del
+...@findex netdev_del
+Remove host network device.
+ETEXI
+
#ifdef CONFIG_SLIRP
{
.name = hostfwd_add,
--
1.6.6.1
[Qemu-devel] [PATCH v3 06/11] error: Drop extra messages after qemu_opts_set() and qemu_opts_parse()
Both functions report errors nicely enough now, no need for additional
messages.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
hw/pci-hotplug.c |2 --
net.c|2 --
qemu-config.c|1 -
vl.c |5 -
4 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/hw/pci-hotplug.c b/hw/pci-hotplug.c
index eb3701b..343fd17 100644
--- a/hw/pci-hotplug.c
+++ b/hw/pci-hotplug.c
@@ -56,8 +56,6 @@ static PCIDevice *qemu_pci_hot_add_nic(Monitor *mon,
opts = qemu_opts_parse(qemu_net_opts, opts_str ? opts_str : , 0);
if (!opts) {
-monitor_printf(mon, parsing network options '%s' failed\n,
- opts_str ? opts_str : );
return NULL;
}
diff --git a/net.c b/net.c
index 1092bdc..9338f35 100644
--- a/net.c
+++ b/net.c
@@ -1161,8 +1161,6 @@ void net_host_device_add(Monitor *mon, const QDict *qdict)
opts = qemu_opts_parse(qemu_net_opts, opts_str ? opts_str : , 0);
if (!opts) {
-monitor_printf(mon, parsing network options '%s' failed\n,
- opts_str ? opts_str : );
return;
}
diff --git a/qemu-config.c b/qemu-config.c
index 150157c..d4a2f43 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -472,7 +472,6 @@ int qemu_config_parse(FILE *fp, const char *fname)
goto out;
}
if (qemu_opt_set(opts, arg, value) != 0) {
-error_report(failed to set \%s\ for %s, arg, group);
goto out;
}
continue;
diff --git a/vl.c b/vl.c
index d69250c..35ab34f 100644
--- a/vl.c
+++ b/vl.c
@@ -766,8 +766,6 @@ QemuOpts *drive_add(const char *file, const char *fmt, ...)
opts = qemu_opts_parse(qemu_drive_opts, optstr, 0);
if (!opts) {
-fprintf(stderr, %s: huh? duplicate? (%s)\n,
-__FUNCTION__, optstr);
return NULL;
}
if (file)
@@ -4244,7 +4242,6 @@ int main(int argc, char **argv, char **envp)
case QEMU_OPTION_mon:
opts = qemu_opts_parse(qemu_mon_opts, optarg, 1);
if (!opts) {
-fprintf(stderr, parse error: %s\n, optarg);
exit(1);
}
default_monitor = 0;
@@ -4252,7 +4249,6 @@ int main(int argc, char **argv, char **envp)
case QEMU_OPTION_chardev:
opts = qemu_opts_parse(qemu_chardev_opts, optarg, 1);
if (!opts) {
-fprintf(stderr, parse error: %s\n, optarg);
exit(1);
}
break;
@@ -4464,7 +4460,6 @@ int main(int argc, char **argv, char **envp)
case QEMU_OPTION_rtc:
opts = qemu_opts_parse(qemu_rtc_opts, optarg, 0);
if (!opts) {
-fprintf(stderr, parse error: %s\n, optarg);
exit(1);
}
configure_rtc(opts);
--
1.6.6.1
[Qemu-devel] [PATCH v3 09/11] error: Convert net_client_init() to QError
The conversion is shallow: client type init() methods aren't
converted. Converting them is a big job for relatively little
practical benefit, so leave it for later.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
net.c | 38 ++
1 files changed, 18 insertions(+), 20 deletions(-)
diff --git a/net.c b/net.c
index 9338f35..435997b 100644
--- a/net.c
+++ b/net.c
@@ -1057,18 +1057,12 @@ int net_client_init(Monitor *mon, QemuOpts *opts, int
is_netdev)
int i;
type = qemu_opt_get(opts, type);
+if (!type) {
+qerror_report(QERR_MISSING_PARAMETER, type);
+return -1;
+}
-if (!is_netdev) {
-if (!type) {
-error_report(No type specified for -net);
-return -1;
-}
-} else {
-if (!type) {
-error_report(No type specified for -netdev);
-return -1;
-}
-
+if (is_netdev) {
if (strcmp(type, tap) != 0
#ifdef CONFIG_SLIRP
strcmp(type, user) != 0
@@ -1077,21 +1071,21 @@ int net_client_init(Monitor *mon, QemuOpts *opts, int
is_netdev)
strcmp(type, vde) != 0
#endif
strcmp(type, socket) != 0) {
-error_report(The '%s' network backend type is not valid with
-netdev,
- type);
+qerror_report(QERR_INVALID_PARAMETER_VALUE, type,
+ a netdev backend type);
return -1;
}
if (qemu_opt_get(opts, vlan)) {
-error_report(The 'vlan' parameter is not valid with -netdev);
+qerror_report(QERR_INVALID_PARAMETER, vlan);
return -1;
}
if (qemu_opt_get(opts, name)) {
-error_report(The 'name' parameter is not valid with -netdev);
+qerror_report(QERR_INVALID_PARAMETER, name);
return -1;
}
if (!qemu_opts_id(opts)) {
-error_report(The id= parameter is required with -netdev);
+qerror_report(QERR_MISSING_PARAMETER, id);
return -1;
}
}
@@ -1117,14 +,18 @@ int net_client_init(Monitor *mon, QemuOpts *opts, int
is_netdev)
}
if (net_client_types[i].init) {
-return net_client_types[i].init(opts, mon, name, vlan);
-} else {
-return 0;
+if (net_client_types[i].init(opts, mon, name, vlan) 0) {
+/* TODO push error reporting into init() methods */
+qerror_report(QERR_DEVICE_INIT_FAILED, type);
+return -1;
+}
}
+return 0;
}
}
-error_report(Invalid -net type '%s', type);
+qerror_report(QERR_INVALID_PARAMETER_VALUE, type,
+ a network client type);
return -1;
}
--
1.6.6.1
[Qemu-devel] Re: [PATCH v3 1/1] Shared memory uio_pci driver
On 03/25/2010 11:18 AM, Cam Macdonell wrote: On Thu, Mar 25, 2010 at 3:15 AM, Michael S. Tsirkinm...@redhat.com wrote: On Thu, Mar 25, 2010 at 12:09:36AM -0600, Cam Macdonell wrote: This patch adds a driver for my shared memory PCI device using the uio_pci interface. The driver has three memory regions. The first memory region is for device registers for sending interrupts. The second BAR is for receiving MSI-X interrupts and the third memory region maps the shared memory. The device only exports the first and third memory regions to userspace. This driver supports MSI-X and regular pin interrupts. Currently, the number of MSI vectors is set to 4 which could be increased, but the driver will work with fewer vectors. If MSI is not available, then regular interrupts will be used. Some high level questions, sorry if they have been raised in the past: - Can this device use virtio framework? This gives us some standards to work off, with feature negotiation, ability to detect config changes, support for non-PCI platforms, decent documentation that is easy to extend, legal id range to use. You would thus have your driver in uio/uio_virtio_shmem.c There has been previous discussion of virtio, however while virtio is good for exporting guest memory, it's not ideal for importing memory into a guest. virtio is a DMA-based API which means that it doesn't assume cache coherent shared memory. The PCI transport takes advantage of cache coherent shared memory but it's not strictly required. Memory sharing in virtio would be a layering violation because it forces cache coherent shared memory for all virtio transports. Regards, Anthony Liguori
[Qemu-devel] Re: [PATCH v3 1/1] Shared memory uio_pci driver
On Thu, Mar 25, 2010 at 3:46 AM, Avi Kivity a...@redhat.com wrote: On 03/25/2010 08:09 AM, Cam Macdonell wrote: This patch adds a driver for my shared memory PCI device using the uio_pci interface. The driver has three memory regions. The first memory region is for device registers for sending interrupts. The second BAR is for receiving MSI-X interrupts and the third memory region maps the shared memory. The device only exports the first and third memory regions to userspace. This driver supports MSI-X and regular pin interrupts. Currently, the number of MSI vectors is set to 4 which could be increased, but the driver will work with fewer vectors. If MSI is not available, then regular interrupts will be used. There is now a generic PCI 2.3 driver that can handle all PCI devices. It doesn't support MSI, but if we add MSI support then it can be used without the need for a specialized driver. Agreed, I'd be happy to use the generic driver if MSI is there. What would MSI support for UIO look like? An array of struct uio_irq for the different vectors? Cam -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
Anthony Liguori wrote: On 03/25/2010 10:16 AM, Daniel P. Berrange wrote: On Thu, Mar 25, 2010 at 03:14:24PM +, Vincent Hanquez wrote: On Thu, Mar 25, 2010 at 03:07:20PM +, Daniel P. Berrange wrote: I agree apps shouldn't use it for RPC, but admins using the interactive user monitor are just as deserving of stable commands args. I think, once QMP is completely there, admins would be better using a qemu-cmd that's just serialise it's command line arguments into a JSON command. Then, after a qemu-cmd is introduced, we should mark the user monitor deprecated along with a specific date/release its future for removal. I'm not sure. The human monitor has some features that are not appropriate for QMP. For instance, the ability to deal with formula input and some commands meant to add debugging. I guess you could do that in qemu-cmd but I don't see a compelling reason to. As I mentioned before, I'd love to see the qemu binary (incl. monitor interface) being implemented as a pure QMP user. Then libvirt and friends can be 100% that they can achieve everything using QMP because we don't live in the same address space anymore and can't pull tricks. Alex
[Qemu-devel] Re: [PATCH v3 1/1] Shared memory uio_pci driver
On Thu, Mar 25, 2010 at 3:05 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Mar 25, 2010 at 12:09:36AM -0600, Cam Macdonell wrote:
This patch adds a driver for my shared memory PCI device using the uio_pci
interface. The driver has three memory regions. The first memory region is
for
device registers for sending interrupts. The second BAR is for receiving
MSI-X
interrupts and the third memory region maps the shared memory. The device
only
exports the first and third memory regions to userspace.
This driver supports MSI-X and regular pin interrupts. Currently, the
number of
MSI vectors is set to 4 which could be increased, but the driver will work
with
fewer vectors. If MSI is not available, then regular interrupts will be
used.
---
drivers/uio/Kconfig | 8 ++
drivers/uio/Makefile | 1 +
drivers/uio/uio_ivshmem.c | 235
+
3 files changed, 244 insertions(+), 0 deletions(-)
create mode 100644 drivers/uio/uio_ivshmem.c
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 1da73ec..b92cded 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -74,6 +74,14 @@ config UIO_SERCOS3
If you compile this as a module, it will be called uio_sercos3.
+config UIO_IVSHMEM
+ tristate KVM shared memory PCI driver
+ default n
+ help
+ Userspace I/O interface for the KVM shared memory device. This
+ driver will make available two memory regions, the first is
+ registers and the second is a region for sharing between VMs.
+
config UIO_PCI_GENERIC
tristate Generic driver for PCI 2.3 and PCI Express cards
depends on PCI
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index 18fd818..25c1ca5 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_UIO_AEC) += uio_aec.o
obj-$(CONFIG_UIO_SERCOS3) += uio_sercos3.o
obj-$(CONFIG_UIO_PCI_GENERIC) += uio_pci_generic.o
obj-$(CONFIG_UIO_NETX) += uio_netx.o
+obj-$(CONFIG_UIO_IVSHMEM) += uio_ivshmem.o
diff --git a/drivers/uio/uio_ivshmem.c b/drivers/uio/uio_ivshmem.c
new file mode 100644
index 000..607435b
--- /dev/null
+++ b/drivers/uio/uio_ivshmem.c
@@ -0,0 +1,235 @@
+/*
+ * UIO IVShmem Driver
+ *
+ * (C) 2009 Cam Macdonell
+ * based on Hilscher CIF card driver (C) 2007 Hans J. Koch
h...@linutronix.de
+ *
+ * Licensed under GPL version 2 only.
+ *
+ */
+
+#include linux/device.h
+#include linux/module.h
+#include linux/pci.h
+#include linux/uio_driver.h
+
+#include asm/io.h
+
+#define IntrStatus 0x04
+#define IntrMask 0x00
+
+struct ivshmem_info {
+ struct uio_info *uio;
+ struct pci_dev *dev;
+ char (*msix_names)[256];
+ struct msix_entry *msix_entries;
+ int nvectors;
+};
+
+static irqreturn_t ivshmem_handler(int irq, struct uio_info *dev_info)
+{
+
+ void __iomem *plx_intscr = dev_info-mem[0].internal_addr
+ + IntrStatus;
+ u32 val;
+
+ val = readl(plx_intscr);
+ if (val == 0)
+ return IRQ_NONE;
+
+ printk(KERN_INFO Regular interrupt (val = %d)\n, val);
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t ivshmem_msix_handler(int irq, void *opaque)
+{
+
+ struct uio_info * dev_info = (struct uio_info *) opaque;
+
+ /* we have to do this explicitly when using MSI-X */
+ uio_event_notify(dev_info);
How does userspace know which vector was triggered?
Right now, it doesn't. If a user had a particular need they would
need to write their own uio driver. I guess this leads to a
discussion of MSI support in UIO and how they would work with the
userspace.
+ printk(KERN_INFO MSI-X interrupt (%d)\n, irq);
+ return IRQ_HANDLED;
+
extra empty line
+}
+
+static int request_msix_vectors(struct ivshmem_info *ivs_info, int nvectors)
+{
+ int i, err;
+ const char *name = ivshmem;
+
+ printk(KERN_INFO devname is %s\n, name);
These KERN_INFO messages need to be cleaned up, they would be
look confusing in the log.
Agreed. I will clean most of these out.
+ ivs_info-nvectors = nvectors;
+
+
+ ivs_info-msix_entries = kmalloc(nvectors * sizeof
*ivs_info-msix_entries,
+ GFP_KERNEL);
+ ivs_info-msix_names = kmalloc(nvectors * sizeof *ivs_info-msix_names,
+ GFP_KERNEL);
+
need to handle errors
+ for (i = 0; i nvectors; ++i)
+ ivs_info-msix_entries[i].entry = i;
+
+ err = pci_enable_msix(ivs_info-dev, ivs_info-msix_entries,
+ ivs_info-nvectors);
+ if (err 0) {
+ ivs_info-nvectors = err; /* msi-x positive error code
+ returns the number available*/
+ err = pci_enable_msix(ivs_info-dev, ivs_info-msix_entries,
+ ivs_info-nvectors);
+ if (err 0) {
+ printk(KERN_INFO no MSI (%d). Back to INTx.\n, err);
+
[Qemu-devel] Re: [PATCH v3 1/1] Shared memory uio_pci driver
On 03/25/2010 06:23 PM, Anthony Liguori wrote: There has been previous discussion of virtio, however while virtio is good for exporting guest memory, it's not ideal for importing memory into a guest. virtio is a DMA-based API which means that it doesn't assume cache coherent shared memory. The PCI transport takes advantage of cache coherent shared memory but it's not strictly required. Aren't we violating this by not using dma_alloc_coherent() for the queues? -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [PATCH v3 1/1] Shared memory uio_pci driver
On 03/25/2010 06:24 PM, Cam Macdonell wrote: There is now a generic PCI 2.3 driver that can handle all PCI devices. It doesn't support MSI, but if we add MSI support then it can be used without the need for a specialized driver. Agreed, I'd be happy to use the generic driver if MSI is there. What would MSI support for UIO look like? An array of struct uio_irq for the different vectors? I'm not familiar with the uio internals, but for the interface, an ioctl() on the fd to assign an eventfd to an MSI vector. Similar to ioeventfd, but instead of mapping a doorbell to an eventfd, it maps a real MSI to an eventfd. That would be very useful for device assignment: we can pick up a uio device, map its vectors, and give them to a guest. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [PATCH v3 1/1] Shared memory uio_pci driver
On 03/25/2010 11:05 AM, Michael S. Tsirkin wrote:
+static struct pci_device_id ivshmem_pci_ids[] __devinitdata = {
+{
+.vendor =0x1af4,
+.device =0x1110,
vendor ids must be registered with PCI SIG.
this one does not seem to be registered.
That's the Qumranet vendor ID.
--
error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [PATCH v3 1/1] Shared memory uio_pci driver
On Thu, Mar 25, 2010 at 10:30:42AM -0600, Cam Macdonell wrote:
On Thu, Mar 25, 2010 at 3:05 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Mar 25, 2010 at 12:09:36AM -0600, Cam Macdonell wrote:
This patch adds a driver for my shared memory PCI device using the uio_pci
interface. The driver has three memory regions. The first memory region
is for
device registers for sending interrupts. The second BAR is for receiving
MSI-X
interrupts and the third memory region maps the shared memory. The device
only
exports the first and third memory regions to userspace.
This driver supports MSI-X and regular pin interrupts. Currently, the
number of
MSI vectors is set to 4 which could be increased, but the driver will work
with
fewer vectors. If MSI is not available, then regular interrupts will be
used.
---
drivers/uio/Kconfig | 8 ++
drivers/uio/Makefile | 1 +
drivers/uio/uio_ivshmem.c | 235
+
3 files changed, 244 insertions(+), 0 deletions(-)
create mode 100644 drivers/uio/uio_ivshmem.c
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 1da73ec..b92cded 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -74,6 +74,14 @@ config UIO_SERCOS3
If you compile this as a module, it will be called uio_sercos3.
+config UIO_IVSHMEM
+ tristate KVM shared memory PCI driver
+ default n
+ help
+ Userspace I/O interface for the KVM shared memory device. This
+ driver will make available two memory regions, the first is
+ registers and the second is a region for sharing between VMs.
+
config UIO_PCI_GENERIC
tristate Generic driver for PCI 2.3 and PCI Express cards
depends on PCI
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index 18fd818..25c1ca5 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_UIO_AEC) += uio_aec.o
obj-$(CONFIG_UIO_SERCOS3) += uio_sercos3.o
obj-$(CONFIG_UIO_PCI_GENERIC) += uio_pci_generic.o
obj-$(CONFIG_UIO_NETX) += uio_netx.o
+obj-$(CONFIG_UIO_IVSHMEM) += uio_ivshmem.o
diff --git a/drivers/uio/uio_ivshmem.c b/drivers/uio/uio_ivshmem.c
new file mode 100644
index 000..607435b
--- /dev/null
+++ b/drivers/uio/uio_ivshmem.c
@@ -0,0 +1,235 @@
+/*
+ * UIO IVShmem Driver
+ *
+ * (C) 2009 Cam Macdonell
+ * based on Hilscher CIF card driver (C) 2007 Hans J. Koch
h...@linutronix.de
+ *
+ * Licensed under GPL version 2 only.
+ *
+ */
+
+#include linux/device.h
+#include linux/module.h
+#include linux/pci.h
+#include linux/uio_driver.h
+
+#include asm/io.h
+
+#define IntrStatus 0x04
+#define IntrMask 0x00
+
+struct ivshmem_info {
+ struct uio_info *uio;
+ struct pci_dev *dev;
+ char (*msix_names)[256];
+ struct msix_entry *msix_entries;
+ int nvectors;
+};
+
+static irqreturn_t ivshmem_handler(int irq, struct uio_info *dev_info)
+{
+
+ void __iomem *plx_intscr = dev_info-mem[0].internal_addr
+ + IntrStatus;
+ u32 val;
+
+ val = readl(plx_intscr);
+ if (val == 0)
+ return IRQ_NONE;
+
+ printk(KERN_INFO Regular interrupt (val = %d)\n, val);
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t ivshmem_msix_handler(int irq, void *opaque)
+{
+
+ struct uio_info * dev_info = (struct uio_info *) opaque;
+
+ /* we have to do this explicitly when using MSI-X */
+ uio_event_notify(dev_info);
How does userspace know which vector was triggered?
Right now, it doesn't. If a user had a particular need they would
need to write their own uio driver. I guess this leads to a
discussion of MSI support in UIO and how they would work with the
userspace.
So why request more than one vector then?
+ printk(KERN_INFO MSI-X interrupt (%d)\n, irq);
+ return IRQ_HANDLED;
+
extra empty line
+}
+
+static int request_msix_vectors(struct ivshmem_info *ivs_info, int
nvectors)
+{
+ int i, err;
+ const char *name = ivshmem;
+
+ printk(KERN_INFO devname is %s\n, name);
These KERN_INFO messages need to be cleaned up, they would be
look confusing in the log.
Agreed. I will clean most of these out.
+ ivs_info-nvectors = nvectors;
+
+
+ ivs_info-msix_entries = kmalloc(nvectors * sizeof
*ivs_info-msix_entries,
+ GFP_KERNEL);
+ ivs_info-msix_names = kmalloc(nvectors * sizeof
*ivs_info-msix_names,
+ GFP_KERNEL);
+
need to handle errors
+ for (i = 0; i nvectors; ++i)
+ ivs_info-msix_entries[i].entry = i;
+
+ err = pci_enable_msix(ivs_info-dev, ivs_info-msix_entries,
+ ivs_info-nvectors);
+ if (err 0) {
+ ivs_info-nvectors = err; /* msi-x positive error code
+
Re: [Qemu-devel] [PATCH] Add qerror message if the 'change' target filename can't be opened
Ryan Harper ry...@us.ibm.com writes:
Currently when using the change command to switch the file in the cd drive
the command doesn't complain if the file doesn't exit or can't be opened
and the drive keeps the existing image. This patch adds a qerror_report
call to print a message out indicating the failure. This error message
can be used to catch failures.
[...]
Signed-off-by: Ryan Harper ry...@us.ibm.com
---
monitor.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/monitor.c b/monitor.c
index 0448a70..196c7a6 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1099,6 +1099,7 @@ static int do_change_block(Monitor *mon, const char
*device,
return -1;
}
if (bdrv_open2(bs, filename, BDRV_O_RDWR, drv) 0) {
+qerror_report(QERR_OPEN_FILE_FAILED, filename);
return -1;
}
return monitor_read_bdrv_key_start(mon, bs, NULL, NULL);
--
We want this fix for QMP. Without it, we get UndefinedError, and a
complaint ifdef CONFIG_DEBUG_MONITOR.
[Qemu-devel] Re: [PATCH v3 1/1] Shared memory uio_pci driver
On Thu, Mar 25, 2010 at 06:36:02PM +0200, Avi Kivity wrote:
On 03/25/2010 11:05 AM, Michael S. Tsirkin wrote:
+static struct pci_device_id ivshmem_pci_ids[] __devinitdata = {
+{
+.vendor =0x1af4,
+.device =0x1110,
vendor ids must be registered with PCI SIG.
this one does not seem to be registered.
That's the Qumranet vendor ID.
Isn't virtio_pci matching that id already?
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 09/10] target-alpha: Implement load-locked/store-conditional properly.
On Thu, Mar 25, 2010 at 09:29:18AM -0700, Richard Henderson wrote:
On 03/25/2010 09:06 AM, Nathan Froyd wrote:
It pretends just as much as ppc and arm. See translate.c:OP_ST_ATOMIC.
No it doesn't. Look at HELPER_ST_ATOMIC:
tmp = do_##ld_insn(arg2, mem_idx);
\
if (tmp == env-llval) {
\
do_##st_insn(arg2, arg1, mem_idx);
\
return 1;
\
Ah, OK. Those helpers are never called for user-mode emulation,
though. They're only called for system emulation and...well, everybody
lies about being atomic in system mode. :)
-Nathan
[Qemu-devel] [PATCH -V3 00/32] virtio-9p: paravirtual file system passthrough
This patch series adds a paravirtual file system passthrough mechanism to QEMU based on the 9P protocol. With the current implementation, all I/O is implemented in the VCPU thread. We've modified the protocol handlers so that we can support dispatch I/O in a thread pool. The actual thread pool implementation will be posted later This patch set should work with any recent Linux kernel as virtio-9p has been supported for a few kernel releases now. Export dir is specified using the below Qemu option. -fsdev fstype,id=ID,path=path/to/share \ -device virtio-9p-pci,fsdev=ID,mount_tag=tag \ or -virtfs fstype,path=path/to/share,mount_tag=tag Only supported fstype currently is local. mount_tag is used to identify the mount point in the kernel. This will be available in Linux kernel via /sys/devices/virtio-pci/virtio1/mount_tag file. Changes from V2: 1) Added new method for specifying export dir. This new method should be more flexible. 2) rebased to qemu master bedd2912c83b1a87a6bfe3f59a892fd65cda7084 Changes from V1: 1) fsstress test suite runs successfully with the patches. That should indicate patches are stable enough to be merged. 2) Added proper error handling to all posix_* calls. 3) Fixed code to follow Qemu coding style. 4) Other bug fixes most of which are folded back into the original patches 5) rebased to qemu master 0aef4261ac0ec9089ade0e3a92f986cb4ba7317e -aneesh
[Qemu-devel] [PATCH -V3 01/32] vitio-9p: Add a virtio 9p device to qemu
From: Anthony Liguori aligu...@us.ibm.com
This patch doesn't implement the 9p protocol handling
code. It add a simple device which dump the protocl data
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
Makefile.target |1 +
hw/virtio-9p-debug.c | 442 ++
hw/virtio-9p.c | 275 +++
hw/virtio-9p.h | 70
hw/virtio-pci.c | 25 +++
hw/virtio.h |1 +
6 files changed, 814 insertions(+), 0 deletions(-)
create mode 100644 hw/virtio-9p-debug.c
create mode 100644 hw/virtio-9p.c
create mode 100644 hw/virtio-9p.h
diff --git a/Makefile.target b/Makefile.target
index eb4d010..178ddce 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -166,6 +166,7 @@ obj-y += qemu-timer.o
# virtio has to be here due to weird dependency between PCI and virtio-net.
# need to fix this properly
obj-y += virtio-blk.o virtio-balloon.o virtio-net.o virtio-serial-bus.o
+obj-y += virtio-9p.o virtio-9p-debug.o
obj-y += rwhandler.o
obj-$(CONFIG_KVM) += kvm.o kvm-all.o
LIBS+=-lz
diff --git a/hw/virtio-9p-debug.c b/hw/virtio-9p-debug.c
new file mode 100644
index 000..9230659
--- /dev/null
+++ b/hw/virtio-9p-debug.c
@@ -0,0 +1,442 @@
+/*
+ * Virtio 9p PDU debug
+ *
+ * Copyright IBM, Corp. 2010
+ *
+ * Authors:
+ * Anthony Liguori aligu...@us.ibm.com
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ */
+#include virtio.h
+#include pc.h
+#include virtio-9p.h
+
+#include assert.h
+#include sys/uio.h
+
+#define BUG_ON(cond) assert(!(cond))
+
+extern int dotu;
+static FILE *llogfile;
+
+static struct iovec *get_sg(V9fsPDU *pdu, int rx)
+{
+if (rx)
+return pdu-elem.in_sg;
+return pdu-elem.out_sg;
+}
+
+static void pprint_int8(V9fsPDU *pdu, int rx, size_t *offsetp,
+const char *name)
+{
+struct iovec *sg = get_sg(pdu, rx);
+size_t offset = *offsetp;
+int8_t value;
+
+BUG_ON((offset + sizeof(value)) sg[0].iov_len);
+
+memcpy(value, sg[0].iov_base + offset, sizeof(value));
+offset += sizeof(value);
+
+fprintf(llogfile, %s=0x%x, name, value);
+
+*offsetp = offset;
+}
+
+static void pprint_int16(V9fsPDU *pdu, int rx, size_t *offsetp,
+const char *name)
+{
+struct iovec *sg = get_sg(pdu, rx);
+size_t offset = *offsetp;
+int16_t value;
+
+BUG_ON((offset + sizeof(value)) sg[0].iov_len);
+
+memcpy(value, sg[0].iov_base + offset, sizeof(value));
+offset += sizeof(value);
+
+fprintf(llogfile, %s=0x%x, name, value);
+
+*offsetp = offset;
+}
+
+static void pprint_int32(V9fsPDU *pdu, int rx, size_t *offsetp,
+const char *name)
+{
+struct iovec *sg = get_sg(pdu, rx);
+size_t offset = *offsetp;
+int32_t value;
+
+BUG_ON((offset + sizeof(value)) sg[0].iov_len);
+
+memcpy(value, sg[0].iov_base + offset, sizeof(value));
+offset += sizeof(value);
+
+fprintf(llogfile, %s=0x%x, name, value);
+
+*offsetp = offset;
+}
+
+static void pprint_int64(V9fsPDU *pdu, int rx, size_t *offsetp,
+const char *name)
+{
+struct iovec *sg = get_sg(pdu, rx);
+size_t offset = *offsetp;
+int64_t value;
+
+BUG_ON((offset + sizeof(value)) sg[0].iov_len);
+
+memcpy(value, sg[0].iov_base + offset, sizeof(value));
+offset += sizeof(value);
+
+fprintf(llogfile, %s=0x% PRIx64, name, value);
+
+*offsetp = offset;
+}
+
+static void pprint_str(V9fsPDU *pdu, int rx, size_t *offsetp, const char *name)
+{
+struct iovec *sg = get_sg(pdu, rx);
+size_t offset = *offsetp;
+int16_t size;
+size_t result;
+
+BUG_ON((offset + 2) sg[0].iov_len);
+memcpy(size, sg[0].iov_base + offset, 2);
+offset += 2;
+
+BUG_ON((offset + size) sg[0].iov_len);
+fprintf(llogfile, %s=, name);
+result = fwrite(sg[0].iov_base + offset, 1, size, llogfile);
+BUG_ON(result != size);
+offset += size;
+
+*offsetp = offset;
+}
+
+static void pprint_qid(V9fsPDU *pdu, int rx, size_t *offsetp, const char *name)
+{
+fprintf(llogfile, %s={, name);
+pprint_int8(pdu, rx, offsetp, type);
+pprint_int32(pdu, rx, offsetp, , version);
+pprint_int64(pdu, rx, offsetp, , path);
+fprintf(llogfile, });
+}
+
+static void pprint_stat(V9fsPDU *pdu, int rx, size_t *offsetp, const char
*name)
+{
+fprintf(llogfile, %s={, name);
+pprint_int16(pdu, rx, offsetp, size);
+pprint_int16(pdu, rx, offsetp, , type);
+pprint_int32(pdu, rx, offsetp, , dev);
+pprint_qid(pdu, rx, offsetp, , qid);
+pprint_int32(pdu, rx, offsetp, , mode);
+pprint_int32(pdu, rx, offsetp, , atime);
+pprint_int32(pdu, rx, offsetp, , mtime);
+pprint_int64(pdu, rx, offsetp, , length);
+pprint_str(pdu, rx, offsetp, , name);
+pprint_str(pdu, rx,
[Qemu-devel] [PATCH -V3 03/32] virtio-9p: Implement P9_TATTACH
From: Anthony Liguori aligu...@us.ibm.com
[jv...@linux.vnet.ibm.com: Added qemu_vasprintf]
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
Makefile.target |2 +-
hw/virtio-9p-local.c | 84 +++
hw/virtio-9p.c | 155 +++---
hw/virtio-9p.h | 33 +++
qemu-common.h|1 +
qemu-malloc.c|5 ++
6 files changed, 270 insertions(+), 10 deletions(-)
create mode 100644 hw/virtio-9p-local.c
diff --git a/Makefile.target b/Makefile.target
index 178ddce..960bfe2 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -166,7 +166,7 @@ obj-y += qemu-timer.o
# virtio has to be here due to weird dependency between PCI and virtio-net.
# need to fix this properly
obj-y += virtio-blk.o virtio-balloon.o virtio-net.o virtio-serial-bus.o
-obj-y += virtio-9p.o virtio-9p-debug.o
+obj-y += virtio-9p.o virtio-9p-debug.o virtio-9p-local.o
obj-y += rwhandler.o
obj-$(CONFIG_KVM) += kvm.o kvm-all.o
LIBS+=-lz
diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
new file mode 100644
index 000..1d2523b
--- /dev/null
+++ b/hw/virtio-9p-local.c
@@ -0,0 +1,84 @@
+/*
+ * Virtio 9p Posix callback
+ *
+ * Copyright IBM, Corp. 2010
+ *
+ * Authors:
+ * Anthony Liguori aligu...@us.ibm.com
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ */
+#include virtio.h
+#include pc.h
+#include qemu_socket.h
+#include virtio-9p.h
+#include sys/uio.h
+#include arpa/inet.h
+#include assert.h
+#include pwd.h
+#include grp.h
+#include sys/socket.h
+#include sys/un.h
+
+static const char *base_path;
+
+static const char *rpath(const char *path)
+{
+/* FIXME: so wrong... */
+static char buffer[4096];
+snprintf(buffer, sizeof(buffer), %s/%s, base_path, path);
+return buffer;
+}
+
+static int local_lstat(void *opaque, const char *path, struct stat *stbuf)
+{
+return lstat(rpath(path), stbuf);
+}
+
+static int local_setuid(void *opaque, uid_t uid)
+{
+struct passwd *pw;
+gid_t groups[33];
+int ngroups;
+static uid_t cur_uid = -1;
+
+if (cur_uid == uid)
+return 0;
+
+if (setreuid(0, 0))
+return -1;
+
+pw = getpwuid(uid);
+if (pw == NULL)
+return -1;
+
+ngroups = 33;
+if (getgrouplist(pw-pw_name, pw-pw_gid, groups, ngroups) == -1)
+return -1;
+
+if (setgroups(ngroups, groups))
+return -1;
+
+if (setregid(-1, pw-pw_gid))
+return -1;
+
+if (setreuid(-1, uid))
+return -1;
+
+cur_uid = uid;
+
+return 0;
+}
+
+static V9fsPosixFileOperations ops = {
+.lstat = local_lstat,
+.setuid = local_setuid,
+};
+
+V9fsPosixFileOperations *virtio_9p_init_local(const char *path)
+{
+base_path = path;
+return ops;
+}
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 53b3d78..fdff589 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -82,6 +82,7 @@ typedef struct V9fsState
V9fsPDU pdus[MAX_REQ];
V9fsPDU *free_pdu;
V9fsFidState *fid_list;
+V9fsPosixFileOperations *ops;
char *root;
uid_t uid;
} V9fsState;
@@ -91,6 +92,123 @@ int debug_9p_pdu = 1;
extern void pprint_pdu(V9fsPDU *pdu);
+static int posix_lstat(V9fsState *s, V9fsString *path, struct stat *stbuf)
+{
+return s-ops-lstat(s-ops-opaque, path-data, stbuf);
+}
+
+static int posix_setuid(V9fsState *s, uid_t uid)
+{
+return s-ops-setuid(s-ops-opaque, uid);
+}
+
+static void v9fs_string_free(V9fsString *str)
+{
+qemu_free(str-data);
+str-data = NULL;
+str-size = 0;
+}
+
+static void v9fs_string_sprintf(V9fsString *str, const char *fmt, ...)
+{
+va_list ap;
+int err;
+
+v9fs_string_free(str);
+
+va_start(ap, fmt);
+err = qemu_vasprintf(str-data, fmt, ap);
+BUG_ON(err == -1);
+va_end(ap);
+
+str-size = err;
+}
+
+static V9fsFidState *lookup_fid(V9fsState *s, int32_t fid)
+{
+V9fsFidState *f;
+
+for (f = s-fid_list; f; f = f-next) {
+if (f-fid == fid) {
+posix_setuid(s, f-uid);
+return f;
+}
+}
+
+return NULL;
+}
+
+static V9fsFidState *alloc_fid(V9fsState *s, int32_t fid)
+{
+V9fsFidState *f;
+
+f = lookup_fid(s, fid);
+if (f)
+return NULL;
+
+f = qemu_mallocz(sizeof(V9fsFidState));
+BUG_ON(f == NULL);
+
+f-fid = fid;
+f-fd = -1;
+f-dir = NULL;
+
+f-next = s-fid_list;
+s-fid_list = f;
+
+return f;
+}
+
+#define P9_QID_TYPE_DIR0x80
+#define P9_QID_TYPE_SYMLINK0x02
+
+#define P9_STAT_MODE_DIR 0x8000
+#define P9_STAT_MODE_APPEND0x4000
+#define P9_STAT_MODE_EXCL 0x2000
+#define P9_STAT_MODE_MOUNT 0x1000
+#define P9_STAT_MODE_AUTH 0x0800
+#define P9_STAT_MODE_TMP 0x0400
+#define P9_STAT_MODE_SYMLINK 0x0200
+#define P9_STAT_MODE_LINK
[Qemu-devel] [PATCH -V3 06/32] virtio-9p: Implement P9_TOPEN
From: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Gautham R Shenoy e...@in.ibm.com
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
hw/virtio-9p-local.c | 12
hw/virtio-9p.c | 145 +++--
2 files changed, 151 insertions(+), 6 deletions(-)
diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
index 409f5b0..d8cb70d 100644
--- a/hw/virtio-9p-local.c
+++ b/hw/virtio-9p-local.c
@@ -88,12 +88,24 @@ static int local_closedir(void *opaque, DIR *dir)
return closedir(dir);
}
+static int local_open(void *opaque, const char *path, int flags)
+{
+return open(rpath(path), flags);
+}
+
+static DIR *local_opendir(void *opaque, const char *path)
+{
+return opendir(rpath(path));
+}
+
static V9fsPosixFileOperations ops = {
.lstat = local_lstat,
.setuid = local_setuid,
.readlink = local_readlink,
.close = local_close,
.closedir = local_closedir,
+.open = local_open,
+.opendir = local_opendir,
};
V9fsPosixFileOperations *virtio_9p_init_local(const char *path)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 784d399..f1df0b9 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -127,6 +127,16 @@ static int posix_closedir(V9fsState *s, DIR *dir)
return s-ops-closedir(s-ops-opaque, dir);
}
+static int posix_open(V9fsState *s, V9fsString *path, int flags)
+{
+return s-ops-open(s-ops-opaque, path-data, flags);
+}
+
+static DIR *posix_opendir(V9fsState *s, V9fsString *path)
+{
+return s-ops-opendir(s-ops-opaque, path-data);
+}
+
static void v9fs_string_init(V9fsString *str)
{
str-data = NULL;
@@ -910,15 +920,138 @@ out:
v9fs_walk_complete(s, vs, err);
}
-static void v9fs_clunk(V9fsState *s, V9fsPDU *pdu)
+typedef struct V9fsOpenState {
+V9fsPDU *pdu;
+size_t offset;
+int32_t fid;
+int8_t mode;
+V9fsFidState *fidp;
+V9fsQID qid;
+struct stat stbuf;
+
+} V9fsOpenState;
+
+enum {
+Oread = 0x00,
+Owrite = 0x01,
+Ordwr = 0x02,
+Oexec = 0x03,
+Oexcl = 0x04,
+Otrunc = 0x10,
+Orexec = 0x20,
+Orclose= 0x40,
+Oappend= 0x80,
+};
+
+static int omode_to_uflags(int8_t mode)
{
-if (debug_9p_pdu)
-pprint_pdu(pdu);
+int ret = 0;
+
+switch (mode 3) {
+case Oread:
+ret = O_RDONLY;
+break;
+case Ordwr:
+ret = O_RDWR;
+break;
+case Owrite:
+ret = O_WRONLY;
+break;
+case Oexec:
+ret = O_RDONLY;
+break;
+}
+
+if (mode Otrunc)
+ret |= O_TRUNC;
+
+if (mode Oappend)
+ret |= O_APPEND;
+
+if (mode Oexcl)
+ret |= O_EXCL;
+
+return ret;
+}
+
+static void v9fs_open_post_opendir(V9fsState *s, V9fsOpenState *vs, int err)
+{
+if (vs-fidp-dir == NULL) {
+err = -errno;
+goto out;
+}
+
+vs-offset += pdu_marshal(vs-pdu, vs-offset, Qd, vs-qid, 0);
+err = vs-offset;
+out:
+complete_pdu(s, vs-pdu, err);
+qemu_free(vs);
+
}
-static void v9fs_open(V9fsState *s, V9fsPDU *pdu)
-{if (debug_9p_pdu)
-pprint_pdu(pdu);
+static void v9fs_open_post_open(V9fsState *s, V9fsOpenState *vs, int err)
+{
+if (vs-fidp-fd == -1) {
+err = -errno;
+goto out;
+}
+
+vs-offset += pdu_marshal(vs-pdu, vs-offset, Qd, vs-qid, 0);
+err = vs-offset;
+out:
+complete_pdu(s, vs-pdu, err);
+qemu_free(vs);
+}
+
+static void v9fs_open_post_lstat(V9fsState *s, V9fsOpenState *vs, int err)
+{
+BUG_ON(err == -1);
+
+stat_to_qid(vs-stbuf, vs-qid);
+
+if (S_ISDIR(vs-stbuf.st_mode)) {
+vs-fidp-dir = posix_opendir(s, vs-fidp-path);
+v9fs_open_post_opendir(s, vs, err);
+} else {
+vs-fidp-fd = posix_open(s, vs-fidp-path,
+omode_to_uflags(vs-mode));
+v9fs_open_post_open(s, vs, err);
+}
+
+}
+
+static void v9fs_open(V9fsState *s, V9fsPDU *pdu)
+{
+
+V9fsOpenState *vs;
+ssize_t err = 0;
+
+
+vs = qemu_malloc(sizeof(*vs));
+vs-pdu = pdu;
+vs-offset = 7;
+
+pdu_unmarshal(vs-pdu, vs-offset, db, vs-fid, vs-mode);
+
+vs-fidp = lookup_fid(s, vs-fid);
+if (vs-fidp == NULL) {
+err = -ENOENT;
+goto out;
+}
+
+err = posix_lstat(s, vs-fidp-path, vs-stbuf);
+
+v9fs_open_post_lstat(s, vs, err);
+return;
+out:
+complete_pdu(s, pdu, err);
+qemu_free(vs);
+}
+
+static void v9fs_clunk(V9fsState *s, V9fsPDU *pdu)
+{
+if (debug_9p_pdu)
+ pprint_pdu(pdu);
}
static void v9fs_read(V9fsState *s, V9fsPDU *pdu)
--
1.7.0.2.323.g0d092
[Qemu-devel] [PATCH -V3 05/32] virtio-9p: Implement P9_TWALK
From: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Gautham R Shenoy e...@in.ibm.com
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
hw/virtio-9p-local.c | 12 +++
hw/virtio-9p.c | 219 +-
2 files changed, 229 insertions(+), 2 deletions(-)
diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
index aefb5a8..409f5b0 100644
--- a/hw/virtio-9p-local.c
+++ b/hw/virtio-9p-local.c
@@ -78,10 +78,22 @@ static ssize_t local_readlink(void *opaque, const char
*path,
return readlink(rpath(path), buf, bufsz);
}
+static int local_close(void *opaque, int fd)
+{
+return close(fd);
+}
+
+static int local_closedir(void *opaque, DIR *dir)
+{
+return closedir(dir);
+}
+
static V9fsPosixFileOperations ops = {
.lstat = local_lstat,
.setuid = local_setuid,
.readlink = local_readlink,
+.close = local_close,
+.closedir = local_closedir,
};
V9fsPosixFileOperations *virtio_9p_init_local(const char *path)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index de5f6b0..784d399 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -117,6 +117,22 @@ static ssize_t posix_readlink(V9fsState *s, V9fsString
*path, V9fsString *buf)
return len;
}
+static int posix_close(V9fsState *s, int fd)
+{
+return s-ops-close(s-ops-opaque, fd);
+}
+
+static int posix_closedir(V9fsState *s, DIR *dir)
+{
+return s-ops-closedir(s-ops-opaque, dir);
+}
+
+static void v9fs_string_init(V9fsString *str)
+{
+str-data = NULL;
+str-size = 0;
+}
+
static void v9fs_string_free(V9fsString *str)
{
qemu_free(str-data);
@@ -144,6 +160,12 @@ static void v9fs_string_sprintf(V9fsString *str, const
char *fmt, ...)
str-size = err;
}
+static void v9fs_string_copy(V9fsString *lhs, V9fsString *rhs)
+{
+v9fs_string_free(lhs);
+v9fs_string_sprintf(lhs, %s, rhs-data);
+}
+
static size_t v9fs_string_size(V9fsString *str)
{
return str-size;
@@ -184,6 +206,31 @@ static V9fsFidState *alloc_fid(V9fsState *s, int32_t fid)
return f;
}
+static int free_fid(V9fsState *s, int32_t fid)
+{
+V9fsFidState **fidpp, *fidp;
+
+for (fidpp = s-fid_list; *fidpp; fidpp = (*fidpp)-next) {
+if ((*fidpp)-fid == fid)
+break;
+}
+
+if (*fidpp == NULL)
+return -ENOENT;
+
+fidp = *fidpp;
+*fidpp = fidp-next;
+
+if (fidp-fd != -1)
+posix_close(s, fidp-fd);
+if (fidp-dir)
+posix_closedir(s, fidp-dir);
+v9fs_string_free(fidp-path);
+qemu_free(fidp);
+
+return 0;
+}
+
#define P9_QID_TYPE_DIR0x80
#define P9_QID_TYPE_SYMLINK0x02
@@ -689,10 +736,178 @@ out:
qemu_free(vs);
}
+typedef struct V9fsWalkState {
+V9fsPDU *pdu;
+size_t offset;
+int32_t fid;
+int32_t newfid;
+int16_t nwnames;
+int name_idx;
+V9fsQID *qids;
+V9fsFidState *fidp;
+V9fsFidState *newfidp;
+V9fsString path;
+V9fsString *wnames;
+struct stat stbuf;
+} V9fsWalkState;
+
+static void v9fs_walk_complete(V9fsState *s, V9fsWalkState *vs, int err)
+{
+complete_pdu(s, vs-pdu, err);
+
+if(vs-nwnames) {
+for (vs-name_idx = 0; vs-name_idx vs-nwnames; vs-name_idx++)
+v9fs_string_free(vs-wnames[vs-name_idx]);
+
+qemu_free(vs-wnames);
+qemu_free(vs-qids);
+}
+}
+
+static void v9fs_walk_marshal(V9fsWalkState *vs)
+{
+int i;
+vs-offset = 7;
+vs-offset += pdu_marshal(vs-pdu, vs-offset, w, vs-nwnames);
+
+for (i = 0; i vs-nwnames; i++)
+vs-offset += pdu_marshal(vs-pdu, vs-offset, Q, vs-qids[i]);
+}
+
+static void v9fs_walk_post_newfid_lstat(V9fsState *s, V9fsWalkState *vs,
+int err)
+{
+if (err == -1) {
+free_fid(s, vs-newfid);
+v9fs_string_free(vs-path);
+err = -ENOENT;
+goto out;
+}
+
+stat_to_qid(vs-stbuf, vs-qids[vs-name_idx]);
+
+vs-name_idx++;
+if (vs-name_idx vs-nwnames) {
+v9fs_string_sprintf(vs-path, %s/%s, vs-newfidp-path.data,
+vs-wnames[vs-name_idx].data);
+v9fs_string_copy(vs-newfidp-path, vs-path);
+
+err = posix_lstat(s, vs-newfidp-path, vs-stbuf);
+v9fs_walk_post_newfid_lstat(s, vs, err);
+return;
+}
+
+v9fs_string_free(vs-path);
+v9fs_walk_marshal(vs);
+err = vs-offset;
+out:
+v9fs_walk_complete(s, vs, err);
+}
+
+static void v9fs_walk_post_oldfid_lstat(V9fsState *s, V9fsWalkState *vs,
+int err)
+{
+if (err == -1) {
+v9fs_string_free(vs-path);
+err = -ENOENT;
+goto out;
+}
+
+stat_to_qid(vs-stbuf, vs-qids[vs-name_idx]);
+vs-name_idx++;
+if (vs-name_idx vs-nwnames) {
+
+v9fs_string_sprintf(vs-path, %s/%s,
+vs-fidp-path.data, vs-wnames[vs-name_idx].data);
+
[Qemu-devel] [PATCH -V3 07/32] virtio-9p: Implement P9_TREAD
From: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
hw/virtio-9p-local.c | 37
hw/virtio-9p.c | 253 +-
2 files changed, 287 insertions(+), 3 deletions(-)
diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
index d8cb70d..d77ecc2 100644
--- a/hw/virtio-9p-local.c
+++ b/hw/virtio-9p-local.c
@@ -98,6 +98,37 @@ static DIR *local_opendir(void *opaque, const char *path)
return opendir(rpath(path));
}
+static void local_rewinddir(void *opaque, DIR *dir)
+{
+return rewinddir(dir);
+}
+
+static off_t local_telldir(void *opaque, DIR *dir)
+{
+return telldir(dir);
+}
+
+static struct dirent *local_readdir(void *opaque, DIR *dir)
+{
+return readdir(dir);
+}
+
+static void local_seekdir(void *opaque, DIR *dir, off_t off)
+{
+return seekdir(dir, off);
+}
+
+static ssize_t local_readv(void *opaque, int fd, const struct iovec *iov,
+ int iovcnt)
+{
+return readv(fd, iov, iovcnt);
+}
+
+static off_t local_lseek(void *opaque, int fd, off_t offset, int whence)
+{
+return lseek(fd, offset, whence);
+}
+
static V9fsPosixFileOperations ops = {
.lstat = local_lstat,
.setuid = local_setuid,
@@ -106,6 +137,12 @@ static V9fsPosixFileOperations ops = {
.closedir = local_closedir,
.open = local_open,
.opendir = local_opendir,
+.rewinddir = local_rewinddir,
+.telldir = local_telldir,
+.readdir = local_readdir,
+.seekdir = local_seekdir,
+.readv = local_readv,
+.lseek = local_lseek,
};
V9fsPosixFileOperations *virtio_9p_init_local(const char *path)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index f1df0b9..9bc0a57 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -137,6 +137,37 @@ static DIR *posix_opendir(V9fsState *s, V9fsString *path)
return s-ops-opendir(s-ops-opaque, path-data);
}
+static void posix_rewinddir(V9fsState *s, DIR *dir)
+{
+return s-ops-rewinddir(s-ops-opaque, dir);
+}
+
+static off_t posix_telldir(V9fsState *s, DIR *dir)
+{
+return s-ops-telldir(s-ops-opaque, dir);
+}
+
+static struct dirent *posix_readdir(V9fsState *s, DIR *dir)
+{
+return s-ops-readdir(s-ops-opaque, dir);
+}
+
+static void posix_seekdir(V9fsState *s, DIR *dir, off_t off)
+{
+return s-ops-seekdir(s-ops-opaque, dir, off);
+}
+
+static int posix_readv(V9fsState *s, int fd, const struct iovec *iov,
+ int iovcnt)
+{
+return s-ops-readv(s-ops-opaque, fd, iov, iovcnt);
+}
+
+static off_t posix_lseek(V9fsState *s, int fd, off_t offset, int whence)
+{
+return s-ops-lseek(s-ops-opaque, fd, offset, whence);
+}
+
static void v9fs_string_init(V9fsString *str)
{
str-data = NULL;
@@ -1048,14 +1079,230 @@ out:
qemu_free(vs);
}
-static void v9fs_clunk(V9fsState *s, V9fsPDU *pdu)
+static struct iovec *adjust_sg(struct iovec *sg, int len, int *iovcnt)
{
-if (debug_9p_pdu)
- pprint_pdu(pdu);
+while (len *iovcnt) {
+if (len sg-iov_len) {
+sg-iov_len -= len;
+sg-iov_base += len;
+len = 0;
+} else {
+len -= sg-iov_len;
+sg++;
+*iovcnt -= 1;
+}
+}
+
+return sg;
+}
+
+static struct iovec *cap_sg(struct iovec *sg, int cap, int *cnt)
+{
+int i;
+int total = 0;
+
+for (i = 0; i *cnt; i++) {
+if ((total + sg[i].iov_len) cap) {
+sg[i].iov_len -= ((total + sg[i].iov_len) - cap);
+i++;
+break;
+}
+total += sg[i].iov_len;
+}
+
+*cnt = i;
+
+return sg;
+}
+
+static void print_sg(struct iovec *sg, int cnt)
+{
+int i;
+
+printf(sg[%d]: {, cnt);
+for (i = 0; i cnt; i++) {
+if (i)
+printf(, );
+printf((%p, %zd), sg[i].iov_base, sg[i].iov_len);
+}
+printf(}\n);
+}
+
+typedef struct V9fsReadState {
+V9fsPDU *pdu;
+size_t offset;
+int32_t fid;
+int32_t count;
+int32_t total;
+int64_t off;
+V9fsFidState *fidp;
+struct iovec iov[128]; /* FIXME: bad, bad, bad */
+struct iovec *sg;
+off_t dir_pos;
+struct dirent *dent;
+struct stat stbuf;
+V9fsString name;
+V9fsStat v9stat;
+int32_t len;
+int32_t cnt;
+int32_t max_count;
+} V9fsReadState;
+
+static void v9fs_read_post_readdir(V9fsState *, V9fsReadState *, ssize_t );
+
+static void v9fs_read_post_seekdir(V9fsState *s, V9fsReadState *vs, ssize_t
err)
+{
+v9fs_stat_free(vs-v9stat);
+v9fs_string_free(vs-name);
+vs-offset += pdu_marshal(vs-pdu, vs-offset, d, vs-count);
+vs-offset += vs-count;
+err = vs-offset;
+complete_pdu(s, vs-pdu, err);
+qemu_free(vs);
+return;
+}
+
+static void v9fs_read_post_dir_lstat(V9fsState *s, V9fsReadState *vs,
+
[Qemu-devel] [PATCH -V3 08/32] virtio-9p: Implement P9_TCLUNK
From: Anthony Liguori aligu...@us.ibm.com
This patch gets ls -al to work
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
hw/virtio-9p.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 9bc0a57..3ac6255 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -1303,8 +1303,20 @@ out:
static void v9fs_clunk(V9fsState *s, V9fsPDU *pdu)
{
-if (debug_9p_pdu)
-pprint_pdu(pdu);
+int32_t fid;
+size_t offset = 7;
+int err;
+
+pdu_unmarshal(pdu, offset, d, fid);
+
+err = free_fid(s, fid);
+if (err 0)
+goto out;
+
+offset = 7;
+err = offset;
+out:
+complete_pdu(s, pdu, err);
}
static void v9fs_write(V9fsState *s, V9fsPDU *pdu)
--
1.7.0.2.323.g0d092
[Qemu-devel] [PATCH -V3 09/32] virtio-9p: Implement P9_TWRITE
From: Anthony Liguori aligu...@us.ibm.com
This gets write to file to work
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
hw/virtio-9p-local.c |7
hw/virtio-9p.c | 97 -
2 files changed, 102 insertions(+), 2 deletions(-)
diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
index d77ecc2..c5d1db3 100644
--- a/hw/virtio-9p-local.c
+++ b/hw/virtio-9p-local.c
@@ -129,6 +129,12 @@ static off_t local_lseek(void *opaque, int fd, off_t
offset, int whence)
return lseek(fd, offset, whence);
}
+static ssize_t local_writev(void *opaque, int fd, const struct iovec *iov,
+ int iovcnt)
+{
+return writev(fd, iov, iovcnt);
+}
+
static V9fsPosixFileOperations ops = {
.lstat = local_lstat,
.setuid = local_setuid,
@@ -143,6 +149,7 @@ static V9fsPosixFileOperations ops = {
.seekdir = local_seekdir,
.readv = local_readv,
.lseek = local_lseek,
+.writev = local_writev,
};
V9fsPosixFileOperations *virtio_9p_init_local(const char *path)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 3ac6255..bc26d66 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -168,6 +168,12 @@ static off_t posix_lseek(V9fsState *s, int fd, off_t
offset, int whence)
return s-ops-lseek(s-ops-opaque, fd, offset, whence);
}
+static int posix_writev(V9fsState *s, int fd, const struct iovec *iov,
+ int iovcnt)
+{
+return s-ops-writev(s-ops-opaque, fd, iov, iovcnt);
+}
+
static void v9fs_string_init(V9fsString *str)
{
str-data = NULL;
@@ -1319,10 +1325,97 @@ out:
complete_pdu(s, pdu, err);
}
+typedef struct V9fsWriteState {
+V9fsPDU *pdu;
+size_t offset;
+int32_t fid;
+int32_t len;
+int32_t count;
+int32_t total;
+int64_t off;
+V9fsFidState *fidp;
+struct iovec iov[128]; /* FIXME: bad, bad, bad */
+struct iovec *sg;
+int cnt;
+} V9fsWriteState;
+
+static void v9fs_write_post_writev(V9fsState *s, V9fsWriteState *vs,
+ ssize_t err)
+{
+BUG_ON(vs-len 0);
+vs-total += vs-len;
+vs-sg = adjust_sg(vs-sg, vs-len, vs-cnt);
+if (vs-total vs-count vs-len 0) {
+do {
+if (0)
+print_sg(vs-sg, vs-cnt);
+vs-len = posix_writev(s, vs-fidp-fd, vs-sg, vs-cnt);
+} while (vs-len == -1 errno == EINTR);
+v9fs_write_post_writev(s, vs, err);
+}
+vs-offset += pdu_marshal(vs-pdu, vs-offset, d, vs-total);
+
+err = vs-offset;
+complete_pdu(s, vs-pdu, err);
+qemu_free(vs);
+}
+
+static void v9fs_write_post_lseek(V9fsState *s, V9fsWriteState *vs, ssize_t
err)
+{
+BUG_ON(err == -1);
+
+vs-sg = cap_sg(vs-sg, vs-count, vs-cnt);
+
+if (vs-total vs-count) {
+do {
+if (0)
+print_sg(vs-sg, vs-cnt);
+vs-len = posix_writev(s, vs-fidp-fd, vs-sg, vs-cnt);
+} while (vs-len == -1 errno == EINTR);
+
+v9fs_write_post_writev(s, vs, err);
+return;
+}
+
+complete_pdu(s, vs-pdu, err);
+qemu_free(vs);
+}
+
static void v9fs_write(V9fsState *s, V9fsPDU *pdu)
{
-if (debug_9p_pdu)
-pprint_pdu(pdu);
+V9fsWriteState *vs;
+ssize_t err;
+
+vs = qemu_malloc(sizeof(*vs));
+
+vs-pdu = pdu;
+vs-offset = 7;
+vs-sg = vs-iov;
+vs-total = 0;
+vs-len = 0;
+
+pdu_unmarshal(vs-pdu, vs-offset, dqdv, vs-fid, vs-off, vs-count,
+vs-sg, vs-cnt);
+
+vs-fidp = lookup_fid(s, vs-fid);
+if (vs-fidp == NULL) {
+err = -EINVAL;
+goto out;
+}
+
+if (vs-fidp-fd == -1) {
+err = -EINVAL;
+goto out;
+}
+
+err = posix_lseek(s, vs-fidp-fd, vs-off, SEEK_SET);
+
+v9fs_write_post_lseek(s, vs, err);
+return;
+
+out:
+complete_pdu(s, vs-pdu, err);
+qemu_free(vs);
}
static void v9fs_create(V9fsState *s, V9fsPDU *pdu)
--
1.7.0.2.323.g0d092
[Qemu-devel] [PATCH -V3 04/32] virtio-9p: Implement P9_TSTAT
From: Anthony Liguori aligu...@us.ibm.com
This get the mount to work on the guest
[ki...@linux.vnet.ibm.com: malloc to qemu_malloc conversion]
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Gautham R Shenoy e...@in.ibm.com
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
hw/virtio-9p-local.c |7 ++
hw/virtio-9p.c | 169 +-
2 files changed, 174 insertions(+), 2 deletions(-)
diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
index 1d2523b..aefb5a8 100644
--- a/hw/virtio-9p-local.c
+++ b/hw/virtio-9p-local.c
@@ -72,9 +72,16 @@ static int local_setuid(void *opaque, uid_t uid)
return 0;
}
+static ssize_t local_readlink(void *opaque, const char *path,
+char *buf, size_t bufsz)
+{
+return readlink(rpath(path), buf, bufsz);
+}
+
static V9fsPosixFileOperations ops = {
.lstat = local_lstat,
.setuid = local_setuid,
+.readlink = local_readlink,
};
V9fsPosixFileOperations *virtio_9p_init_local(const char *path)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index fdff589..de5f6b0 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -102,6 +102,21 @@ static int posix_setuid(V9fsState *s, uid_t uid)
return s-ops-setuid(s-ops-opaque, uid);
}
+static ssize_t posix_readlink(V9fsState *s, V9fsString *path, V9fsString *buf)
+{
+ssize_t len;
+
+buf-data = qemu_malloc(1024);
+
+len = s-ops-readlink(s-ops-opaque, path-data, buf-data, 1024 - 1);
+if (len -1) {
+buf-size = len;
+buf-data[len] = 0;
+}
+
+return len;
+}
+
static void v9fs_string_free(V9fsString *str)
{
qemu_free(str-data);
@@ -109,6 +124,11 @@ static void v9fs_string_free(V9fsString *str)
str-size = 0;
}
+static void v9fs_string_null(V9fsString *str)
+{
+v9fs_string_free(str);
+}
+
static void v9fs_string_sprintf(V9fsString *str, const char *fmt, ...)
{
va_list ap;
@@ -124,6 +144,11 @@ static void v9fs_string_sprintf(V9fsString *str, const
char *fmt, ...)
str-size = err;
}
+static size_t v9fs_string_size(V9fsString *str)
+{
+return str-size;
+}
+
static V9fsFidState *lookup_fid(V9fsState *s, int32_t fid)
{
V9fsFidState *f;
@@ -437,6 +462,15 @@ static size_t pdu_marshal(V9fsPDU *pdu, size_t offset,
const char *fmt, ...)
return offset - old_offset;
}
+static void v9fs_stat_free(V9fsStat *stat)
+{
+v9fs_string_free(stat-name);
+v9fs_string_free(stat-uid);
+v9fs_string_free(stat-gid);
+v9fs_string_free(stat-muid);
+v9fs_string_free(stat-extension);
+}
+
static void complete_pdu(V9fsState *s, V9fsPDU *pdu, ssize_t len)
{
int8_t id = pdu-id + 1; /* Response */
@@ -472,6 +506,88 @@ static void complete_pdu(V9fsState *s, V9fsPDU *pdu,
ssize_t len)
free_pdu(s, pdu);
}
+static uint32_t stat_to_v9mode(const struct stat *stbuf)
+{
+uint32_t mode;
+
+mode = stbuf-st_mode 0777;
+if (S_ISDIR(stbuf-st_mode))
+mode |= P9_STAT_MODE_DIR;
+
+if (dotu) {
+if (S_ISLNK(stbuf-st_mode))
+mode |= P9_STAT_MODE_SYMLINK;
+if (S_ISSOCK(stbuf-st_mode))
+mode |= P9_STAT_MODE_SOCKET;
+if (S_ISFIFO(stbuf-st_mode))
+mode |= P9_STAT_MODE_NAMED_PIPE;
+if (S_ISBLK(stbuf-st_mode) || S_ISCHR(stbuf-st_mode))
+mode |= P9_STAT_MODE_DEVICE;
+if (stbuf-st_mode S_ISUID)
+mode |= P9_STAT_MODE_SETUID;
+if (stbuf-st_mode S_ISGID)
+mode |= P9_STAT_MODE_SETGID;
+if (stbuf-st_mode S_ISVTX)
+mode |= P9_STAT_MODE_SETVTX;
+}
+
+return mode;
+}
+
+static void stat_to_v9stat(V9fsState *s, V9fsString *name,
+const struct stat *stbuf,
+V9fsStat *v9stat)
+{
+int err;
+const char *str;
+
+memset(v9stat, 0, sizeof(*v9stat));
+
+stat_to_qid(stbuf, v9stat-qid);
+v9stat-mode = stat_to_v9mode(stbuf);
+v9stat-atime = stbuf-st_atime;
+v9stat-mtime = stbuf-st_mtime;
+v9stat-length = stbuf-st_size;
+
+v9fs_string_null(v9stat-uid);
+v9fs_string_null(v9stat-gid);
+v9fs_string_null(v9stat-muid);
+
+if (dotu) {
+v9stat-n_uid = stbuf-st_uid;
+v9stat-n_gid = stbuf-st_gid;
+v9stat-n_muid = 0;
+
+v9fs_string_null(v9stat-extension);
+
+if (v9stat-mode P9_STAT_MODE_SYMLINK) {
+err = posix_readlink(s, name, v9stat-extension);
+BUG_ON(err == -1);
+v9stat-extension.data[err] = 0;
+v9stat-extension.size = err;
+} else if (v9stat-mode P9_STAT_MODE_DEVICE) {
+v9fs_string_sprintf(v9stat-extension, %c %u %u,
+S_ISCHR(stbuf-st_mode) ? 'c' : 'b',
+major(stbuf-st_rdev), minor(stbuf-st_rdev));
+}
+}
+
+str = strrchr(name-data, '/');
+if (str)
+str += 1;
+else
+str = name-data;
+
+
[Qemu-devel] [PATCH -V3 12/32] virtio-9p: Implement P9_TREMOVE
From: Anthony Liguori aligu...@us.ibm.com
This gets file deletion to work
[mo...@in.ibm.com: Fix truncate to use the relative path]
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Gautham R Shenoy e...@in.ibm.com
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
hw/virtio-9p-local.c |7 ++
hw/virtio-9p.c | 54 -
2 files changed, 59 insertions(+), 2 deletions(-)
diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
index 829e79a..dca6175 100644
--- a/hw/virtio-9p-local.c
+++ b/hw/virtio-9p-local.c
@@ -245,6 +245,12 @@ static int local_utime(void *opaque, const char *path,
return utime(rpath(path), buf);
}
+static int local_remove(void *opaque, const char *path)
+{
+return remove(rpath(path));
+}
+
+
static V9fsPosixFileOperations ops = {
.lstat = local_lstat,
.setuid = local_setuid,
@@ -272,6 +278,7 @@ static V9fsPosixFileOperations ops = {
.rename = local_rename,
.chown = local_chown,
.utime = local_utime,
+.remove = local_remove,
};
V9fsPosixFileOperations *virtio_9p_init_local(const char *path)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index c8995a3..4478e57 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -237,6 +237,11 @@ static int posix_utime(V9fsState *s, V9fsString *path,
return s-ops-utime(s-ops-opaque, path-data, buf);
}
+static int posix_remove(V9fsState *s, V9fsString *path)
+{
+return s-ops-remove(s-ops-opaque, path-data);
+}
+
static void v9fs_string_init(V9fsString *str)
{
str-data = NULL;
@@ -1716,10 +1721,55 @@ static void v9fs_flush(V9fsState *s, V9fsPDU *pdu)
pprint_pdu(pdu);
}
+typedef struct V9fsRemoveState {
+V9fsPDU *pdu;
+size_t offset;
+int32_t fid;
+V9fsFidState *fidp;
+} V9fsRemoveState;
+
+static void v9fs_remove_post_remove(V9fsState *s, V9fsRemoveState *vs,
+int err)
+{
+if (err) {
+err = -errno;
+goto out;
+}
+
+err = free_fid(s, vs-fid);
+if (err 0)
+goto out;
+
+err = vs-offset;
+out:
+complete_pdu(s, vs-pdu, err);
+qemu_free(vs);
+}
+
static void v9fs_remove(V9fsState *s, V9fsPDU *pdu)
{
-if (debug_9p_pdu)
-pprint_pdu(pdu);
+V9fsRemoveState *vs;
+int err = 0;
+
+vs = qemu_malloc(sizeof(*vs));
+vs-pdu = pdu;
+vs-offset = 7;
+
+pdu_unmarshal(vs-pdu, vs-offset, d, vs-fid);
+
+vs-fidp = lookup_fid(s, vs-fid);
+if (vs-fidp == NULL) {
+err = -EINVAL;
+goto out;
+}
+
+err = posix_remove(s, vs-fidp-path);
+v9fs_remove_post_remove(s, vs, err);
+return;
+
+out:
+complete_pdu(s, pdu, err);
+qemu_free(vs);
}
static mode_t v9mode_to_mode(uint32_t mode, V9fsString *extension)
--
1.7.0.2.323.g0d092
[Qemu-devel] [PATCH -V3 16/32] virtio-9p: Add support for hardlink
link count for files and directories are encoded as
a tagged string in the extension field for a .u protocol
extension.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
hw/virtio-9p.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index e8a9eeb..3ddf2b9 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -674,6 +674,9 @@ static void stat_to_v9stat(V9fsState *s, V9fsString *name,
v9fs_string_sprintf(v9stat-extension, %c %u %u,
S_ISCHR(stbuf-st_mode) ? 'c' : 'b',
major(stbuf-st_rdev), minor(stbuf-st_rdev));
+} else if (S_ISDIR(stbuf-st_mode) || S_ISREG(stbuf-st_mode)) {
+v9fs_string_sprintf(v9stat-extension, %s %u,
+HARDLINKCOUNT, stbuf-st_nlink);
}
}
--
1.7.0.2.323.g0d092
[Qemu-devel] [PATCH -V3 13/32] virtio-9p: Implement P9_TFLUSH
From: Anthony Liguori aligu...@us.ibm.com
Don't do anything special for flush
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
hw/virtio-9p.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 4478e57..1dbb982 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -1717,10 +1717,11 @@ out:
static void v9fs_flush(V9fsState *s, V9fsPDU *pdu)
{
-if (debug_9p_pdu)
-pprint_pdu(pdu);
+/* A nop call with no return */
+complete_pdu(s, pdu, 7);
}
+
typedef struct V9fsRemoveState {
V9fsPDU *pdu;
size_t offset;
--
1.7.0.2.323.g0d092
[Qemu-devel] [PATCH -V3 17/32] Implement sync support in 9p server
From: M. Mohan Kumar mo...@in.ibm.com
When wstat is called with stat field values set to 'don't touch' pattern,
9p Server interprets it as a request to guarantee that the contents of
the associated file are committed to stable storage before the Rwstat
message is returned. Implement this feature in the server side.
[jv...@linux.vnet.ibm.com: Proper error handling and state friendliness]
Signed-off-by: M. Mohan Kumar mo...@in.ibm.com
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
hw/virtio-9p-local.c |6 ++
hw/virtio-9p.c | 45 +
hw/virtio-9p.h |1 +
3 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
index 4dd6b22..4584bf6 100644
--- a/hw/virtio-9p-local.c
+++ b/hw/virtio-9p-local.c
@@ -249,6 +249,11 @@ static int local_remove(V9fsState *s, const char *path)
}
+static int local_fsync(V9fsState *s, int fd)
+{
+return fsync(fd);
+}
+
static V9fsPosixFileOperations ops = {
.lstat = local_lstat,
.setuid = local_setuid,
@@ -277,6 +282,7 @@ static V9fsPosixFileOperations ops = {
.chown = local_chown,
.utime = local_utime,
.remove = local_remove,
+.fsync = local_fsync,
};
V9fsPosixFileOperations *virtio_9p_init_local(const char *path)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 3ddf2b9..3a5b3f0 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -172,6 +172,11 @@ static int posix_remove(V9fsState *s, V9fsString *path)
return s-ops-remove(s, path-data);
}
+static int posix_fsync(V9fsState *s, int fd)
+{
+return s-ops-fsync(s, fd);
+}
+
static void v9fs_string_init(V9fsString *str)
{
str-data = NULL;
@@ -1889,6 +1894,39 @@ out:
qemu_free(vs);
}
+static void v9fs_wstat_post_fsync(V9fsState *s, V9fsWstatState *vs, int err)
+{
+if (err == -1) {
+err = -errno;
+}
+v9fs_stat_free(vs-v9stat);
+complete_pdu(s, vs-pdu, err);
+qemu_free(vs);
+}
+
+static int donttouch_stat(V9fsStat *stat)
+{
+if (stat-type == -1
+ stat-dev == -1
+ stat-qid.type == -1
+ stat-qid.version == -1
+ stat-qid.path == -1
+ stat-mode == -1
+ stat-atime == -1
+ stat-mtime == -1
+ stat-length == -1
+ !stat-name.size
+ !stat-uid.size
+ !stat-gid.size
+ !stat-muid.size
+ stat-n_uid == -1
+ stat-n_gid == -1
+ stat-n_muid == -1)
+ return 1;
+ else
+ return 0;
+}
+
static void v9fs_wstat(V9fsState *s, V9fsPDU *pdu)
{
V9fsWstatState *vs;
@@ -1906,6 +1944,13 @@ static void v9fs_wstat(V9fsState *s, V9fsPDU *pdu)
goto out;
}
+/* do we need to sync the file? */
+if (donttouch_stat(vs-v9stat)) {
+err = posix_fsync(s, vs-fidp-fd);
+v9fs_wstat_post_fsync(s, vs, err);
+return;
+}
+
if (vs-v9stat.mode != -1) {
if (vs-v9stat.mode P9_STAT_MODE_DIR vs-fidp-dir == NULL) {
err = -EIO;
diff --git a/hw/virtio-9p.h b/hw/virtio-9p.h
index 3fc88a4..da0aa64 100644
--- a/hw/virtio-9p.h
+++ b/hw/virtio-9p.h
@@ -182,6 +182,7 @@ typedef struct V9fsPosixFileOpertions
int (*fstat)(V9fsState *, int, struct stat *);
int (*rename)(V9fsState *, const char *, const char *);
int (*truncate)(V9fsState *, const char *, off_t);
+int (*fsync)(V9fsState *, int);
void *opaque;
} V9fsPosixFileOperations;
--
1.7.0.2.323.g0d092
[Qemu-devel] [PATCH -V3 18/32] virtio-9p: Fix sg usage in the code
sg list contain more than one element and we need to use the right
element when we are doing the marshaling and unmarshaling of data.
This patch also abstract out the pack/unpack interface and make sure
we use one function for doing both.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
hw/virtio-9p-debug.c | 83 +
hw/virtio-9p.c | 57 --
hw/virtio-9p.h |9 +
3 files changed, 98 insertions(+), 51 deletions(-)
diff --git a/hw/virtio-9p-debug.c b/hw/virtio-9p-debug.c
index 9230659..ee222db 100644
--- a/hw/virtio-9p-debug.c
+++ b/hw/virtio-9p-debug.c
@@ -29,92 +29,121 @@ static struct iovec *get_sg(V9fsPDU *pdu, int rx)
return pdu-elem.out_sg;
}
+static int get_sg_count(V9fsPDU *pdu, int rx)
+{
+if (rx)
+return pdu-elem.in_num;
+return pdu-elem.out_num;
+
+}
+
static void pprint_int8(V9fsPDU *pdu, int rx, size_t *offsetp,
const char *name)
{
-struct iovec *sg = get_sg(pdu, rx);
+size_t copied;
+int count = get_sg_count(pdu, rx);
size_t offset = *offsetp;
+struct iovec *sg = get_sg(pdu, rx);
int8_t value;
-BUG_ON((offset + sizeof(value)) sg[0].iov_len);
+copied = do_pdu_unpack(value, sg, count, offset, sizeof(value));
-memcpy(value, sg[0].iov_base + offset, sizeof(value));
+BUG_ON(copied != sizeof(value));
offset += sizeof(value);
-
fprintf(llogfile, %s=0x%x, name, value);
-
*offsetp = offset;
}
static void pprint_int16(V9fsPDU *pdu, int rx, size_t *offsetp,
const char *name)
{
+size_t copied;
+int count = get_sg_count(pdu, rx);
struct iovec *sg = get_sg(pdu, rx);
size_t offset = *offsetp;
int16_t value;
-BUG_ON((offset + sizeof(value)) sg[0].iov_len);
-memcpy(value, sg[0].iov_base + offset, sizeof(value));
-offset += sizeof(value);
+copied = do_pdu_unpack(value, sg, count, offset, sizeof(value));
+BUG_ON(copied != sizeof(value));
+offset += sizeof(value);
fprintf(llogfile, %s=0x%x, name, value);
-
*offsetp = offset;
}
static void pprint_int32(V9fsPDU *pdu, int rx, size_t *offsetp,
const char *name)
{
+size_t copied;
+int count = get_sg_count(pdu, rx);
struct iovec *sg = get_sg(pdu, rx);
size_t offset = *offsetp;
int32_t value;
-BUG_ON((offset + sizeof(value)) sg[0].iov_len);
-memcpy(value, sg[0].iov_base + offset, sizeof(value));
-offset += sizeof(value);
+copied = do_pdu_unpack(value, sg, count, offset, sizeof(value));
+BUG_ON(copied != sizeof(value));
+offset += sizeof(value);
fprintf(llogfile, %s=0x%x, name, value);
-
*offsetp = offset;
}
static void pprint_int64(V9fsPDU *pdu, int rx, size_t *offsetp,
const char *name)
{
+size_t copied;
+int count = get_sg_count(pdu, rx);
struct iovec *sg = get_sg(pdu, rx);
size_t offset = *offsetp;
int64_t value;
-BUG_ON((offset + sizeof(value)) sg[0].iov_len);
-memcpy(value, sg[0].iov_base + offset, sizeof(value));
-offset += sizeof(value);
+copied = do_pdu_unpack(value, sg, count, offset, sizeof(value));
+BUG_ON(copied != sizeof(value));
+offset += sizeof(value);
fprintf(llogfile, %s=0x% PRIx64, name, value);
-
*offsetp = offset;
}
static void pprint_str(V9fsPDU *pdu, int rx, size_t *offsetp, const char *name)
{
+int sg_count = get_sg_count(pdu, rx);
struct iovec *sg = get_sg(pdu, rx);
size_t offset = *offsetp;
-int16_t size;
+uint16_t tmp_size, size;
size_t result;
+size_t copied = 0;
+int i = 0;
-BUG_ON((offset + 2) sg[0].iov_len);
-memcpy(size, sg[0].iov_base + offset, 2);
-offset += 2;
+/* get the size */
+copied = do_pdu_unpack(tmp_size, sg, sg_count, offset, sizeof(tmp_size));
+BUG_ON(copied != sizeof(tmp_size));
+size = le16_to_cpupu(tmp_size);
+offset += copied;
-BUG_ON((offset + size) sg[0].iov_len);
fprintf(llogfile, %s=, name);
-result = fwrite(sg[0].iov_base + offset, 1, size, llogfile);
-BUG_ON(result != size);
-offset += size;
-
-*offsetp = offset;
+for (i = 0; size i sg_count; i++) {
+size_t len;
+if (offset = sg[i].iov_len) {
+/* skip this sg */
+offset -= sg[i].iov_len;
+continue;
+} else {
+len = MIN(sg[i].iov_len - offset, size);
+result = fwrite(sg[i].iov_base + offset, 1, len, llogfile);
+BUG_ON(result != len);
+size -= len;
+copied += len;
+if (size) {
+offset = 0;
+continue;
+}
+}
+}
+*offsetp += copied;
}
static void pprint_qid(V9fsPDU *pdu, int rx, size_t *offsetp, const char *name)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index
[Qemu-devel] [PATCH -V3 19/32] virtio-9p: Get the correct count values from the pdu
From: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
PDU contain little endian format for integer values. So
we need to make sure we map them to host format. Also the count
value can be in another sg offset other than 0. Use the righ
functions to get the count value
Signed-off-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
hw/virtio-9p-debug.c | 29 +++--
1 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/hw/virtio-9p-debug.c b/hw/virtio-9p-debug.c
index ee222db..e8ede8e 100644
--- a/hw/virtio-9p-debug.c
+++ b/hw/virtio-9p-debug.c
@@ -181,20 +181,25 @@ static void pprint_stat(V9fsPDU *pdu, int rx, size_t
*offsetp, const char *name)
static void pprint_strs(V9fsPDU *pdu, int rx, size_t *offsetp, const char
*name)
{
+int sg_count = get_sg_count(pdu, rx);
struct iovec *sg = get_sg(pdu, rx);
size_t offset = *offsetp;
-int16_t count, i;
+uint16_t tmp_count, count, i;
+size_t copied = 0;
fprintf(llogfile, %s={, name);
-BUG_ON((offset + 2) sg[0].iov_len);
-memcpy(count, sg[0].iov_base + offset, 2);
-offset += 2;
+/* Get the count */
+copied = do_pdu_unpack(tmp_count, sg, sg_count, offset,
sizeof(tmp_count));
+BUG_ON(copied != sizeof(tmp_count));
+count = le16_to_cpupu(tmp_count);
+offset += copied;
for (i = 0; i count; i++) {
char str[512];
-if (i)
+if (i) {
fprintf(llogfile, , );
+}
snprintf(str, sizeof(str), [%d], i);
pprint_str(pdu, rx, offset, str);
}
@@ -206,20 +211,24 @@ static void pprint_strs(V9fsPDU *pdu, int rx, size_t
*offsetp, const char *name)
static void pprint_qids(V9fsPDU *pdu, int rx, size_t *offsetp, const char
*name)
{
+int sg_count = get_sg_count(pdu, rx);
struct iovec *sg = get_sg(pdu, rx);
size_t offset = *offsetp;
-int16_t count, i;
+uint16_t tmp_count, count, i;
+size_t copied = 0;
fprintf(llogfile, %s={, name);
-BUG_ON((offset + 2) sg[0].iov_len);
-memcpy(count, sg[0].iov_base + offset, 2);
-offset += 2;
+copied = do_pdu_unpack(tmp_count, sg, sg_count, offset,
sizeof(tmp_count));
+BUG_ON(copied != sizeof(tmp_count));
+count = le16_to_cpupu(tmp_count);
+offset += copied;
for (i = 0; i count; i++) {
char str[512];
-if (i)
+if (i) {
fprintf(llogfile, , );
+}
snprintf(str, sizeof(str), [%d], i);
pprint_qid(pdu, rx, offset, str);
}
--
1.7.0.2.323.g0d092
[Qemu-devel] [PATCH -V3 22/32] virtio-9p: Update existing fid path on rename
We need to make sure that we update the path component of the existing
fid's when we rename a file. The client is not expected to clunk these fids
pointing to the old name. If we don't update any operation on the old unopened
fid will point to the old name and will fail
Add BUG_ON to make sure when we clone a fid, we don't have open descriptor
attached to the fid. We also need to make sure that when we open a fid, the
specified fid should not already be opened. Capture the case by adding a BUG_ON
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
hw/virtio-9p.c | 39 +++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index c8ab6b6..9aa4b72 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -955,6 +955,9 @@ 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);
v9fs_string_init(vs-path);
vs-name_idx = 0;
@@ -1120,6 +1123,9 @@ static void v9fs_open(V9fsState *s, V9fsPDU *pdu)
goto out;
}
+BUG_ON(vs-fidp-fd != -1);
+BUG_ON(vs-fidp-dir);
+
err = posix_lstat(s, vs-fidp-path, vs-stbuf);
v9fs_open_post_lstat(s, vs, err);
@@ -1877,8 +1883,19 @@ out:
qemu_free(vs);
}
+static void v9fs_fix_path(V9fsString *dst, V9fsString *src, int len)
+{
+V9fsString str;
+v9fs_string_init(str);
+v9fs_string_copy(str, dst);
+v9fs_string_sprintf(dst, %s%s, src-data, str.data+len);
+v9fs_string_free(str);
+}
+
+
static void v9fs_wstat_post_chown(V9fsState *s, V9fsWstatState *vs, int err)
{
+V9fsFidState *fidp;
if (err 0) {
goto out;
}
@@ -1905,6 +1922,28 @@ static void v9fs_wstat_post_chown(V9fsState *s,
V9fsWstatState *vs, int err)
if (strcmp(new_name, vs-fidp-path.data) != 0) {
if (posix_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));
+}
+}
+v9fs_string_copy(vs-fidp-path, vs-nname);
}
}
}
--
1.7.0.2.323.g0d092
[Qemu-devel] [PATCH -V3 21/32] virtio-9p: Remove unnecessary definition of fid
We already have fid as a part of V9fsFidState so use that instead
of defining another variable
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Reviewed-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
---
hw/virtio-9p.c | 62 ++-
1 files changed, 29 insertions(+), 33 deletions(-)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 3ce26ca..c8ab6b6 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -770,7 +770,6 @@ out:
typedef struct V9fsStatState {
V9fsPDU *pdu;
size_t offset;
-int32_t fid;
V9fsStat v9stat;
V9fsFidState *fidp;
struct stat stbuf;
@@ -798,6 +797,7 @@ out:
static void v9fs_stat(V9fsState *s, V9fsPDU *pdu)
{
+int32_t fid;
V9fsStatState *vs;
ssize_t err = 0;
@@ -807,9 +807,9 @@ static void v9fs_stat(V9fsState *s, V9fsPDU *pdu)
memset(vs-v9stat, 0, sizeof(vs-v9stat));
-pdu_unmarshal(vs-pdu, vs-offset, d, vs-fid);
+pdu_unmarshal(vs-pdu, vs-offset, d, fid);
-vs-fidp = lookup_fid(s, vs-fid);
+vs-fidp = lookup_fid(s, fid);
if (vs-fidp == NULL) {
err = -ENOENT;
goto out;
@@ -828,8 +828,6 @@ out:
typedef struct V9fsWalkState {
V9fsPDU *pdu;
size_t offset;
-int32_t fid;
-int32_t newfid;
int16_t nwnames;
int name_idx;
V9fsQID *qids;
@@ -867,7 +865,7 @@ static void v9fs_walk_post_newfid_lstat(V9fsState *s,
V9fsWalkState *vs,
int err)
{
if (err == -1) {
-free_fid(s, vs-newfid);
+free_fid(s, vs-newfidp-fid);
v9fs_string_free(vs-path);
err = -ENOENT;
goto out;
@@ -924,6 +922,7 @@ out:
static void v9fs_walk(V9fsState *s, V9fsPDU *pdu)
{
+int32_t fid, newfid;
V9fsWalkState *vs;
int err = 0;
int i;
@@ -934,8 +933,8 @@ static void v9fs_walk(V9fsState *s, V9fsPDU *pdu)
vs-qids = NULL;
vs-offset = 7;
-vs-offset += pdu_unmarshal(vs-pdu, vs-offset, ddw, vs-fid,
-vs-newfid, vs-nwnames);
+vs-offset += pdu_unmarshal(vs-pdu, vs-offset, ddw, fid,
+newfid, vs-nwnames);
if(vs-nwnames) {
vs-wnames = qemu_mallocz(sizeof(vs-wnames[0]) * vs-nwnames);
@@ -948,14 +947,14 @@ static void v9fs_walk(V9fsState *s, V9fsPDU *pdu)
}
}
-vs-fidp = lookup_fid(s, vs-fid);
+vs-fidp = lookup_fid(s, fid);
if (vs-fidp == NULL) {
err = -ENOENT;
goto out;
}
/* FIXME: is this really valid? */
-if (vs-fid == vs-newfid) {
+if (fid == newfid) {
v9fs_string_init(vs-path);
vs-name_idx = 0;
@@ -969,7 +968,7 @@ static void v9fs_walk(V9fsState *s, V9fsPDU *pdu)
return;
}
} else {
-vs-newfidp = alloc_fid(s, vs-newfid);
+vs-newfidp = alloc_fid(s, newfid);
if (vs-newfidp == NULL) {
err = -EINVAL;
goto out;
@@ -1000,7 +999,6 @@ out:
typedef struct V9fsOpenState {
V9fsPDU *pdu;
size_t offset;
-int32_t fid;
int8_t mode;
V9fsFidState *fidp;
V9fsQID qid;
@@ -1105,7 +1103,7 @@ out:
static void v9fs_open(V9fsState *s, V9fsPDU *pdu)
{
-
+int32_t fid;
V9fsOpenState *vs;
ssize_t err = 0;
@@ -1114,9 +1112,9 @@ static void v9fs_open(V9fsState *s, V9fsPDU *pdu)
vs-pdu = pdu;
vs-offset = 7;
-pdu_unmarshal(vs-pdu, vs-offset, db, vs-fid, vs-mode);
+pdu_unmarshal(vs-pdu, vs-offset, db, fid, vs-mode);
-vs-fidp = lookup_fid(s, vs-fid);
+vs-fidp = lookup_fid(s, fid);
if (vs-fidp == NULL) {
err = -ENOENT;
goto out;
@@ -1183,7 +1181,6 @@ static void print_sg(struct iovec *sg, int cnt)
typedef struct V9fsReadState {
V9fsPDU *pdu;
size_t offset;
-int32_t fid;
int32_t count;
int32_t total;
int64_t off;
@@ -1346,6 +1343,7 @@ out:
static void v9fs_read(V9fsState *s, V9fsPDU *pdu)
{
+int32_t fid;
V9fsReadState *vs;
ssize_t err = 0;
@@ -1356,9 +1354,9 @@ static void v9fs_read(V9fsState *s, V9fsPDU *pdu)
vs-len = 0;
vs-count = 0;
-pdu_unmarshal(vs-pdu, vs-offset, dqd, vs-fid, vs-off, vs-count);
+pdu_unmarshal(vs-pdu, vs-offset, dqd, fid, vs-off, vs-count);
-vs-fidp = lookup_fid(s, vs-fid);
+vs-fidp = lookup_fid(s, fid);
if (vs-fidp == NULL) {
err = -EINVAL;
goto out;
@@ -1407,7 +1405,6 @@ out:
typedef struct V9fsWriteState {
V9fsPDU *pdu;
size_t offset;
-int32_t fid;
int32_t len;
int32_t count;
int32_t total;
@@ -1476,6 +1473,7 @@ out:
static void v9fs_write(V9fsState *s, V9fsPDU *pdu)
{
+int32_t fid;
V9fsWriteState *vs;
ssize_t err;
@@ -1487,10 +1485,10 @@ static void v9fs_write(V9fsState *s, V9fsPDU *pdu)
vs-total = 0;
vs-len = 0;
-pdu_unmarshal(vs-pdu, vs-offset, dqdv, vs-fid, vs-off,
[Qemu-devel] [PATCH -V3 20/32] virtio-9p: Remove BUG_ON and add proper error handling
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
hw/virtio-9p.c | 106
1 files changed, 84 insertions(+), 22 deletions(-)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 1237bac..3ce26ca 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -244,7 +244,6 @@ static V9fsFidState *alloc_fid(V9fsState *s, int32_t fid)
return NULL;
f = qemu_mallocz(sizeof(V9fsFidState));
-BUG_ON(f == NULL);
f-fid = fid;
f-fd = -1;
@@ -320,15 +319,18 @@ static void stat_to_qid(const struct stat *stbuf, V9fsQID
*qidp)
qidp-type |= P9_QID_TYPE_SYMLINK;
}
-static void fid_to_qid(V9fsState *s, V9fsFidState *fidp, V9fsQID *qidp)
+static int fid_to_qid(V9fsState *s, V9fsFidState *fidp, V9fsQID *qidp)
{
struct stat stbuf;
int err;
err = posix_lstat(s, fidp-path, stbuf);
-BUG_ON(err == -1);
+if (err) {
+return err;
+}
stat_to_qid(stbuf, qidp);
+return 0;
}
static V9fsPDU *alloc_pdu(V9fsState *s)
@@ -653,7 +655,7 @@ static uint32_t stat_to_v9mode(const struct stat *stbuf)
return mode;
}
-static void stat_to_v9stat(V9fsState *s, V9fsString *name,
+static int stat_to_v9stat(V9fsState *s, V9fsString *name,
const struct stat *stbuf,
V9fsStat *v9stat)
{
@@ -681,7 +683,10 @@ static void stat_to_v9stat(V9fsState *s, V9fsString *name,
if (v9stat-mode P9_STAT_MODE_SYMLINK) {
err = posix_readlink(s, name, v9stat-extension);
-BUG_ON(err == -1);
+if (err == -1) {
+err = -errno;
+return err;
+}
v9stat-extension.data[err] = 0;
v9stat-extension.size = err;
} else if (v9stat-mode P9_STAT_MODE_DEVICE) {
@@ -708,6 +713,7 @@ static void stat_to_v9stat(V9fsState *s, V9fsString *name,
v9fs_string_size(v9stat-gid) +
v9fs_string_size(v9stat-muid) +
v9fs_string_size(v9stat-extension);
+return 0;
}
static void v9fs_version(V9fsState *s, V9fsPDU *pdu)
@@ -745,7 +751,12 @@ static void v9fs_attach(V9fsState *s, V9fsPDU *pdu)
fidp-uid = n_uname;
v9fs_string_sprintf(fidp-path, %s, /);
-fid_to_qid(s, fidp, qid);
+err = fid_to_qid(s, fidp, qid);
+if (err) {
+err = -EINVAL;
+free_fid(s, fid);
+goto out;
+}
offset += pdu_marshal(pdu, offset, Q, qid);
@@ -772,7 +783,10 @@ static void v9fs_stat_post_lstat(V9fsState *s,
V9fsStatState *vs, int err)
goto out;
}
-stat_to_v9stat(s, vs-fidp-path, vs-stbuf, vs-v9stat);
+err = stat_to_v9stat(s, vs-fidp-path, vs-stbuf, vs-v9stat);
+if (err) {
+goto out;
+}
vs-offset += pdu_marshal(vs-pdu, vs-offset, wS, 0, vs-v9stat);
err = vs-offset;
@@ -925,10 +939,8 @@ static void v9fs_walk(V9fsState *s, V9fsPDU *pdu)
if(vs-nwnames) {
vs-wnames = qemu_mallocz(sizeof(vs-wnames[0]) * vs-nwnames);
-BUG_ON(vs-wnames == NULL);
vs-qids = qemu_mallocz(sizeof(vs-qids[0]) * vs-nwnames);
-BUG_ON(vs-qids == NULL);
for (i = 0; i vs-nwnames; i++) {
vs-offset += pdu_unmarshal(vs-pdu, vs-offset, s,
@@ -1070,7 +1082,10 @@ out:
static void v9fs_open_post_lstat(V9fsState *s, V9fsOpenState *vs, int err)
{
-BUG_ON(err == -1);
+if (err) {
+err = -errno;
+goto out;
+}
stat_to_qid(vs-stbuf, vs-qid);
@@ -1082,7 +1097,10 @@ static void v9fs_open_post_lstat(V9fsState *s,
V9fsOpenState *vs, int err)
omode_to_uflags(vs-mode));
v9fs_open_post_open(s, vs, err);
}
-
+return;
+out:
+complete_pdu(s, vs-pdu, err);
+qemu_free(vs);
}
static void v9fs_open(V9fsState *s, V9fsPDU *pdu)
@@ -1186,11 +1204,15 @@ static void v9fs_read_post_readdir(V9fsState *,
V9fsReadState *, ssize_t );
static void v9fs_read_post_seekdir(V9fsState *s, V9fsReadState *vs, ssize_t
err)
{
+if (err) {
+goto out;
+}
v9fs_stat_free(vs-v9stat);
v9fs_string_free(vs-name);
vs-offset += pdu_marshal(vs-pdu, vs-offset, d, vs-count);
vs-offset += vs-count;
err = vs-offset;
+out:
complete_pdu(s, vs-pdu, err);
qemu_free(vs);
return;
@@ -1199,8 +1221,14 @@ static void v9fs_read_post_seekdir(V9fsState *s,
V9fsReadState *vs, ssize_t err)
static void v9fs_read_post_dir_lstat(V9fsState *s, V9fsReadState *vs,
ssize_t err)
{
-BUG_ON(err == -1);
-stat_to_v9stat(s, vs-name, vs-stbuf, vs-v9stat);
+if (err) {
+ err = -errno;
+ goto out;
+}
+err = stat_to_v9stat(s, vs-name, vs-stbuf, vs-v9stat);
+if (err) {
+goto out;
+}
vs-len = pdu_marshal(vs-pdu, vs-offset + 4 + vs-count, S,
vs-v9stat);
@@ -1217,6 +1245,11 @@ static void
