Hi Badari,
On 12/08/11 06:50, Badari Pulavarty wrote:
On 8/10/2011 8:19 PM, Liu Yuan wrote:
When opening second device, we get panic since used_info_cachep is
already created. Just to make progress I moved this call to
vhost_blk_init().
I don't see any host panics now. With single block device
On 08/11/2011 06:20 PM, Paolo Bonzini wrote:
+qemu_mutex_lock_ramlist();
QLIST_REMOVE(block, next);
QLIST_INSERT_HEAD(&ram_list.blocks, block, next);
+qemu_mutex_unlock_ramlist();
Theoretically qemu_get_ram_ptr should be prote
On 08/11/2011 07:36 PM, Umesh Deshpande wrote:
Now, migrate_fd_cleanup, buffured_close is just executed by the
migration thread.
I am not letting iothread call any migration cancellation related
functions. In stead it just submits the request and waits for the
migration thread to terminate itse
On Fri, Aug 12, 2011 at 1:47 PM, Stefan Hajnoczi wrote:
> On Fri, Aug 12, 2011 at 6:35 AM, Zhi Yong Wu wrote:
>> On Tue, Aug 9, 2011 at 4:57 PM, Ram Pai wrote:
>>> On Tue, Aug 09, 2011 at 12:17:51PM +0800, Zhi Yong Wu wrote:
Note:
1.) When bps/iops limits are specified to a small
On Fri, 2011-08-12 at 08:25 +0300, Pekka Enberg wrote:
> On Thu, 2011-08-11 at 23:41 +0300, Sasha Levin wrote:
> > 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 th
On Fri, Aug 12, 2011 at 6:35 AM, Zhi Yong Wu wrote:
> On Tue, Aug 9, 2011 at 4:57 PM, Ram Pai wrote:
>> On Tue, Aug 09, 2011 at 12:17:51PM +0800, Zhi Yong Wu wrote:
>>> Note:
>>> 1.) When bps/iops limits are specified to a small value such as 511
>>> bytes/s, this VM will hang up. We are c
Am 12.08.2011 um 05:35 schrieb David Gibson :
> On Tue, Aug 09, 2011 at 06:31:45PM +0200, Alexander Graf wrote:
>> When running a PAPR guest, we need to handle a few hypercalls in kernel
>> space,
>> most prominently the page table invalidation (to sync the shadows).
>>
>> So this patch adds ha
Am 12.08.2011 um 05:33 schrieb David Gibson :
> On Tue, Aug 09, 2011 at 06:31:47PM +0200, Alexander Graf wrote:
>> PAPR defines hypercalls as SC1 instructions. Using these, the guest modifies
>> page tables and does other privileged operations that it wouldn't be allowed
>> to do in supervisor mo
On Tue, Aug 9, 2011 at 4:57 PM, Ram Pai wrote:
> On Tue, Aug 09, 2011 at 12:17:51PM +0800, Zhi Yong Wu wrote:
>> Note:
>> 1.) When bps/iops limits are specified to a small value such as 511
>> bytes/s, this VM will hang up. We are considering how to handle this senario.
>> 2.) When "d
On Thu, 2011-08-11 at 23:41 +0300, Sasha Levin wrote:
> 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: Sa
On Fri, Aug 12, 2011 at 1:06 PM, Stefan Hajnoczi wrote:
> On Fri, Aug 12, 2011 at 6:00 AM, Zhi Yong Wu wrote:
>> On Wed, Aug 10, 2011 at 7:00 PM, Stefan Hajnoczi wrote:
>>> On Wed, Aug 10, 2011 at 7:57 AM, Zhi Yong Wu wrote:
On Tue, Aug 9, 2011 at 11:19 PM, Stefan Hajnoczi
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?
>
> Just add the romfile property to your nic with an empty string, i.e.
>
> qemu $otheropts -device e1000,romfile=,mac=...
Thanks, I can use that a sworkaround
On Fri, Aug 12, 2011 at 6:00 AM, Zhi Yong Wu wrote:
> On Wed, Aug 10, 2011 at 7:00 PM, Stefan Hajnoczi wrote:
>> On Wed, Aug 10, 2011 at 7:57 AM, Zhi Yong Wu wrote:
>>> On Tue, Aug 9, 2011 at 11:19 PM, Stefan Hajnoczi wrote:
On Tue, Aug 9, 2011 at 5:17 AM, Zhi Yong Wu
wrote:
> N
On Wed, Aug 10, 2011 at 7:00 PM, Stefan Hajnoczi wrote:
> On Wed, Aug 10, 2011 at 7:57 AM, Zhi Yong Wu wrote:
>> On Tue, Aug 9, 2011 at 11:19 PM, Stefan Hajnoczi wrote:
>>> On Tue, Aug 9, 2011 at 5:17 AM, Zhi Yong Wu
>>> wrote:
Note:
1.) When bps/iops limits are specified to a s
On Fri, Aug 12, 2011 at 5:40 AM, Zhi Yong Wu wrote:
> On Wed, Aug 10, 2011 at 5:37 PM, Stefan Hajnoczi
> wrote:
>> On Wed, Aug 10, 2011 at 01:54:33PM +0800, Zhi Yong Wu wrote:
>>> On Tue, Aug 9, 2011 at 8:49 PM, Stefan Hajnoczi wrote:
>>> > On Tue, Aug 9, 2011 at 5:17 AM, Zhi Yong Wu
>>> > wro
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
On Wed, Aug 10, 2011 at 5:37 PM, Stefan Hajnoczi
wrote:
> On Wed, Aug 10, 2011 at 01:54:33PM +0800, Zhi Yong Wu wrote:
>> On Tue, Aug 9, 2011 at 8:49 PM, Stefan Hajnoczi wrote:
>> > On Tue, Aug 9, 2011 at 5:17 AM, Zhi Yong Wu
>> > wrote:
>> >> +BlockDriverAIOCB *qemu_block_queue_enqueue(BlockQu
On Fri, Aug 12, 2011 at 9:48 AM, Linus Torvalds
wrote:
> 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 referen
On Tue, Aug 09, 2011 at 06:31:45PM +0200, Alexander Graf wrote:
> When running a PAPR guest, we need to handle a few hypercalls in kernel space,
> most prominently the page table invalidation (to sync the shadows).
>
> So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I tried
>
On Tue, Aug 09, 2011 at 06:31:47PM +0200, Alexander Graf wrote:
> PAPR defines hypercalls as SC1 instructions. Using these, the guest modifies
> page tables and does other privileged operations that it wouldn't be allowed
> to do in supervisor mode.
>
> This patch adds support for PR KVM to trap t
Jason Wang writes:
> As multi-queue nics were commonly used for high-end servers,
> current single queue based tap can not satisfy the
> requirement of scaling guest network performance as the
> numbers of vcpus increase. So the following series
> implements multiple queue support in tun/tap.
From: Krishna Kumar
Implement mq virtio-net driver.
Though struct virtio_net_config changes, it works with the old
qemu since the last element is not accessed unless qemu sets
VIRTIO_NET_F_MULTIQUEUE.
Signed-off-by: Krishna Kumar
Signed-off-by: Jason Wang
---
drivers/net/virtio_net.c | 57
From: Krishna Kumar
Move queue_index from virtio_pci_vq_info to virtqueue. This
allows callback handlers to figure out the queue number for
the vq that needs attention.
Signed-off-by: Krishna Kumar
---
drivers/virtio/virtio_pci.c | 10 +++---
include/linux/virtio.h |1 +
2 file
In order to let tap can transmit packets to multiple
sockets, the first step is to move all socket/sock related
structures to tun_file. The reference between tap device and
socket was setup during TUNSETIFF as usual. After this we
can move towards the multi-queue support by allowing
multiple files
As multi-queue nics were commonly used for high-end servers,
current single queue based tap can not satisfy the
requirement of scaling guest network performance as the
numbers of vcpus increase. So the following series
implements multiple queue support in tun/tap.
In order to take advantages of th
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
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
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
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
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
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 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
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
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
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,
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
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
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
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
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
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
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
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 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);
+
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 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
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 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 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 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
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 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
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 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 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, 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
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
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 |
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 ++
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 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
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
> >>
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 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
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 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
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 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, 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
> 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 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
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 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, 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, 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: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:
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, 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
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
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
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
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]
>
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
> 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
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
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
> 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 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
> >
> > 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: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
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, 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.
>
> 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 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
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 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: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 +++
> 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 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
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
1 - 100 of 125 matches
Mail list logo
