[Qemu-devel] [PATCH] build: set up capabilities on qemu-bridge-helper

2013-11-12 Thread Avi Kivity
. Perhaps we need a configure flag to disable helpers. Signed-off-by: Avi Kivity a...@cloudius-systems.com --- Makefile | 3 +++ rules.mak | 2 ++ 2 files changed, 5 insertions(+) diff --git a/Makefile b/Makefile index b15003f..af7748c 100644 --- a/Makefile +++ b/Makefile @@ -188,6 +188,7 @@ qemu

Re: [Qemu-devel] [PATCH] build: set up capabilities on qemu-bridge-helper

2013-11-12 Thread Avi Kivity
On Nov 12, 2013 9:23 PM, Eric Blake ebl...@redhat.com wrote: On 11/12/2013 04:10 AM, Avi Kivity wrote: Out-of-the-box, 'make install' sets up an unusable qemu-bridge-helper since it doesn't have the required capabilities. Fix by adding them. Note: this may break installing as non

Re: [Qemu-devel] [PATCH v2 5/7] exec: memory radix tree page level compression

2013-11-14 Thread Avi Kivity
Michael S. Tsirkin mst at redhat.com writes: At the moment, memory radix tree is already variable width, but it can only skip the low bits of address. This is efficient if we have huge memory regions but inefficient if we are only using a tiny portion of the address space. After we

Re: [Qemu-devel] [PATCH] build: set up capabilities on qemu-bridge-helper

2013-11-14 Thread Avi Kivity
On 11/14/2013 03:29 PM, Stefan Hajnoczi wrote: On Tue, Nov 12, 2013 at 01:10:24PM +0200, Avi Kivity wrote: Out-of-the-box, 'make install' sets up an unusable qemu-bridge-helper since it doesn't have the required capabilities. Fix by adding them. Up until now, downstreams had to make

Re: [Qemu-devel] [PATCH v2 5/7] exec: memory radix tree page level?compression

2013-11-14 Thread Avi Kivity
On 11/14/2013 04:40 PM, Michael S. Tsirkin wrote: On Thu, Nov 14, 2013 at 08:54:11AM +, Avi Kivity wrote: Michael S. Tsirkin mst at redhat.com writes: At the moment, memory radix tree is already variable width, but it can only skip the low bits of address. This is efficient if we have

Re: [Qemu-devel] [PATCH v2 5/7] exec: memory radix tree page level?compression

2013-11-14 Thread Avi Kivity
On 11/14/2013 05:37 PM, Michael S. Tsirkin wrote: On Thu, Nov 14, 2013 at 04:56:43PM +0200, Avi Kivity wrote: On 11/14/2013 04:40 PM, Michael S. Tsirkin wrote: On Thu, Nov 14, 2013 at 08:54:11AM +, Avi Kivity wrote: Michael S. Tsirkin mst at redhat.com writes: At the moment, memory

Re: [Qemu-devel] [PATCH v2 5/7] exec: memory radix tree page level?compression

2013-11-17 Thread Avi Kivity
On 11/17/2013 05:37 PM, Michael S. Tsirkin wrote: On Thu, Nov 14, 2013 at 05:42:26PM +0200, Avi Kivity wrote: On 11/14/2013 05:37 PM, Michael S. Tsirkin wrote: On Thu, Nov 14, 2013 at 04:56:43PM +0200, Avi Kivity wrote: On 11/14/2013 04:40 PM, Michael S. Tsirkin wrote: On Thu, Nov 14, 2013

Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table

2013-11-26 Thread Avi Kivity
On Tue, Nov 26, 2013 at 2:47 PM, Paolo Bonzini pbonz...@redhat.com wrote: Il 26/11/2013 13:40, Zhanghaoyu (A) ha scritto: When guest set irq smp_affinity, VMEXIT occurs, then the vcpu thread will IOCTL return to QEMU from hypervisor, then vcpu thread ask the hypervisor to update the irq routing

Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table

2013-11-26 Thread Avi Kivity
On Tue, Nov 26, 2013 at 3:47 PM, Paolo Bonzini pbonz...@redhat.com wrote: Il 26/11/2013 14:18, Avi Kivity ha scritto: I don't think a workqueue is even needed. You just need to use call_rcu to free old after releasing kvm-irq_lock. What do you think? Can this cause an interrupt

Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table

2013-11-26 Thread Avi Kivity
On 11/26/2013 04:46 PM, Paolo Bonzini wrote: Il 26/11/2013 15:36, Avi Kivity ha scritto: No, this would be exactly the same code that is running now: mutex_lock(kvm-irq_lock); old = kvm-irq_routing; kvm_irq_routing_update(kvm, new

Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table

2013-11-26 Thread Avi Kivity
On 11/26/2013 05:03 PM, Gleb Natapov wrote: On Tue, Nov 26, 2013 at 04:54:44PM +0200, Avi Kivity wrote: On 11/26/2013 04:46 PM, Paolo Bonzini wrote: Il 26/11/2013 15:36, Avi Kivity ha scritto: No, this would be exactly the same code that is running now: mutex_lock(kvm

Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table

2013-11-26 Thread Avi Kivity
On 11/26/2013 05:20 PM, Paolo Bonzini wrote: Il 26/11/2013 16:03, Gleb Natapov ha scritto: I understood the proposal was also to eliminate the synchronize_rcu(), so while new interrupts would see the new routing table, interrupts already in flight could pick up the old one. Isn't that always

Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table

2013-11-26 Thread Avi Kivity
On 11/26/2013 05:28 PM, Paolo Bonzini wrote: Il 26/11/2013 16:25, Avi Kivity ha scritto: If we want to ensure, we need to use a different mechanism for synchronization than the global RCU. QRCU would work; readers are not wait-free but only if there is a concurrent synchronize_qrcu, which

Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table

2013-11-26 Thread Avi Kivity
On 11/26/2013 05:58 PM, Paolo Bonzini wrote: Il 26/11/2013 16:35, Avi Kivity ha scritto: If we want to ensure, we need to use a different mechanism for synchronization than the global RCU. QRCU would work; readers are not wait-free but only if there is a concurrent synchronize_qrcu, which

Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table

2013-11-26 Thread Avi Kivity
On 11/26/2013 06:11 PM, Michael S. Tsirkin wrote: On Tue, Nov 26, 2013 at 06:06:26PM +0200, Avi Kivity wrote: On 11/26/2013 05:58 PM, Paolo Bonzini wrote: Il 26/11/2013 16:35, Avi Kivity ha scritto: If we want to ensure, we need to use a different mechanism for synchronization than the global

Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table

2013-11-26 Thread Avi Kivity
On 11/26/2013 06:24 PM, Gleb Natapov wrote: On Tue, Nov 26, 2013 at 04:20:27PM +0100, Paolo Bonzini wrote: Il 26/11/2013 16:03, Gleb Natapov ha scritto: I understood the proposal was also to eliminate the synchronize_rcu(), so while new interrupts would see the new routing table, interrupts

Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table

2013-11-26 Thread Avi Kivity
On 11/26/2013 06:28 PM, Paolo Bonzini wrote: Il 26/11/2013 17:24, Gleb Natapov ha scritto: VCPU writes to routing table e = entry from IRQ routing table kvm_irq_routing_update(kvm, new); VCPU resumes execution

Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table

2013-11-28 Thread Avi Kivity
On 11/28/2013 11:19 AM, Gleb Natapov wrote: On Thu, Nov 28, 2013 at 09:55:42AM +0100, Paolo Bonzini wrote: Il 28/11/2013 07:27, Zhanghaoyu (A) ha scritto: Without synchronize_rcu you could have VCPU writes to routing table e = entry from IRQ routing

Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table

2013-11-28 Thread Avi Kivity
On 11/28/2013 12:11 PM, Gleb Natapov wrote: On Thu, Nov 28, 2013 at 11:49:00AM +0200, Avi Kivity wrote: On 11/28/2013 11:19 AM, Gleb Natapov wrote: On Thu, Nov 28, 2013 at 09:55:42AM +0100, Paolo Bonzini wrote: Il 28/11/2013 07:27, Zhanghaoyu (A) ha scritto: Without synchronize_rcu you could

Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table

2013-11-28 Thread Avi Kivity
On 11/28/2013 11:53 AM, Paolo Bonzini wrote: Il 28/11/2013 10:49, Avi Kivity ha scritto: Linux is safe, it does interrupt migration from within the interrupt handler. If you do that before the device-specific EOI, you won't get another interrupt until programming the MSI is complete

Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table

2013-11-28 Thread Avi Kivity
On 11/28/2013 12:40 PM, Paolo Bonzini wrote: Il 28/11/2013 11:16, Avi Kivity ha scritto: The QRCU I linked would work great latency-wise (it has roughly the same latency of an rwsem but readers are lock-free). However, the locked operations in the read path would hurt because of cache misses

Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table

2013-11-28 Thread Avi Kivity
On 11/28/2013 01:10 PM, Paolo Bonzini wrote: Il 28/11/2013 12:09, Gleb Natapov ha scritto: - if there are no callbacks, but there are readers, synchronize_srcu busy-loops for some time checking if the readers complete. After a while (20 us for synchronize_srcu, 120 us for

Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table

2013-11-28 Thread Avi Kivity
On 11/28/2013 01:02 PM, Gleb Natapov wrote: On Thu, Nov 28, 2013 at 12:12:55PM +0200, Avi Kivity wrote: On 11/28/2013 12:11 PM, Gleb Natapov wrote: On Thu, Nov 28, 2013 at 11:49:00AM +0200, Avi Kivity wrote: On 11/28/2013 11:19 AM, Gleb Natapov wrote: On Thu, Nov 28, 2013 at 09:55:42AM +0100

Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table

2013-11-28 Thread Avi Kivity
On 11/28/2013 01:22 PM, Gleb Natapov wrote: On Thu, Nov 28, 2013 at 01:18:54PM +0200, Avi Kivity wrote: On 11/28/2013 01:02 PM, Gleb Natapov wrote: On Thu, Nov 28, 2013 at 12:12:55PM +0200, Avi Kivity wrote: On 11/28/2013 12:11 PM, Gleb Natapov wrote: On Thu, Nov 28, 2013 at 11:49:00AM +0200

Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table

2013-11-28 Thread Avi Kivity
On 11/28/2013 01:31 PM, Paolo Bonzini wrote: Il 28/11/2013 12:23, Gleb Natapov ha scritto: Unless what ? :) Unless reader is scheduled out? Yes. Or unless my brain is scheduled out in the middle of a sentence. So we will have to disable preemption in a reader to prevent big latencies for a

Re: [Qemu-devel] outlined TLB lookup on x86

2013-12-08 Thread Avi Kivity
On 11/28/2013 04:12 AM, Richard Henderson wrote: 2. why not use a TLB or bigger size? currently the TLB has 18 entries. the TLB lookup is 10 x86 instructions , but every miss needs ~450 instructions, i measured this using Intel PIN. so even the miss rate is low (say 3%) the overall time spent

[Qemu-devel] [PATCH] enhance gdbstub to support x86-64

2006-07-25 Thread Avi Kivity
The following patch adds x86-64 support to gdbstub. Please consider for inclusion. Index: gdbstub.c === --- gdbstub.c (revision 2399) +++ gdbstub.c (revision 2400) @@ -175,10 +175,144 @@ return 0; } -#if

Re: [Qemu-devel] Wipe patch

2006-07-26 Thread Avi Kivity
Brad Campbell wrote: ZIGLIO, Frediano, VF-IT wrote: Hi, well, this is not a definitive patch but it works. The aim is to be able to wipe the disk without allocating entire space. When you wipe a disk the program fill disk with zero bytes so disk image increase to allocate all space. This just

[Qemu-devel] [PATCH] enhance gdbstub to support x86-64

2006-08-20 Thread Avi Kivity
The following patch adds x86-64 support to gdbstub. Please consider for inclusion. [not subscribed, please cc:] Index: gdbstub.c === --- gdbstub.c (revision 2399) +++ gdbstub.c (revision 2400) @@ -175,10 +175,144 @@

Re: [Qemu-devel] hosting the forum

2006-10-03 Thread Avi Kivity
Sorry, this was meant to be off-list. My apologies. Avi Kivity wrote: Hetz Ben Hamo wrote: Due to some personal problems (related to financial situations) I'm no longer being able to keep paying the server which hosts the QEMU forum. Therefore, I'm looking for someone who can host the QEMU

Re: [Qemu-devel] qemu vs gcc4

2006-10-23 Thread Avi Kivity
Paul Brook wrote: On Monday 23 October 2006 09:16, Martin Guy wrote: Now, gcc4 can produce code with several return instructions (with no option to turn that of, as far as I understand). You cannot cut them out, and therefore you cannot chain the simple functions. ...unless you also

Re: [Qemu-devel] qemu vs gcc4

2006-10-23 Thread Avi Kivity
Paul Brook wrote: That's exactly what my gcc4 hacks do. It gets complicated because a x86 uses variable length insn encodings so you don't know where insn boundaries are, and a jmp instruction is larger than a ret instruction so it's not always possible to do a straight replacement. how

Re: [Qemu-devel] qemu vs gcc4

2006-10-23 Thread Avi Kivity
Paul Brook wrote: We already do that. It doesn't stop gcc putting the return in the middle of the function. Paul void f1(); void f2(); void f(int *z, int x, int y) { if (x) { *z = x; f1(); } else { *z = y; f2(); } asm volatile (); }

Re: [Qemu-devel] [PATCH] Experimental initial patch providing accelerated OpenGL for Linux i386 (2nd attempt to post)

2006-11-19 Thread Avi Kivity
Even Rouault wrote: Apart from portability to other architectures, what would be the other advantages of a solution based on a PCI device ? I can think of a two advantages: - the device can deliver interrupts to the guest when something is completed (I don't know how useful this is to a

Re: [Qemu-devel] Re: NBD server for QEMU images

2006-12-13 Thread Avi Kivity
Anthony Liguori wrote: Mounting a partition being served on the same host as read-write can cause deadlocks. From nbd-2.9.0 README file: This text is pretty old. Is this still valid? This would imply that things like loop can result in dead locks. I don't see why flushing one device

Re: [Qemu-devel] Re: NBD server for QEMU images

2006-12-13 Thread Avi Kivity
Martin Guy wrote: - write tons of data to nbd device, data ends up in pagecache - memory gets low, kswapd wakes up, calls nbd device to actually write the data - nbd issues a request, which ends up on the nbd server on the same machine - the nbd server allocates memory - memory allocation

Re: [Qemu-devel] Re: NBD server for QEMU images

2006-12-14 Thread Avi Kivity
Salvador Fandino wrote: I have run some tests and found that it's easy to cause a deadlock just untaring a file over an nbd device being served from localhost (using the standard nbd-server or my own, it doesn't matter). Another interesting finding is that when the deadlock happens, qemu-nbds

Re: [Qemu-devel] QEMU/pc and scsi disks

2007-03-03 Thread Avi Kivity
Anthony Liguori wrote: I think most people agree that we need a config file. I haven't seen any comments on my config file patch though. So, any comments on that patch? Any requirements on a format? 1. Any option should be settable either in the config file or command line. In other

Re: [Qemu-devel] QEMU/pc and scsi disks

2007-03-04 Thread Avi Kivity
Anthony Liguori wrote: 1. Any option should be settable either in the config file or command line. In other words, the user should not be forced to use a config file. This is useful for management programs who keep all options in an internal database, and for users who can experiment via

Re: [Qemu-devel] [PATCH] Add -name option

2007-03-04 Thread Avi Kivity
Anthony Liguori wrote: This option helps differentiate between guests when running more than one instance of QEMU. It adds a string to the SDL window title and to the VNC server title. Having a name associated with a guest is also terribly useful for management tools as it gives a standard

Re: [Qemu-devel] QEMU/pc and scsi disks

2007-03-04 Thread Avi Kivity
Paul Brook wrote: Out of curiosity, why? If the options are store in some database, as is likely, surely it is easier to generate a longish command line than to generate a unique name for a file, remove it if it already exists, write out the data, launch qemu, and clean up the file later? And

Re: [Qemu-devel] [PATCH] Add -name option

2007-03-04 Thread Avi Kivity
Anthony Liguori wrote: So right now we have: QEMU QEMU - Press Ctrl+Alt to exit grab My patch would add: QEMU (WinXP Home) QEMU (WinXP Home) - Press Ctrl+Alt to exit grab You're suggesting: WinXP Home - QEMU WinXP Home - QEMU - Press Ctrl+Alt to exit grab I like yours for the first title

Re: [Qemu-devel] QEMU/pc and scsi disks

2007-03-04 Thread Avi Kivity
Chris Wilson wrote: Hi Avi, On Sun, 4 Mar 2007, Avi Kivity wrote: Anthony Liguori wrote: I think we should still provide the ability to set the most common options via the command line. I'm also fine with specifying single options on the command line. I suspect though that being able

Re: [Qemu-devel] RFC: This project needs a stable branch

2007-03-15 Thread Avi Kivity
Paul Brook wrote: Whereas I think the single easiest way to increase the user base would be to merge the kvm patches. This is good to hear. I should really have submitted patches to qemu-devel long ago, but have run out of cycles. In addition, I am a little concerned about the kvm

Re: [Qemu-devel] please review this scsi patch

2007-03-19 Thread Avi Kivity
Wang Cheng Yeh wrote: thanks If you include a description of what the patch does and why it is necessary, it will probably be reviewed a lot quicker. -- error compiling committee.c: too many arguments to function ___ Qemu-devel mailing list

Re: [Qemu-devel] [RFC/experimental patch] qemu (x86_64 on x86_64 -no-kqemu) compiles with gcc4 and works

2007-03-25 Thread Avi Kivity
Axel Zeuner wrote: A full featured converter (cvtasm) has a lot of dependencies: it has to support all hosts (M) (with all assembler dialects M') and all targets N, i.e. in the worst case one would end with M'x N variants of it, or M x N if one supports only one assembler dialect per host. It

Re: [Qemu-devel] Exception running under KVM

2007-04-04 Thread Avi Kivity
GSMD wrote: When trying to launch with -- kvm -no-acpi -nographic -m 512 -cdrom /media/ubuntu-7.04-beta-alternate-i386.iso -boot d /opt/ubuntu.img -- I get Code: -- (qemu) exception 12 (0) Please report kvm problems to [EMAIL PROTECTED] This looks like the real-mode emulation problem kvm

Re: [kvm-devel] [Qemu-devel] Fixing ACPI for Vista -- Source code for bios.bin vs. bochs CVS?

2007-05-01 Thread Avi Kivity
Paul Brook wrote: On Monday 30 April 2007, Nakajima, Jun wrote: We found a way to get 32-bit Vista up on KVM by fixing bios.bin. And I think it should be helpful to qemu as well. However, I'm not sure if the binary file has been created simply by applying bios.diff to the latest bochs CVS

[Qemu-devel] Re: [kvm-devel] qemu/kvm seems to take ALSA all for itself?

2007-05-21 Thread Avi Kivity
David Abrahams wrote: When I have windows XP running under kvm, I get [EMAIL PROTECTED]:/tmp$ aplay /usr/share/sounds/gaim/receive.wav ALSA lib pcm_dmix.c:864:(snd_pcm_dmix_open) unable to open slave aplay: main:550: audio open error: Device or resource busy As soon as I shut down my

[Qemu-devel] Re: [kvm-devel] qemu/kvm seems to take ALSA all for itself?

2007-05-23 Thread Avi Kivity
David Abrahams wrote: on Mon May 21 2007, Avi Kivity avi-atKUWr5tajBWk0Htik3J/w-AT-public.gmane.org wrote: David Abrahams wrote: When I have windows XP running under kvm, I get [EMAIL PROTECTED]:/tmp$ aplay /usr/share/sounds/gaim/receive.wav ALSA lib pcm_dmix.c:864

[Qemu-devel] Re: [kvm-devel] PIIX/IDE: ports disabled in PCI config space?

2007-06-05 Thread Avi Kivity
Luca Tettamanti wrote: Hello, I'm testing the new Fedora7 under KVM. As you may know Fedora has migrated to the new libata drivers. ata_piix is unhappy with the PIIX IDE controller provided by QEmu/KVM: [...] The following patch fixes the problem (i.e. ata_piix finds both the HD and

[Qemu-devel] Re: [kvm-devel] PIIX/IDE: ports disabled in PCI config space?

2007-06-05 Thread Avi Kivity
Luca wrote: Good point. I'm looking at bochs right now: the BIOS doesn't touch that bits. The 2 ports are enabled/disabled - using values from the config file - by the reset function of the emulated controller (iodev/pci_ide.cc), so they're doing the same thing I've done for QEMU. I'd rather

Re: [Qemu-devel] Detecting Client OS BSOF/Kernel Oops

2007-06-06 Thread Avi Kivity
Clemens Kolbitsch wrote: Hi! I'd like to detect if the client OS crashes... right now, only for linux, but windows systems will become interesting for me as well in the future... Is there an easy way of detecting if a BSOD or a kernel oops happened?? Maybe that'd be possible by checking if

[Qemu-devel] Re: [PATCH v2 3/7] docs: Add QED image format specification

2010-10-10 Thread Avi Kivity
On 10/08/2010 05:48 PM, Stefan Hajnoczi wrote: Signed-off-by: Stefan Hajnoczistefa...@linux.vnet.ibm.com --- docs/specs/qed_spec.txt | 94 +++ 1 files changed, 94 insertions(+), 0 deletions(-) +Feature bits: +* QED_F_BACKING_FILE = 0x01. The

[Qemu-devel] Re: [PATCH v2 6/7] qed: Read/write support

2010-10-10 Thread Avi Kivity
On 10/08/2010 05:48 PM, Stefan Hajnoczi wrote: This patch implements the read/write state machine. Operations are fully asynchronous and multiple operations may be active at any time. Allocating writes lock tables to ensure metadata updates do not interfere with each other. If two allocating

[Qemu-devel] Re: [PATCH v2 3/7] docs: Add QED image format specification

2010-10-11 Thread Avi Kivity
On 10/11/2010 12:09 PM, Stefan Hajnoczi wrote: On Sun, Oct 10, 2010 at 11:20:09AM +0200, Avi Kivity wrote: On 10/08/2010 05:48 PM, Stefan Hajnoczi wrote: Signed-off-by: Stefan Hajnoczistefa...@linux.vnet.ibm.com --- docs/specs/qed_spec.txt | 94

[Qemu-devel] Re: [PATCH v2 6/7] qed: Read/write support

2010-10-11 Thread Avi Kivity
On 10/11/2010 12:37 PM, Stefan Hajnoczi wrote: On Sun, Oct 10, 2010 at 11:10:15AM +0200, Avi Kivity wrote: On 10/08/2010 05:48 PM, Stefan Hajnoczi wrote: This patch implements the read/write state machine. Operations are fully asynchronous and multiple operations may be active at any

[Qemu-devel] Re: [PATCH v2 3/7] docs: Add QED image format specification

2010-10-11 Thread Avi Kivity
On 10/11/2010 05:02 PM, Anthony Liguori wrote: On 10/11/2010 08:44 AM, Avi Kivity wrote: On 10/11/2010 03:42 PM, Stefan Hajnoczi wrote: A leak is acceptable (it won't grow; it's just an unused, incorrect freelist), but data corruption is not. The alternative is for the freelist

Re: [Qemu-devel] Re: [PATCH v2 3/7] docs: Add QED image format specification

2010-10-11 Thread Avi Kivity
On 10/11/2010 04:54 PM, Anthony Liguori wrote: On 10/11/2010 08:04 AM, Avi Kivity wrote: On 10/11/2010 12:09 PM, Stefan Hajnoczi wrote: On Sun, Oct 10, 2010 at 11:20:09AM +0200, Avi Kivity wrote: On 10/08/2010 05:48 PM, Stefan Hajnoczi wrote: Signed-off-by: Stefan Hajnoczistefa

[Qemu-devel] Re: [PATCH v2 3/7] docs: Add QED image format specification

2010-10-11 Thread Avi Kivity
On 10/11/2010 05:30 PM, Stefan Hajnoczi wrote: It was discussed before, but I don't think we came to a conclusion. Are there any circumstances under which you don't want to set the QED_CF_BACKING_FORMAT flag? I suggest the following: QED_CF_BACKING_FORMAT_RAW = 0x1 When set, the

Re: [Qemu-devel] Re: [PATCH v2 3/7] docs: Add QED image format specification

2010-10-11 Thread Avi Kivity
On 10/11/2010 05:49 PM, Anthony Liguori wrote: On 10/11/2010 09:58 AM, Avi Kivity wrote: A leak is unacceptable. It means an image can grow to an unbounded size. If you are a server provider offering multitenancy, then a malicious guest can potentially grow the image beyond it's allotted

[Qemu-devel] Re: [PATCH v2 3/7] docs: Add QED image format specification

2010-10-11 Thread Avi Kivity
On 10/11/2010 05:41 PM, Anthony Liguori wrote: On 10/11/2010 10:24 AM, Avi Kivity wrote: On 10/11/2010 05:02 PM, Anthony Liguori wrote: On 10/11/2010 08:44 AM, Avi Kivity wrote: On 10/11/2010 03:42 PM, Stefan Hajnoczi wrote: A leak is acceptable (it won't grow; it's just an unused

[Qemu-devel] Re: [PATCH v2 3/7] docs: Add QED image format specification

2010-10-11 Thread Avi Kivity
On 10/11/2010 04:06 PM, Stefan Hajnoczi wrote: On Mon, Oct 11, 2010 at 03:44:38PM +0200, Avi Kivity wrote: On 10/11/2010 03:42 PM, Stefan Hajnoczi wrote: A leak is acceptable (it won't grow; it's just an unused, incorrect freelist), but data corruption

[Qemu-devel] Re: [SeaBIOS] [RFC] Passing boot order from qemu to seabios

2010-10-11 Thread Avi Kivity
On 10/11/2010 05:39 PM, Gleb Natapov wrote: On Mon, Oct 11, 2010 at 05:09:22PM +0200, Avi Kivity wrote: On 10/11/2010 12:18 PM, Gleb Natapov wrote: Currently if VM is started with multiple disks it is almost impossible to guess which one of them will be used as boot device especially

[Qemu-devel] Re: [SeaBIOS] [RFC] Passing boot order from qemu to seabios

2010-10-11 Thread Avi Kivity
On 10/11/2010 12:18 PM, Gleb Natapov wrote: Currently if VM is started with multiple disks it is almost impossible to guess which one of them will be used as boot device especially if there is a mix of ATA/virtio/SCSI devices. Essentially BIOS decides the order and without looking into the code

[Qemu-devel] Re: [PATCH v2 3/7] docs: Add QED image format specification

2010-10-11 Thread Avi Kivity
On 10/11/2010 03:42 PM, Stefan Hajnoczi wrote: A leak is acceptable (it won't grow; it's just an unused, incorrect freelist), but data corruption is not. The alternative is for the freelist to be a non-compat feature bit. That means older QEMU binaries cannot use a QED image that has

Re: [Qemu-devel] Re: [PATCH v2 3/7] docs: Add QED image format specification

2010-10-12 Thread Avi Kivity
On 10/11/2010 06:10 PM, Anthony Liguori wrote: On 10/11/2010 11:02 AM, Avi Kivity wrote: On 10/11/2010 05:49 PM, Anthony Liguori wrote: On 10/11/2010 09:58 AM, Avi Kivity wrote: A leak is unacceptable. It means an image can grow to an unbounded size. If you are a server provider offering

[Qemu-devel] Re: [PATCH v2 6/7] qed: Read/write support

2010-10-12 Thread Avi Kivity
On 10/12/2010 06:16 PM, Anthony Liguori wrote: It's fairly simple to add a sync to this path. It's probably worth checking the prefill/postfill for zeros and avoiding the write/sync if that's the case. That should optimize the common cases of allocating new space within a file. My

[Qemu-devel] Re: [PATCH v2 2/7] cutils: Add bytes_to_str() to format byte values

2010-10-13 Thread Avi Kivity
On 10/08/2010 05:48 PM, Stefan Hajnoczi wrote: From: Anthony Liguorialigu...@us.ibm.com This common function converts byte counts to human-readable strings with proper units. Signed-off-by: Anthony Liguorialigu...@us.ibm.com Signed-off-by: Stefan Hajnoczistefa...@linux.vnet.ibm.com ---

Re: [Qemu-devel] Re: [PATCH v2 6/7] qed: Read/write support

2010-10-13 Thread Avi Kivity
On 10/13/2010 03:24 PM, Anthony Liguori wrote: On 10/13/2010 08:07 AM, Kevin Wolf wrote: Am 13.10.2010 14:13, schrieb Stefan Hajnoczi: We can avoid it when a backing image is not used. Your idea to check for zeroes in the backing image is neat too, it may well reduce the common case even for

Re: [Qemu-devel] Re: [PATCH v2 6/7] qed: Read/write support

2010-10-13 Thread Avi Kivity
On 10/13/2010 04:11 PM, Anthony Liguori wrote: Why would you ever update the header, apart from relocating L1 for some reason? To update the L1/L2 tables clean bit. That's what prevents a check in the normal case where you have a clean shutdown. I see - so you wouldn't update it every

Re: [Qemu-devel] Re: [PATCH v2 6/7] qed: Read/write support

2010-10-13 Thread Avi Kivity
On 10/13/2010 04:07 PM, Stefan Hajnoczi wrote: On Wed, Oct 13, 2010 at 03:50:00PM +0200, Avi Kivity wrote: On 10/13/2010 03:24 PM, Anthony Liguori wrote: On 10/13/2010 08:07 AM, Kevin Wolf wrote: Am 13.10.2010 14:13, schrieb Stefan Hajnoczi: We can avoid it when a backing image

Re: [Qemu-devel] Re: [PATCH v2 6/7] qed: Read/write support

2010-10-13 Thread Avi Kivity
On 10/13/2010 04:53 PM, Anthony Liguori wrote: On 10/13/2010 09:16 AM, Avi Kivity wrote: On 10/13/2010 04:11 PM, Anthony Liguori wrote: Why would you ever update the header, apart from relocating L1 for some reason? To update the L1/L2 tables clean bit. That's what prevents a check

[Qemu-devel] Re: [patch 0/8] port qemu-kvm's MCE support (v3)

2010-10-14 Thread Avi Kivity
On 10/11/2010 08:31 PM, Marcelo Tosatti wrote: Port qemu-kvm's KVM MCE (Machine Check Exception) handling to qemu. It allows qemu to propagate MCEs to the guest. v2: - rename do_qemu_ram_addr_from_host. - fix kvm_on_sigbus/kvm_on_sigbus_vcpu naming. - fix bank register restoration (Dean

Re: [Qemu-devel] Hitting 29 NIC limit

2010-10-14 Thread Avi Kivity
On 10/14/2010 12:54 AM, Anthony Liguori wrote: On 10/13/2010 05:32 PM, Anjali Kulkarni wrote: Hi, Using the legacy way of starting up NICs, I am hitting a limitation after 29 NICs ie no more than 29 are detected (that's because of the 32 PCI slot limit on a single bus- 3 are already taken

Re: [Qemu-devel] Hitting 29 NIC limit

2010-10-14 Thread Avi Kivity
On 10/14/2010 02:54 PM, Anthony Liguori wrote: The key is to make the virtio-net devices multifunction and to fill out all 8 functions for each slot. This is unlikely to work right wrt pci hotplug. Yes. Our hotplug design is based on devices.. This is wrong, it should be based on

Re: [Qemu-devel] Hitting 29 NIC limit

2010-10-14 Thread Avi Kivity
On 10/14/2010 04:11 PM, Anthony Liguori wrote: On 10/14/2010 08:23 AM, Avi Kivity wrote: On 10/14/2010 02:54 PM, Anthony Liguori wrote: The key is to make the virtio-net devices multifunction and to fill out all 8 functions for each slot. This is unlikely to work right wrt pci hotplug

Re: [Qemu-devel] [PATCH 1/3] Introduce threadlets

2010-10-14 Thread Avi Kivity
On 10/14/2010 11:15 AM, Stefan Hajnoczi wrote: I forgot to add that the semantics of cancellation make it difficult to write correct user code. Every cancellation user needs to add extra synchronization after the cancel call to handle the case where the work is currently executing. This seems

Re: [Qemu-devel] [PATCH 1/3] Introduce threadlets

2010-10-17 Thread Avi Kivity
On 10/14/2010 11:32 PM, Venkateswararao Jujjuri (JV) wrote: Blocking is somewhat against the spirit of the thing, no? While I agree that the current cancel API is hard to use correctly, blocking defeats the purpose of the API. Are you proposing to add additional state in the return

[Qemu-devel] Re: [patch 0/8] port qemu-kvm's MCE support (v3 resend)

2010-10-17 Thread Avi Kivity
On 10/11/2010 08:31 PM, Marcelo Tosatti wrote: Port qemu-kvm's KVM MCE (Machine Check Exception) handling to qemu. It allows qemu to propagate MCEs to the guest. v2: - rename do_qemu_ram_addr_from_host. - fix kvm_on_sigbus/kvm_on_sigbus_vcpu naming. - fix bank register restoration (Dean

Re: [Qemu-devel] [PATCH 1/3] Introduce threadlets

2010-10-18 Thread Avi Kivity
On 10/18/2010 12:47 PM, Arun R Bharadwaj wrote: * Avi Kivitya...@redhat.com [2010-10-17 10:57:23]: On 10/14/2010 11:32 PM, Venkateswararao Jujjuri (JV) wrote: Blocking is somewhat against the spirit of the thing, no? While I agree that the current cancel API is hard to use

[Qemu-devel] Re: [PATCH] Add support for async page fault to qemu

2010-10-18 Thread Avi Kivity
On 10/18/2010 05:48 PM, Juan Quintela wrote: Gleb Natapovg...@redhat.com wrote: Add save/restore of MSR for migration and cpuid bit. It is there a way to test if async page faults are in use? Yes, msr != 0 - need a subsection. Good idea. if so, we can add a subsection instead of

[Qemu-devel] Re: [PATCH] Implement a virtio GPU transport

2010-10-19 Thread Avi Kivity
On 10/19/2010 12:31 PM, Ian Molton wrote: an virtualization@, many virtio developers live there. you mean virtualizat...@lists.osdl.org ? Yes. 2. should start with a patch to the virtio-pci spec to document what you're doing Where can I find that spec?

Re: [Qemu-devel] Re: KVM call agenda for Oct 19

2010-10-19 Thread Avi Kivity
On 10/19/2010 02:48 PM, Dor Laor wrote: On 10/19/2010 04:11 AM, Chris Wright wrote: * Juan Quintela (quint...@redhat.com) wrote: Please send in any agenda items you are interested in covering. - 0.13.X -stable handoff - 0.14 planning - threadlet work - virtfs proposals - Live snapshots

Re: [Qemu-devel] Re: KVM call agenda for Oct 19

2010-10-19 Thread Avi Kivity
On 10/19/2010 03:22 PM, Anthony Liguori wrote: I had assumed that this would involve: qemu -hda windows.img (qemu) snapshot ide0-disk0 snap0.img 1) create snap0.img internally by doing the equivalent of `qemu-img create -f qcow2 -b windows.img snap0.img' 2) bdrv_flush('ide0-disk0') 3)

Re: [Qemu-devel] Re: KVM call agenda for Oct 19

2010-10-19 Thread Avi Kivity
On 10/19/2010 02:58 PM, Dor Laor wrote: On 10/19/2010 02:55 PM, Avi Kivity wrote: On 10/19/2010 02:48 PM, Dor Laor wrote: On 10/19/2010 04:11 AM, Chris Wright wrote: * Juan Quintela (quint...@redhat.com) wrote: Please send in any agenda items you are interested in covering. - 0.13.X

Re: [Qemu-devel] Re: KVM call agenda for Oct 19

2010-10-19 Thread Avi Kivity
On 10/19/2010 03:38 PM, Stefan Hajnoczi wrote: bdrv_aio_freeze() or any mechanism to deal with pending requests in the generic block code would be a good step for future live support of other operations like truncate. + logical disk grow, etc. -- error compiling committee.c: too many

Re: [Qemu-devel] KVM call minutes for Oct 19

2010-10-20 Thread Avi Kivity
On 10/20/2010 10:21 AM, Alexander Graf wrote: On 19.10.2010, at 17:14, Chris Wright wrote: 0.13.X -stable - Anthony will send note to qemu-devel on this - move 0.13.X -stable to a separate tree - driven independently of main qemu tree - challenge is always in the porting and testing

[Qemu-devel] Re: [SeaBIOS] [PATCH] mark irq9 active high in DSDT

2010-10-21 Thread Avi Kivity
On 10/21/2010 04:00 AM, Kevin O'Connor wrote: On Wed, Oct 20, 2010 at 11:34:41AM +0200, Gleb Natapov wrote: In PIIX4 SCI (irq9) is active high. Seabios marks it so in interrupt override table, but some OSes (FreeBSD) require the same information to be present in DSDT too. Make it so.

Re: [SeaBIOS] [Qemu-devel] [PATCH 1/2] pci: Automatically patch PCI device id in PCI ROM

2010-10-21 Thread Avi Kivity
On 10/18/2010 08:39 PM, Anthony Liguori wrote: SeaBIOS rejects them when loaded from the rom bar and doesn't reject them when loaded via fw_cfg. What I meant was, rombar=0 in qdev. Sometimes my fingers don't work the same way my brain does :-) Are you using qmp or the human monitor

Re: [SeaBIOS] [Qemu-devel] [PATCH 1/2] pci: Automatically patch PCI device id in PCI ROM

2010-10-21 Thread Avi Kivity
On 10/21/2010 03:14 PM, Anthony Liguori wrote: On 10/21/2010 05:09 AM, Avi Kivity wrote: On 10/18/2010 08:39 PM, Anthony Liguori wrote: SeaBIOS rejects them when loaded from the rom bar and doesn't reject them when loaded via fw_cfg. What I meant was, rombar=0 in qdev. Sometimes my

[Qemu-devel] [PATCH 0/2] Type-safe ioport callbacks

2010-10-24 Thread Avi Kivity
to the community. Avi Kivity (2): Type-safe ioport callbacks piix4 acpi: convert io BAR to type-safe ioport callbacks hw/acpi_piix4.c | 30 +++-- ioport.c| 64 +++ ioport.h| 16 + 3 files

[Qemu-devel] [PATCH 1/2] Type-safe ioport callbacks

2010-10-24 Thread Avi Kivity
. Signed-off-by: Avi Kivity a...@redhat.com --- ioport.c | 64 ++ ioport.h | 16 +++ 2 files changed, 80 insertions(+), 0 deletions(-) diff --git a/ioport.c b/ioport.c index ec3dc65..47eafc3 100644 --- a/ioport.c +++ b

[Qemu-devel] [PATCH 2/2] piix4 acpi: convert io BAR to type-safe ioport callbacks

2010-10-24 Thread Avi Kivity
Signed-off-by: Avi Kivity a...@redhat.com --- hw/acpi_piix4.c | 30 ++ 1 files changed, 18 insertions(+), 12 deletions(-) diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c index f74f34c..5772667 100644 --- a/hw/acpi_piix4.c +++ b/hw/acpi_piix4.c @@ -52,6 +52,7

[Qemu-devel] Re: [PATCH 1/2] Type-safe ioport callbacks

2010-10-24 Thread Avi Kivity
On 10/24/2010 05:34 PM, Avi Kivity wrote: Currently the old and new methods exist side by side; once the old way is gone, we can also save a bunch of memory since the new method requires one pointer per ioport instead of 6. Actually, 1:7, we replace 3 read callbacks, 3 write callbacks, and 1

[Qemu-devel] Re: [PATCH 0/2] Type-safe ioport callbacks

2010-10-24 Thread Avi Kivity
On 10/24/2010 07:35 PM, Paolo Bonzini wrote: On 10/24/2010 05:34 PM, Avi Kivity wrote: A recent qemu - qemu-kvm merge broke cpu hotplug without the compiler complaining because of the type-unsafeness of the ioport callbacks. This patchset adds a type-safe variant of ioport callbacks

Re: [Qemu-devel] [PATCH 1/2] Type-safe ioport callbacks

2010-10-25 Thread Avi Kivity
On 10/24/2010 08:14 PM, Blue Swirl wrote: On Sun, Oct 24, 2010 at 3:34 PM, Avi Kivitya...@redhat.com wrote: The current ioport callbacks are not type-safe, in that they accept an opaque pointer as an argument whose type must match the argument to the registration function; this is not

[Qemu-devel] Re: [SeaBIOS] [PATCH] mark irq9 active high in DSDT

2010-10-25 Thread Avi Kivity
On 10/23/2010 04:12 PM, Kevin O'Connor wrote: On Thu, Oct 21, 2010 at 12:07:17PM +0200, Avi Kivity wrote: How do we manage the stable series wrt this issue? qemu-kvm-0.12.5 has a regression within the stable series that this patch fixes. qemu 0.12.5 does not, but only because it does

[Qemu-devel] Re: [PATCH 1/2] Type-safe ioport callbacks

2010-10-25 Thread Avi Kivity
On 10/25/2010 02:54 PM, Juan Quintela wrote: Avi Kivitya...@redhat.com wrote: +static void ioport_writeb_thunk(void *opaque, uint32_t addr, uint32_t data) +{ +IOPort *ioport = opaque; + +return ioport-ops-writeb(ioport, addr, data); +} + +static void

[Qemu-devel] [PATCH v2 0/2] Type-safe ioport callbacks

2010-10-25 Thread Avi Kivity
to the community. v2: - const correctness - avoid return void Avi Kivity (2): Type-safe ioport callbacks piix4 acpi: convert io BAR to type-safe ioport callbacks hw/acpi_piix4.c | 30 +++-- ioport.c| 64

  1   2   3   4   5   6   7   8   9   10   >