On Thu, 2011-08-11 at 13:40 +0800, walimis wrote:
> On Thu, Aug 11, 2011 at 08:37:01AM +0300, Sasha Levin wrote:
> >On Thu, 2011-08-11 at 13:07 +0800, Liming Wang wrote:
> >> If num_pages is negative, balloon will make kernel crash with
> >> "out of memory". So we check this value to avoid it to be
On Thu, 2011-08-11 at 13:07 +0800, Liming Wang wrote:
> If "kvm run" without balloon option, use "kvm balloon" may
> crash kvm. Add signal placeholder to avoid this.
>
> Signed-off-by: Liming Wang
> ---
> tools/kvm/builtin-run.c |7 +++
> 1 files changed, 7 insertions(+), 0 deletions(-)
On Thu, Aug 11, 2011 at 10:29:05AM +0300, Sasha Levin wrote:
>On Thu, 2011-08-11 at 13:07 +0800, Liming Wang wrote:
>> If "kvm run" without balloon option, use "kvm balloon" may
>> crash kvm. Add signal placeholder to avoid this.
>>
>> Signed-off-by: Liming Wang
>> ---
>> tools/kvm/builtin-run.c
If num_pages is negative, balloon will make kernel crash with
"out of memory". So we check this value to avoid it to be negative.
Signed-off-by: Liming Wang
---
tools/kvm/virtio/balloon.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/tools/kvm/virtio/balloon.c b
The memory API supports cracking wide accesses into narrower ones
when needed; but this was no implemented for the pio address space,
causing lsi53c895a's IO BAR to malfunction.
Fix by correctly cracking wide accesses when needed.
Signed-off-by: Avi Kivity
---
memory.c | 11 +--
1 fil
The memory API automatically cracks large reads and writes into smaller
ones when needed. Factor out this mechanism, which is now duplicated between
memory reads and memory writes, into a function.
Signed-off-by: Avi Kivity
---
memory.c | 109 ++-
The memory API automatically cracks wide memory accesses into narrower
(usually byte) accesses when needed. Unfortunately this wasn't implemented
for ioports, leading to an lsi53c895a failure.
This series implements cracking for ioports as well.
Note that the dual implementation is due to the fa
If "kvm run" without balloon option, use "kvm balloon" may
crash kvm. So ignore balloon signals by default to avoid this.
Signed-off-by: Liming Wang
---
tools/kvm/builtin-run.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/tools/kvm/builtin-run.c b/tools/kvm/builtin-
Hello Avi,
Thank for the fast fix. Unfortunatly it still doesn't work (but LSI BIOS
is initialized correctly).
I'm getting at boot time:
qemu-system-x86_64: /qemu-kvm-test/memory.c:1168:
memory_region_del_subregion: Assertion `subregion->parent == mr' failed.
Thnx.
Ciao,
Gerhard
--
http:/
On 08/11/2011 11:25 AM, Gerhard Wiesinger wrote:
Hello Avi,
Thank for the fast fix. Unfortunatly it still doesn't work (but LSI
BIOS is initialized correctly).
I'm getting at boot time:
qemu-system-x86_64: /qemu-kvm-test/memory.c:1168:
memory_region_del_subregion: Assertion `subregion->paren
On 08/11/2011 11:27 AM, Avi Kivity wrote:
On 08/11/2011 11:25 AM, Gerhard Wiesinger wrote:
Hello Avi,
Thank for the fast fix. Unfortunatly it still doesn't work (but LSI
BIOS is initialized correctly).
I'm getting at boot time:
qemu-system-x86_64: /qemu-kvm-test/memory.c:1168:
memory_region
On 08/10/2011 03:27 PM, Nadav Har'El wrote:
On Wed, Aug 10, 2011, Thomas Mittelstaedt wrote about "Re: [ANNOUNCE]
qemu-kvm-0.15.0":
> Grabbed the version, created a disk image of 5G and tried to load and
> iso via
> /usr/local/bin/qemu -hda ~/virtualdisk.img -cdrom
> ~/Downloads/oneiric-des
On 08/10/2011 02:56 AM, Asias He wrote:
This patch fixes strange characters in serial console.
Before:
[0.448000] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
�[0.695000] serial8250: ttyS0 at I/O 0x3f8 (irq = 0) is a 16550A
�[0.942000] serial8250: ttyS1 at I/O 0x2f8 (irq
On Wed, 2011-08-10 at 19:45 +0300, Pekka Enberg wrote:
> > On 08/10/2011 09:34 PM, Pekka Enberg wrote:
> >> On Wed, 10 Aug 2011, Sasha Levin wrote:
> >>> This patch changes the serial device to print only auxiliary output to
> >>> the
> >>> terminal.
> >>>
> >>> Doing so prevents printing output wh
Hi, Avi:
Your guess is right, the fast server is AMD with NPT. this slow
server is Intel's 7430 with no EPT, I now understand the reserved bit
come from kvm's virtual soft-mmu.
But there is still one confusing problem: why a FC14 VM has a much
better storage IO performance on the same ho
If I use '-boot order=cd' the VM still tries to boot from network. Is that
expected? If so, how can I disable network boot?
- Dietmar
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel
Hello Avi,
#0 0x003a060328f5 in raise () from /lib64/libc.so.6
#1 0x003a060340d5 in abort () from /lib64/libc.so.6
#2 0x003a0602b8b5 in __assert_fail () from /lib64/libc.so.6
#3 0x00435339 in memory_region_del_subregion (mr=,
subregion=)at
/root/download/qemu/git/qem
This patch makes BAR 1 16k, instead of BAR0 - which is the PIO bar.
This fixes wrong output on lspci command and ioremap warnings during boot.
Reported-by: David Evensky
Signed-off-by: Sasha Levin
---
tools/kvm/hw/serial.c |2 +-
tools/kvm/hw/vesa.c |2 +-
tools/kvm/pci.c |
On Thu, Aug 11, 2011 at 08:55:37AM +, Dietmar Maurer wrote:
> If I use '-boot order=cd' the VM still tries to boot from network. Is that
> expected? If so, how can I disable network boot?
>
Does it tries it only when c & d are not bootable or always?
--
Gleb.
--
To un
> Does it tries it only when c & d are not bootable or always?
Only if c &d are not bootable.
- Dietmar
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
This thread fixes two issues:
- Slave IRQCHIP was mapped wrong, this caused all IRQs which belong
to it to be ignored (breaking such things as the mouse).
- Line 2 was being mapped, since it's the link between slave and master
IRQCHIPs it shouldn't be.
Signed-off-by: Sasha Levin
---
tools/kvm/
On 8/11/11 12:04 PM, Sasha Levin wrote:
This thread fixes two issues:
- Slave IRQCHIP was mapped wrong, this caused all IRQs which belong
to it to be ignored (breaking such things as the mouse).
- Line 2 was being mapped, since it's the link between slave and master
IRQCHIPs it shouldn't be.
On Thu, Aug 11, 2011 at 09:12:42AM +, Dietmar Maurer wrote:
> > Does it tries it only when c & d are not bootable or always?
>
> Only if c &d are not bootable.
>
Then it is expected (as in "this is how code works currently"). Why
would you want to disable network boot if other method failed?
On 08/11/2011 12:01 PM, Gerhard Wiesinger wrote:
Hello Avi,
#0 0x003a060328f5 in raise () from /lib64/libc.so.6
#1 0x003a060340d5 in abort () from /lib64/libc.so.6
#2 0x003a0602b8b5 in __assert_fail () from /lib64/libc.so.6
#3 0x00435339 in memory_region_del_subregion (mr
The device uses the virtio preferred method of working with MSI-X by
creating one vector for configuration and one vector for each vq in the
device.
Signed-off-by: Sasha Levin
---
tools/kvm/virtio/net.c | 56 ---
1 files changed, 52 insertions(+), 4
This patch changes kvm_cpu__reboot() behaviour to block until all VCPU
threads have ended, this allows us to assume that the guest is stopped
when the function has returned.
This fixes errors on close caused by releasing KVM_RUN structure while
VCPUs were still running.
Signed-off-by: Sasha Levin
On 08/11/2011 11:59 AM, ya su wrote:
Hi, Avi:
Your guess is right, the fast server is AMD with NPT. this slow
server is Intel's 7430 with no EPT, I now understand the reserved bit
come from kvm's virtual soft-mmu.
But there is still one confusing problem: why a FC14 VM has a much
bet
> Then it is expected (as in "this is how code works currently"). Why would you
> want to disable network boot if other method failed?
Because I do not want to start/install a new VM only because I have some other
error. Also, I think the behavior was different with earlier versions.
For example
On Thu, Aug 11, 2011 at 12:47 PM, Sasha Levin wrote:
> The device uses the virtio preferred method of working with MSI-X by
> creating one vector for configuration and one vector for each vq in the
> device.
>
> Signed-off-by: Sasha Levin
> ---
> tools/kvm/virtio/net.c | 56 +++
On Thu, Aug 11, 2011 at 12:47 PM, Sasha Levin wrote:
> This patch changes kvm_cpu__reboot() behaviour to block until all VCPU
> threads have ended, this allows us to assume that the guest is stopped
> when the function has returned.
>
> This fixes errors on close caused by releasing KVM_RUN struct
On Thu, Aug 11, 2011 at 12:04:08PM +0300, Sasha Levin wrote:
>This patch makes BAR 1 16k, instead of BAR0 - which is the PIO bar.
>
>This fixes wrong output on lspci command and ioremap warnings during boot.
>
>Reported-by: David Evensky
>Signed-off-by: Sasha Levin
>---
> tools/kvm/hw/serial.c |
On 08/08/2011 08:17 AM, Satz Klauer wrote:
Hi,
currently I fail with a problem that I already had (and never could
solve) with QNX 6.4.1, now I tried again with QNX 6.5 but still don't
get it working. I start qemu with
qemu-system-x86_64 -hda qnx.img -m 512 -net nic -net user
(brain-attritiona
> Then it is expected (as in "this is how code works currently"). Why would you
> want to disable network boot if other method failed?
If I start kvm with:
# kvm -boot order=cad
The it tries to boot: cdrom, net, disk, floppy (dnca)
So the boot order is completely wrong!
But the order is corre
On Thu, 2011-08-11 at 13:02 +0300, Pekka Enberg wrote:
> On Thu, Aug 11, 2011 at 12:47 PM, Sasha Levin wrote:
> > This patch changes kvm_cpu__reboot() behaviour to block until all VCPU
> > threads have ended, this allows us to assume that the guest is stopped
> > when the function has returned.
>
On Thu, Aug 11, 2011 at 09:56:37AM +, Dietmar Maurer wrote:
> > Then it is expected (as in "this is how code works currently"). Why would
> > you
> > want to disable network boot if other method failed?
>
> Because I do not want to start/install a new VM only because I have some
> other erro
On Thu, Aug 11, 2011 at 10:13:15AM +, Dietmar Maurer wrote:
> > Then it is expected (as in "this is how code works currently"). Why would
> > you
> > want to disable network boot if other method failed?
>
> If I start kvm with:
>
> # kvm -boot order=cad
>
> The it tries to boot: cdrom, net
> > Also, I think the behavior was different with earlier versions.
> Yes, it was. The behaviour changed when bootindex was introduced. I think it
> should be easy to switch it back to what it was for -boot option, but -boot
> is/should be deprecated in favor of bootindex anyway.
> Implementing opt
On Thu, Aug 11, 2011 at 10:33:47AM +, Dietmar Maurer wrote:
> > > Also, I think the behavior was different with earlier versions.
> > Yes, it was. The behaviour changed when bootindex was introduced. I think it
> > should be easy to switch it back to what it was for -boot option, but -boot
> >
> We can change BIOS to only boot from devices that has bootindex, but then you
> will have to always specify it for all/most devices, or we can add noboot
> device
> property, but that will require changes on qemu side too.
I guess 'noboot' is the way to go. We already have that for disks.
- Di
On Thu, Aug 11, 2011 at 11:29:29AM +, Dietmar Maurer wrote:
> > We can change BIOS to only boot from devices that has bootindex, but then
> > you
> > will have to always specify it for all/most devices, or we can add noboot
> > device
> > property, but that will require changes on qemu side t
On Thu, 2011-08-11 at 17:49 +0800, walimis wrote:
> On Thu, Aug 11, 2011 at 12:04:08PM +0300, Sasha Levin wrote:
> >This patch makes BAR 1 16k, instead of BAR0 - which is the PIO bar.
> >
> >This fixes wrong output on lspci command and ioremap warnings during boot.
> >
> >Reported-by: David Evensky
> Agree. noboot sounds optimal, but also requires more codding that other
> options (sigh, isn't it always this way?). But how do we have it for disks?
-drive [file=file][,if=type][,bus=n][,unit=m][,media=d][,index=i]
[,cyls=c,heads=h,secs=s[,trans=t]][,snapshot=on|off]
[,cache=write
This patch makes BAR 1 16k, instead of BAR0 - which is the PIO bar.
This fixes wrong output on lspci command and ioremap warnings during boot.
Signed-off-by: Sasha Levin
---
tools/kvm/hw/vesa.c |2 +-
tools/kvm/pci.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --gi
On Thu, Aug 11, 2011 at 11:57:28AM +, Dietmar Maurer wrote:
> > Agree. noboot sounds optimal, but also requires more codding that other
> > options (sigh, isn't it always this way?). But how do we have it for disks?
>
> -drive [file=file][,if=type][,bus=n][,unit=m][,media=d][,index=i]
>
Instead of exiting directly when a user enters 'ctrl x + a', go through
the regular termination path by stopping all VCPUs and letting the
main thread handle it.
Signed-off-by: Sasha Levin
---
tools/kvm/builtin-run.c |9 +
tools/kvm/kvm-cpu.c |8 ++--
tools/kvm/term.c
Add a helper function to trigger an IRQ.
This function is usefull when an IRQ line has to be raised and lowered
such as when using MSI-X.
Signed-off-by: Sasha Levin
---
tools/kvm/include/kvm/kvm.h |1 +
tools/kvm/kvm.c |6 ++
2 files changed, 7 insertions(+), 0 deletions
The device uses the virtio preferred method of working with MSI-X by
creating one vector for configuration and one vector for each vq in the
device.
Signed-off-by: Sasha Levin
---
tools/kvm/virtio/net.c | 54 +++
1 files changed, 49 insertions(+), 5
On Thu, 11 Aug 2011, Liming Wang wrote:
If num_pages is negative, balloon will make kernel crash with
"out of memory". So we check this value to avoid it to be negative.
Signed-off-by: Liming Wang
---
tools/kvm/virtio/balloon.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
d
On Thu, 11 Aug 2011, Sasha Levin wrote:
Instead of exiting directly when a user enters 'ctrl x + a', go through
the regular termination path by stopping all VCPUs and letting the
main thread handle it.
Signed-off-by: Sasha Levin
---
tools/kvm/builtin-run.c |9 +
tools/kvm/kvm-cpu.c
On Thu, 2011-08-11 at 16:39 +0300, Pekka Enberg wrote:
> On Thu, 11 Aug 2011, Sasha Levin wrote:
> > Instead of exiting directly when a user enters 'ctrl x + a', go through
> > the regular termination path by stopping all VCPUs and letting the
> > main thread handle it.
> >
> > Signed-off-by: Sasha
On Thu, 11 Aug 2011, Sasha Levin wrote:
This is a nice cleanup but I'm not happy about the fact that you also nuke
the above printf(). Is there a simple way to keep it there?
You get that printf from the normal exit path.
You get a different printf:
$ grep -r "KVM session" *.c
builtin-run.c
On Thu, 2011-08-11 at 16:47 +0300, Pekka Enberg wrote:
> On Thu, 11 Aug 2011, Sasha Levin wrote:
> >> This is a nice cleanup but I'm not happy about the fact that you also nuke
> >> the above printf(). Is there a simple way to keep it there?
> >>
> >
> > You get that printf from the normal exit pat
On Thu, Aug 11, 2011 at 03:43:54PM +0300, Sasha Levin wrote:
>Instead of exiting directly when a user enters 'ctrl x + a', go through
>the regular termination path by stopping all VCPUs and letting the
>main thread handle it.
>
>Signed-off-by: Sasha Levin
>---
> tools/kvm/builtin-run.c |9
On Thu, Aug 11, 2011 at 04:36:29PM +0300, Pekka Enberg wrote:
>On Thu, 11 Aug 2011, Liming Wang wrote:
>>If num_pages is negative, balloon will make kernel crash with
>>"out of memory". So we check this value to avoid it to be negative.
>>
>>Signed-off-by: Liming Wang
>>---
>>tools/kvm/virtio/ball
On 08/11/2011 05:17 PM, Pekka Enberg wrote:
> On 8/11/11 12:04 PM, Sasha Levin wrote:
>> This thread fixes two issues:
>> - Slave IRQCHIP was mapped wrong, this caused all IRQs which belong
>> to it to be ignored (breaking such things as the mouse).
>> - Line 2 was being mapped, since it's the
> No, this boot= option is deprecated too. AFAIK boot=off does (and always
> did) nothing. boot=on tells qemu to boot from the disk using extboot option
> rom. This was needed to boot from virtio disks. Now SeaBIOS can boot from
> virtio disk natively, so extboot no longer needed. But due to the w
On Thu, Aug 11, 2011 at 09:54:26PM +0800, Asias He wrote:
>On 08/11/2011 05:17 PM, Pekka Enberg wrote:
>> On 8/11/11 12:04 PM, Sasha Levin wrote:
>>> This thread fixes two issues:
>>> - Slave IRQCHIP was mapped wrong, this caused all IRQs which belong
>>> to it to be ignored (breaking such things
On Thu, Aug 11, 2011 at 01:57:04PM +, Dietmar Maurer wrote:
> > No, this boot= option is deprecated too. AFAIK boot=off does (and always
> > did) nothing. boot=on tells qemu to boot from the disk using extboot option
> > rom. This was needed to boot from virtio disks. Now SeaBIOS can boot from
On Thu, 11 Aug 2011, Sasha Levin wrote:
You get a different printf:
$ grep -r "KVM session" *.c
builtin-run.c: printf("\n # KVM session ended normally.\n");
term.c: printf("\n # KVM session terminated.\n");
It's nice to see that the user terminated the session without
On Mon, Aug 08, 2011 at 07:17:47AM +0200, Satz Klauer wrote:
> Hi,
>
> currently I fail with a problem that I already had (and never could
> solve) with QNX 6.4.1, now I tried again with QNX 6.5 but still don't
> get it working. I start qemu with
>
> qemu-system-x86_64 -hda qnx.img -m 512 -net ni
Hello,
I have encountered a problem with the bootindex parameter for a KVM
guest that has two virtio-blk disks.
host CPU: AMD Phenom II X4 955 Processor
host OS (first): x86_64 debian-squeeze (kernel 2.6.38 amd64)
host OS (later): x86_64 debian-squeeze (kernel 3.0 amd64)
guest OS (both disks): e.
On Thu, 2011-08-11 at 16:42 +0300, Pekka Enberg wrote:
> On Thu, 11 Aug 2011, Sasha Levin wrote:
> >> No I didn't but that's not really a solution to the problem. We can't
> >> expect people to configure guest userspace for something as basic as
> >> console.
> >
> > I tested it again with /bin/sh
On Thu, Aug 11, 2011 at 06:19:54PM +0300, Sasha Levin wrote:
>On Thu, 2011-08-11 at 16:42 +0300, Pekka Enberg wrote:
>> On Thu, 11 Aug 2011, Sasha Levin wrote:
>> >> No I didn't but that's not really a solution to the problem. We can't
>> >> expect people to configure guest userspace for something
On Thu, 2011-08-11 at 23:14 +0800, walimis wrote:
> On Thu, Aug 11, 2011 at 06:19:54PM +0300, Sasha Levin wrote:
> >On Thu, 2011-08-11 at 16:42 +0300, Pekka Enberg wrote:
> >> On Thu, 11 Aug 2011, Sasha Levin wrote:
> >> >> No I didn't but that's not really a solution to the problem. We can't
> >>
Following patch series deals with VCPU and iothread starvation during the
migration of
a guest. Currently the iothread is responsible for performing the guest
migration. It holds qemu_mutex during the migration and doesn't allow VCPU to
enter the qemu mode and delays its return to the guest. The gu
This patch creates a separate thread for the guest migration on the source side.
migrate_cancel request from the iothread is handled asynchronously. That is,
iothread submits migrate_cancel to the migration thread and returns, while the
migration thread attends this request at the next iteration to
Following patch introduces a mutex to protect the migration thread against the
removal of memslots during the guest migration iteration.
Signed-off-by: Umesh Deshpande
---
arch_init.c | 10 ++
buffered_file.c |4
cpu-all.h |2 ++
cpus.c | 12 ++
Following patch makes iothread wait until the migration thread responds to the
migrate_cancel request and terminates its execution.
Signed-off-by: Umesh Deshpande
---
buffered_file.c | 13 -
hw/hw.h |5 -
migration.c |1 +
qemu-thread-posix.c |
This patch creates a migration bitmap, which is periodically kept in sync with
the qemu bitmap. A separate copy of the dirty bitmap for the migration avoids
concurrent access to the qemu bitmap from iothread and migration thread.
Signed-off-by: Umesh Deshpande
---
arch_init.c | 16
On Thu, 11 Aug 2011, Sasha Levin wrote:
I've tested it with rootfs as well.
I'm not sure what else can be the difference.
Pekka, Whats your exact kernel version?
Latest and greatest, of course!
$ uname -a
Linux tiger 3.1.0-rc1+ #9 SMP PREEMPT Tue Aug 9 21:25:52 EEST 2011 x86_64
GNU/Linux
On Thu, 11 Aug 2011, Avi Kivity wrote:
On 08/11/2011 12:01 PM, Gerhard Wiesinger wrote:
Hello Avi,
#0 0x003a060328f5 in raise () from /lib64/libc.so.6
#1 0x003a060340d5 in abort () from /lib64/libc.so.6
#2 0x003a0602b8b5 in __assert_fail () from /lib64/libc.so.6
#3 0x00
On Thu, 11 Aug 2011, Avi Kivity wrote:
This should be faster today with really new kernels (the problem is not in
qemu) but I'm not sure if it's fast enough.
What's a "really new" kernel? In which version were performance
optimizations done? (Currently I'm using 2.6.34.7, hadn't time yet to
u
On 08/11/2011 07:11 PM, Gerhard Wiesinger wrote:
On Thu, 11 Aug 2011, Avi Kivity wrote:
This should be faster today with really new kernels (the problem is
not in qemu) but I'm not sure if it's fast enough.
What's a "really new" kernel? In which version were performance
optimizations done? (C
On 08/11/2011 05:32 PM, Umesh Deshpande wrote:
This patch creates a separate thread for the guest migration on the source side.
migrate_cancel request from the iothread is handled asynchronously. That is,
iothread submits migrate_cancel to the migration thread and returns, while the
migration thr
diff --git a/buffered_file.c b/buffered_file.c
index b64ada7..5735e18 100644
--- a/buffered_file.c
+++ b/buffered_file.c
@@ -243,7 +243,9 @@ static void *migrate_vm(void *opaque)
while (!s->closed) {
if (s->freeze_output) {
+qemu_mutex_unlock_iothread();
On 8 August 2011 18:07, Avi Kivity wrote:
> -static uint32_t pci_vpb_config_readb (void *opaque, target_phys_addr_t addr)
> +static uint64_t pci_vpb_config_read(void *opaque, target_phys_addr_t addr,
> + unsigned size)
> {
> uint32_t val;
> - val = pci_da
On 08/11/2011 07:08 PM, Gerhard Wiesinger wrote:
(gdb) frame 4
#4 0x0041eb9b in pci_update_mappings (d=0x1a90bc0)
at /root/download/qemu/git/qemu-kvm-test/hw/pci.c:1134
1134memory_region_del_subregion(r->address_space,
r->memory);
(gdb) print i
$1 =
(gdb) print *r
On 08/11/2011 07:20 PM, Avi Kivity wrote:
On 08/11/2011 07:08 PM, Gerhard Wiesinger wrote:
(gdb) frame 4
#4 0x0041eb9b in pci_update_mappings (d=0x1a90bc0)
at /root/download/qemu/git/qemu-kvm-test/hw/pci.c:1134
1134memory_region_del_subregion(r->address_space,
r->m
On 08/11/2011 05:32 PM, Umesh Deshpande wrote:
Following patch series deals with VCPU and iothread starvation during the
migration of
a guest. Currently the iothread is responsible for performing the guest
migration. It holds qemu_mutex during the migration and doesn't allow VCPU to
enter the qem
On August 11, 2011, Avi Kivity wrote:
> On 08/09/2011 06:33 PM, Nick wrote:
> > Hi,
> >
> > Just joined this list, looking for leads to solve a similar-sounding
> > problem (guest processes hanging for seconds or minutes when host IO
> > load is high). I'll say more in a separate email, but I caug
Hello everyone,
so basically this is a tradeoff between not having a long latency for
the migration to succeed and reducing the total network traffic (and
CPU load) in the migration source and destination and reducing the
memory footprint a bit, by adding an initial latency to the memory
accesses
On 08/11/2011 12:18 PM, Paolo Bonzini wrote:
@@ -175,20 +170,20 @@ static int buffered_close(void *opaque)
while (!s->has_error&& s->buffer_size) {
buffered_flush(s);
-if (s->freeze_output)
+if (s->freeze_output) {
s->wait_for_unfreeze(s);
+
Am Donnerstag, den 11.08.2011, 11:33 +0300 schrieb Avi Kivity:
> On 08/10/2011 03:27 PM, Nadav Har'El wrote:
> > On Wed, Aug 10, 2011, Thomas Mittelstaedt wrote about "Re: [ANNOUNCE]
> > qemu-kvm-0.15.0":
> > > Grabbed the version, created a disk image of 5G and tried to load and
> > > iso via
>
On 08/11/2011 07:20 PM, Peter Maydell wrote:
On 8 August 2011 18:07, Avi Kivity wrote:
> -static uint32_t pci_vpb_config_readb (void *opaque, target_phys_addr_t addr)
> +static uint64_t pci_vpb_config_read(void *opaque, target_phys_addr_t addr,
> +unsigned
Signed-off-by: Avi Kivity
---
v1.1: fix bogus 'return size', thanks to Peter Maydell
hw/versatile_pci.c | 92 ---
1 files changed, 43 insertions(+), 49 deletions(-)
diff --git a/hw/versatile_pci.c b/hw/versatile_pci.c
index e1d5c0b..98e56f1 100
Hi,
Another possibility to disable network boot would be to avoid loading
the pxe-XXX.rom network boot ROMs. Or is that a bad idea?
Just add the romfile property to your nic with an empty string, i.e.
qemu $otheropts -device e1000,romfile=,mac=...
HTH,
Gerd
--
To unsubscribe from this l
On 08/11/2011 10:32 AM, Umesh Deshpande wrote:
Following patch series deals with VCPU and iothread starvation during the
migration of
a guest. Currently the iothread is responsible for performing the guest
migration. It holds qemu_mutex during the migration and doesn't allow VCPU to
enter the qem
On Thu, 11 Aug 2011, Avi Kivity wrote:
Or maybe it's just -O2 screwing up debug information. Please change
./configure to set -O1 and redo.
Please print *r.memory as well.
./configure --target-list=x86_64-softmmu,i386-softmmu --enable-debug
Rest below.
Ciao,
Gerhard
--
http://www.wiesinger
Hi,
On 07/28/2011 05:22 PM, Michael S. Tsirkin wrote:
On Thu, Jul 28, 2011 at 10:29:05PM +0800, Liu Yuan wrote:
+static struct miscdevice vhost_blk_misc = {
+ 234,
Don't get a major unless you really must.
the minor number 234 conflicts with that of BTRFS, in kernel 3.0 at least.
Ther
This patch speeds up PS/2 mouse detection by switching to the
fastest probing method compatible with kvm tools i8042 emulation.
The result is detection taking < 0.5 sec instead of >5 sec.
Tested-by: Asias He
Signed-off-by: Sasha Levin
---
tools/kvm/builtin-run.c |2 +-
1 files changed, 1 i
This patch fixes the read action of virtio-net config by not
handling reads to the start of the space as MSI related
operations.
This fixes the MAC configuration of the device and makes uip network
work again.
Signed-off-by: Sasha Levin
---
tools/kvm/virtio/net.c |6 --
1 files changed,
11.08.2011 17:59, Gleb Natapov wrote:
> On Thu, Aug 11, 2011 at 01:57:04PM +, Dietmar Maurer wrote:
[]
>> Another possibility to disable network boot would be to avoid loading
>> the pxe-XXX.rom network boot ROMs. Or is that a bad idea?
>>
> Ah yeah. Don't see anything bad if you do not what t
On 11 August 2011 17:29, Avi Kivity wrote:
> -static uint32_t pci_vpb_config_readl (void *opaque, target_phys_addr_t addr)
> +static uint64_t pci_vpb_config_read(void *opaque, target_phys_addr_t addr,
> + unsigned size)
> {
> uint32_t val;
> - val = pci_d
On 8/10/2011 8:19 PM, Liu Yuan wrote:
On 08/11/2011 11:01 AM, Liu Yuan wrote:
It looks like the patch wouldn't work for testing multiple devices.
vhost_blk_open() does
+ used_info_cachep = KMEM_CACHE(used_info, SLAB_HWCACHE_ALIGN |
SLAB_PANIC);
This is weird. how do you open multiple
Sasha,
I've done a pull to get patch below and otherwise sync up and got an
ioremap error. It is a little different from the patch I got from you
previously that worked. The patch that worked changed pci.c as:
- u8 bar = offset - PCI_BAR_OFFSET(0);
+ u
On Wed, Aug 10, 2011 at 11:40 PM, David Gibson
wrote:
>
> This patch, therefore, stores a pointer to the inode instead of the
> address_space in the page private data for hugepages. More
> importantly it correctly adjusts the reference count on the inodes
> when they're added to the page private
As we've moved socket related structure to
file->private_data, we can separate system calls that only
touch tfile from others as they don't need hold rtnl lock.
Signed-off-by: Jason Wang
---
drivers/net/tun.c | 52 ++--
1 files changed, 34 insert
Signed-off-by: Jason Wang
---
include/linux/if_tun.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/linux/if_tun.h b/include/linux/if_tun.h
index 06b1829..c92a291 100644
--- a/include/linux/if_tun.h
+++ b/include/linux/if_tun.h
@@ -34,6 +34,7 @@
#define TUN_ONE
With the abstraction that each socket were a backend of a
queue for userspace, this patch adds multiqueue support for
tap device by allowing multiple sockets to be attached to a
tap device. Then we could parallize the transmission by put
them into different socket.
As queue related information wer
This patch adds userspace interface for multi-queue based
tap device. Two new ioctls were added. The first is
TUNATTACHQUEUE which is used to attach an opened file
descriptor to an existed tap device. Another is
TUNDETACHQUEUE which is used to detach an file from an
existed tap device, and this fil
1 - 100 of 125 matches
Mail list logo
