Re: [Qemu-devel] [RFC] Bug Day - June 1st, 2010
On Tue, May 18, 2010 at 05:38:27PM -0500, Anthony Liguori wrote: > Hi, > > In an effort to improve the 0.13 release quality, I'd like to host a > Bug Day on June 1st, 2010. I've setup a quick wiki page with some > more info (http://wiki.qemu.org/BugDay/June2010). > > Here's my basic thinking: > > - Anyone who can should try to spend some time either triaging > bugs, updating bug status, or actually fixing bugs. > - We'll have a special IRC channel (#qemu-bugday) on OFTC. As many > QEMU and KVM developers as possible should join this channel for > that day to help assist people working on bugs. > - We'll try to migrate as many confirmable bugs from the Source > Forge tracker to Launchpad. > > If this is successful, we'll try to have regular bug days. Any > suggestions on how to make the experience as fun and productive as > possible are certainly appreciated! The idea is nice, but would it be possible to hold this on a week-end, I personally won't be able to attend such thing on a day week. Or maybe holding that on two days: friday and saturday so that people can participate at least one of the two days, depending if they do that from work or from home. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- 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
Re: virtio: imply disable_cb on callbacks
On Tue, 18 May 2010 09:03:17 pm Michael S. Tsirkin wrote: > Rusty, the patch "virtio: imply disable_cb on callbacks" is on your tree. > I'd like to figure out how it works: for example: > > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c > --- a/drivers/block/virtio_blk.c > +++ b/drivers/block/virtio_blk.c > @@ -69,6 +69,8 @@ static void blk_done(struct virtqueue *v > /* In case queue is stopped waiting for more buffers. */ > blk_start_queue(vblk->disk->queue); > spin_unlock_irqrestore(&vblk->lock, flags); > + > + vq->vq_ops->enable_cb(vq); > } > > static bool do_req(struct request_queue *q, struct virtio_blk *vblk, > > > Since this does not check the return status from enable_cb, > it seems we could loose an interrupt if it arrives > between poll and callback enable? It's been quite a while since I wrote this patch, and never really liked it enough to polish it. We would need to enable this *before* reading the queue, AFAICT. I'll remove it from my series; it's in the wilderness area already :) Thanks! Rusty. -- 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
Resource accounting questions.
Hi guys, i have installed kvm on four Ubuntu Server 9.04. My question is: How i can make a resource accounting of CPU, RAM, I/O on the host for each guest (something like acct but only for the guest proccess for disk space issues)? Do you have some suggestions? Thanx in advance and regards :) -- Luis Antonio Galindo Castro aka FunkyM0nk3y Fingerprint: 237E EFE1 6055 BCEB ACD0 7A49 30FC A883 0044 A85E -- 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
Biweekly KVM Test report, kernel f1bf31e... qemu 1c596c5...
Hi, all, This is KVM biweekly test result against kvm.git: f1bf31ef946581de4dbc44b3d5e4e39200a0ef62 and qemu-kvm.git: 1c596c54fd5cdce8d65f5a0c3f800567857e6a58, based on kernel 2.6.34-rc6. There are no new issue found in the past two weeks. The 32pae Windows guest will cost about 9 minute to boot up. Six Old Issues: 1. 32PAE Windows guest is slow to boot with acpi on shadow https://sourceforge.net/tracker/?func=detail&aid=2976863&group_id=180599&atid=893831 2. Hot-added device is not visible in guest after migration https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2832416&group_id=180599 3. ltp diotest running time is 2.54 times than before https://sourceforge.net/tracker/?func=detail&aid=2723366&group_id=180599&atid=893831 4. 32bits Rhel5/FC6 guest may fail to reboot after installation https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1991647&group_id=180599 5. perfctr wrmsr warning when booting 64bit RHEl5.3 https://sourceforge.net/tracker/?func=detail&aid=2721640&group_id=180599&atid=893831 6. [SR] qemu return form "migrate " command spend long time https://sourceforge.net/tracker/?func=detail&aid=2942079&group_id=180599&atid=893831 Test environment Platform A Stoakley/Clovertown CPU 4 Memory size 8G Summary Test Report of Last Session = Total PassFailNoResult Crash = control_panel 17 16 1 00 gtest 23 21 2 00 = control_panel 17 16 1 00 :KVM_4G_guest_64_g32e 1 1 0 00 :KVM_four_sguest_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_g32e1 1 0 00 :KVM_linux_win_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_gPAE1 1 0 00 :KVM_SR_Continuity_64_gP 1 1 0 00 :KVM_four_sguest_64_g32e 1 1 0 00 :KVM_four_dguest_64_gPAE 1 1 0 00 :KVM_SR_SMP_64_gPAE1 1 0 00 :KVM_LM_Continuity_64_g3 1 1 0 00 :KVM_1500M_guest_64_gPAE 1 1 0 00 :KVM_LM_Continuity_64_gP 1 0 1 00 :KVM_1500M_guest_64_g32e 1 1 0 00 :KVM_SR_Continuity_64_g3 1 1 0 00 :KVM_two_winxp_64_gPAE 1 1 0 00 :KVM_256M_guest_64_gPAE1 1 0 00 :KVM_256M_guest_64_g32e1 1 0 00 gtest 23 21 2 00 :boot_up_acpi_64_gPAE 1 1 0 00 :boot_up_noacpi_xp_64_gP 1 1 0 00 :boot_base_kernel_64_gPA 1 1 0 00 :boot_up_vista_64_g32e 1 1 0 00 :boot_smp_acpi_win2k3_64 1 0 1 00 :kb_nightly_64_gPAE1 1 0 00 :boot_up_acpi_xp_64_g32e 1 1 0 00 :boot_smp_win7_ent_64_g3 1 1 0 00 :boot_smp_acpi_xp_64_gPA 1 0 1 00 :boot_smp_acpi_xp_64_g32 1 1 0 00 :boot_smp_vista_64_gPAE1 1 0 00 :boot_up_acpi_64_g32e 1 1 0 00 :boot_base_kernel_64_g32 1 1 0 00 :kb_nightly_64_g32e1 1 0 00 :boot_up_acpi_win2k3_64_ 1 1 0 00 :boot_up_win2008_64_gPAE 1 1 0 00 :ltp_nightly_64_g32e 1 1 0 00 :boot_smp_win2008_64_g32 1 1 0 00 :boot_up_vista_64_gPAE 1 1 0 00 :ltp_nightly_64_gPAE 1 1 0 00 :boot_smp_acpi_win2k3_64 1 1 0 00 :boot_up_noacpi_win2k3_6 1 1 0 00 :boot_smp_win7_ent_64_gP 1 1 0 00 = Total 40 37 3 00 Test environment Platform B Nehalem CPU 8 Memory size 4G Report summary of IA32E on vt-NHM1: Summary Test Report of Last Session
[ kvm-Bugs-2976863 ] 32PAE Windows guest is slow to boot with acpi on shadow
Bugs item #2976863, was opened at 2010-03-26 14:44 Message generated for change (Comment added) made by haoxudong You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2976863&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Xudong Hao (haoxudong) Assigned to: Nobody/Anonymous (nobody) >Summary: 32PAE Windows guest is slow to boot with acpi on shadow Initial Comment: Environment: Host OS (ia32/ia32e/IA64):32e and pae Guest OS (ia32/ia32e/IA64): ia32pae Guest OS Type (Linux/Windows): windows(xp, vista, and Win7) kvm.git Commit: b8ed93d4.. qemu-kvm Commit: aa4df134.. Host Kernel Version:2.6.34-rc2 Hardware: Stoakely Bug detailed description: -- when we boot a 32pae Windows guest with acpi on, the guest will become bule screen of death. Reproduce steps: 1. boot into host, loal kvm and kvm_intel module 2. use following command to boot a guest: qemu-system-x86_64 -m 256 -net nic,macaddr=00:16:3e:27:b6:8a,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /share/xvs/var/Windows.img 3. the guest will become bule screen of death. -- >Comment By: Xudong Hao (haoxudong) Date: 2010-05-19 11:23 Message: Change bug title discription since bug behave changed. -- Comment By: Xudong Hao (haoxudong) Date: 2010-05-18 11:11 Message: >This problem you are experiencing is only reproducible on 32-bit host, >64-bit host is OK, correct? No, on 64-bit host, 32pae guest get this booting slow problem with acpi on and shandow mode too. Mtosatti, What platform(CPU) do you use? -- Comment By: Marcelo Tosatti (mtosatti) Date: 2010-04-22 00:51 Message: > Now BSOD issue got out on kvm commit: > bc8a97a218d0d2367d125db3e11ec45bb0fa0a3f-a1b705841caa33fca0b95928505c01d5105b706f. Please save the BSOD message. > However, boot a 32-bit XP with acpi on will cost about 9 minutes, did you > meet similar issue on your side? No. It boots similarly fast as with 64-bit host. This problem you are experiencing is only reproducible on 32-bit host, 64-bit host is OK, correct? -- Comment By: Xudong Hao (haoxudong) Date: 2010-04-20 10:35 Message: Now BSOD issue got out on kvm commit: bc8a97a218d0d2367d125db3e11ec45bb0fa0a3f-a1b705841caa33fca0b95928505c01d5105b706f. However, boot a 32-bit XP with acpi on will cost about 9 minutes, did you meet similar issue on your side? -- Comment By: Marcelo Tosatti (mtosatti) Date: 2010-04-15 04:51 Message: 1) 32-bit WinXP qemu-system-x86_64 -drive file=/root/winxp-32-good.qcow2,cache=writeback -m 2000 -vnc :1 -usbdevice tablet -net nic,model=e1000 -net tap,script=/root/ifup 2) acpi on Control panes shows "ACPI multiprocessor PC" 3) shadow mode [r...@localhost ~]# cat /sys/module/kvm_intel/parameters/ept N host: Linux localhost.localdomain 2.6.34-rc3 #101 SMP Mon Apr 12 18:18:39 BRT 2010 i686 i686 i386 GNU/Linux Can you send a screenshot of the hang? -- Comment By: Xudong Hao (haoxudong) Date: 2010-04-13 13:45 Message: Motsatti, I checked again, guest still booting stop at the loading scroll bar. Let find what difference between ours. Can you check if your reproduce steps: 1) 32-bit WinXP 1) acpi on 2) shadow mode -- Comment By: Marcelo Tosatti (mtosatti) Date: 2010-04-13 06:28 Message: Xudong, Tested WinXP.32 and WinVista.32 on 32-bit host, both work fine. -- Comment By: Xudong Hao (haoxudong) Date: 2010-04-12 09:56 Message: Latest commit: 069c71e7a5e5f968099ca551f68e5dfe5a3f71bc qemu: 5c781061a45abe1855ad0a95d834336da574703c Windows guest did not blue screen with latest KVM commit, but guest hang at the loading scroll bar. This issue only happen on shadow mode. Windows guest can boot up with EPT mode. -- Comment By: Marcelo Tosatti (mtosatti) Date: 2010-04-06 02:50 Message: Xudong, Can you reproduce the problem with latest git repositories? The BSOD screenshot is truncated, the error number is not present. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2976863&group_id=180599 -- To unsubscribe from this list: send the line "
Re: [Autotest] [PATCH] KVM Test: Make remote_scp() more robust.
- "Michael Goldish" wrote:
> From: "Michael Goldish"
> To: "Feng Yang"
> Cc: autot...@test.kernel.org, kvm@vger.kernel.org
> Sent: Monday, May 17, 2010 11:05:37 PM GMT +08:00 Beijing / Chongqing / Hong
> Kong / Urumqi
> Subject: Re: [Autotest] [PATCH] KVM Test: Make remote_scp() more robust.
>
> On 05/07/2010 01:26 PM, Feng Yang wrote:
> > 1. In remote_scp(), if SCP connetion stalled for some reason,
> following
> > code will be ran.
> > else: # match == None
> >
> > logging.debug("Timeout elapsed or process terminated")
> > status = sub.get_status()
> > sub.close()
> > return status == 0
> > At this moment, kvm_subprocess server is still running which means
> > lock_server_running_filename is still locked. But sub.get_status()
> > tries to lock it again. If kvm_subprocess server keeps running,
> > a deadlock will happen. This patch will fix this issue by enable
>
> Agreed. It's a mistake (my mistake) to call get_status() on a
> process
> that's still running and isn't expected to terminate soon. I think
> even
> the docstring of get_status() says that it blocks, so that's expected
> behavior.
> However, there's a simple solution to that, and I don't see why an
> additional timeout is necessary.
>
> > timeout parameter. Update default value for timeout to 600, it
> should
> > be enough.
> >
> > 2. Add "-v" in scp command to catch more infomation. Also add "Exit
> status"
> > and "stalled" match prompt in remote_scp().
> > Signed-off-by: Feng Yang
> > ---
> > client/tests/kvm/kvm_utils.py | 36
>
> > client/tests/kvm/kvm_vm.py|4 ++--
> > 2 files changed, 30 insertions(+), 10 deletions(-)
> >
> > diff --git a/client/tests/kvm/kvm_utils.py
> b/client/tests/kvm/kvm_utils.py
> > index 25f3c8c..3db4dec 100644
> > --- a/client/tests/kvm/kvm_utils.py
> > +++ b/client/tests/kvm/kvm_utils.py
> > @@ -524,7 +524,7 @@ def remote_login(command, password, prompt,
> linesep="\n", timeout=10):
> > return None
> >
> >
> > -def remote_scp(command, password, timeout=300, login_timeout=10):
> > +def remote_scp(command, password, timeout=600, login_timeout=10):
> > """
> > Run the given command using kvm_spawn and provide answers to
> the questions
> > asked. If timeout expires while waiting for the transfer to
> complete ,
> > @@ -548,12 +548,18 @@ def remote_scp(command, password, timeout=300,
> login_timeout=10):
> >
> > password_prompt_count = 0
> > _timeout = login_timeout
> > +end_time = time.time() + timeout
> > +logging.debug("Trying to SCP...")
> >
> > -logging.debug("Trying to login...")
> >
> > while True:
> > +if end_time <= time.time():
> > +logging.debug("transfer timeout!")
> > +sub.close()
> > +return False
> > (match, text) = sub.read_until_last_line_matches(
> > -[r"[Aa]re you sure", r"[Pp]assword:\s*$", r"lost
> connection"],
> > +[r"[Aa]re you sure", r"[Pp]assword:\s*$", r"lost
> connection",
> > + r"Exit status", r"stalled"],
> > timeout=_timeout, internal_timeout=0.5)
> > if match == 0: # "Are you sure you want to continue
> connecting"
> > logging.debug("Got 'Are you sure...'; sending 'yes'")
> > @@ -574,15 +580,29 @@ def remote_scp(command, password, timeout=300,
> login_timeout=10):
> > logging.debug("Got 'lost connection'")
> > sub.close()
> > return False
> > +elif match == 3: # "Exit status"
>
> This check for "Exit status" is redundant. When the process
> terminates,
> read_until_last_line_matches() will return None and get_status() will
> return the exit status.
Here check for "Exit status", we can get not only the exit status,but also some
useful debug information when exit status is not 0.
Because we have enable '-v' in scp command.
but read_until_last_line_matches() only return exit status.
>
> > +sub.close()
> > +if "Exit status 0" in text:
> > +logging.debug("SCP command completed
> successfully")
> > +return True
> > +else:
> > +logging.debug("SCP command fail with exit status
> %s" % text)
> > +return False
> > +elif match == 4: # "stalled"
> > +logging.debug("SCP connection stalled for some
> reason")
> > +continue
> > +
> > else: # match == None
> > -logging.debug("Timeout elapsed or process terminated")
> > +if sub.is_alive():
> > +continue
> > +logging.debug("Process terminated for some reason")
> > status = sub.get_status()
> > sub.close()
> > return status == 0
>
> To avoid a deadlock, we can simply check if the process is still
> alive
> before calling get_status(), i.e.
>
> el
Re: [Qemu-devel] [RFC] Bug Day - June 1st, 2010
Natalia Portillo wrote: > Hi, > > > - We'll try to migrate as many confirmable bugs from the Source Forge > > tracker to Launchpad. > I think that part of the bug day should also include retesting OSes that > appear in OS Support List as having bug and confirming if the bug is still > present and if it's in Launchpad or not. There have been reports of several legacy OSes being unable to install or boot in the newer qemu while working in the older one. They're probably not in the "OS Support List" though. Are they effectively uninteresting for the purpose of the 0.13 release? Unfortunately I doubt I will have time to participate in the Bug Day. Thanks, -- Jamie -- 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
Re: [Qemu-devel] [RFC] Bug Day - June 1st, 2010
Hi, > - We'll try to migrate as many confirmable bugs from the Source Forge tracker > to Launchpad. I think that part of the bug day should also include retesting OSes that appear in OS Support List as having bug and confirming if the bug is still present and if it's in Launchpad or not. -- 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
Re: [PATCH net-next] ixgbe: return error in set_rar when index out of range
On Tue, May 18, 2010 at 08:34, Shirley Ma wrote:
> Return -1 when set_rar index is out of range
>
> Signed-off-by: Shirley Ma
> ---
>
> drivers/net/ixgbe/ixgbe_common.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
I think this should use IXGBE_ERR_ instead and there is another
spot where this could be used. Instead I propose this patch
instead...
ixgbe: return IXGBE_ERR_RAR_INDEX when out of range
From: Jeff Kirsher
Based on patch from Shirley Ma
Return IXGBE_ERR_RAR_INDEX when RAR index is out of range, instead of
returning IXGBE_SUCCESS.
Signed-off-by: Jeff Kirsher
Acked-by: Don Skidmore
---
drivers/net/ixgbe/ixgbe_common.c |2 ++
drivers/net/ixgbe/ixgbe_type.h |1 +
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_common.c b/drivers/net/ixgbe/ixgbe_common.c
index 1159d91..9595b1b 100644
--- a/drivers/net/ixgbe/ixgbe_common.c
+++ b/drivers/net/ixgbe/ixgbe_common.c
@@ -1188,6 +1188,7 @@ s32 ixgbe_set_rar_generic(struct ixgbe_hw *hw,
u32 index, u8 *addr, u32 vmdq,
IXGBE_WRITE_REG(hw, IXGBE_RAH(index), rar_high);
} else {
hw_dbg(hw, "RAR index %d is out of range.\n", index);
+ return IXGBE_ERR_RAR_INDEX;
}
return 0;
@@ -1219,6 +1220,7 @@ s32 ixgbe_clear_rar_generic(struct ixgbe_hw *hw,
u32 index)
IXGBE_WRITE_REG(hw, IXGBE_RAH(index), rar_high);
} else {
hw_dbg(hw, "RAR index %d is out of range.\n", index);
+ return IXGBE_ERR_RAR_INDEX;
}
/* clear VMDq pool/queue selection for this RAR */
diff --git a/drivers/net/ixgbe/ixgbe_type.h b/drivers/net/ixgbe/ixgbe_type.h
index bd69196..37d2807 100644
--- a/drivers/net/ixgbe/ixgbe_type.h
+++ b/drivers/net/ixgbe/ixgbe_type.h
@@ -2600,6 +2600,7 @@ struct ixgbe_info {
#define IXGBE_ERR_FDIR_REINIT_FAILED-23
#define IXGBE_ERR_EEPROM_VERSION-24
#define IXGBE_ERR_NO_SPACE -25
+#define IXGBE_ERR_RAR_INDEX -26
#define IXGBE_NOT_IMPLEMENTED 0x7FFF
#endif /* _IXGBE_TYPE_H_ */
--
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
[ PATCH 3/3] vhost: make it more scalable by creating a vhost thread per device
Make vhost more scalable by creating a separate vhost thread per
vhost device. This provides better scaling across virtio-net interfaces
in multiple guests.
Also attach each vhost thread to the cgroup and cpumask of the
associated guest(qemu or libvirt).
Signed-off-by: Sridhar Samudrala
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 9777583..18bf5be 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -329,19 +329,22 @@ static void handle_rx_net(struct work_struct *work)
static int vhost_net_open(struct inode *inode, struct file *f)
{
struct vhost_net *n = kmalloc(sizeof *n, GFP_KERNEL);
+ struct vhost_dev *dev;
int r;
if (!n)
return -ENOMEM;
+
+ dev = &n->dev;
n->vqs[VHOST_NET_VQ_TX].handle_kick = handle_tx_kick;
n->vqs[VHOST_NET_VQ_RX].handle_kick = handle_rx_kick;
- r = vhost_dev_init(&n->dev, n->vqs, VHOST_NET_VQ_MAX);
+ r = vhost_dev_init(dev, n->vqs, VHOST_NET_VQ_MAX);
if (r < 0) {
kfree(n);
return r;
}
- vhost_poll_init(n->poll + VHOST_NET_VQ_TX, handle_tx_net, POLLOUT);
- vhost_poll_init(n->poll + VHOST_NET_VQ_RX, handle_rx_net, POLLIN);
+ vhost_poll_init(n->poll + VHOST_NET_VQ_TX, handle_tx_net, POLLOUT, dev);
+ vhost_poll_init(n->poll + VHOST_NET_VQ_RX, handle_rx_net, POLLIN, dev);
n->tx_poll_state = VHOST_NET_POLL_DISABLED;
f->private_data = n;
@@ -644,25 +647,14 @@ static struct miscdevice vhost_net_misc = {
int vhost_net_init(void)
{
- int r = vhost_init();
- if (r)
- goto err_init;
- r = misc_register(&vhost_net_misc);
- if (r)
- goto err_reg;
- return 0;
-err_reg:
- vhost_cleanup();
-err_init:
- return r;
-
+ return misc_register(&vhost_net_misc);
}
+
module_init(vhost_net_init);
void vhost_net_exit(void)
{
misc_deregister(&vhost_net_misc);
- vhost_cleanup();
}
module_exit(vhost_net_exit);
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 49fa953..b076b9b 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -37,8 +37,6 @@ enum {
VHOST_MEMORY_F_LOG = 0x1,
};
-static struct workqueue_struct *vhost_workqueue;
-
static void vhost_poll_func(struct file *file, wait_queue_head_t *wqh,
poll_table *pt)
{
@@ -57,18 +55,19 @@ static int vhost_poll_wakeup(wait_queue_t *wait, unsigned
mode, int sync,
if (!((unsigned long)key & poll->mask))
return 0;
- queue_work(vhost_workqueue, &poll->work);
+ queue_work(poll->dev->wq, &poll->work);
return 0;
}
/* Init poll structure */
void vhost_poll_init(struct vhost_poll *poll, work_func_t func,
-unsigned long mask)
+unsigned long mask, struct vhost_dev *dev)
{
INIT_WORK(&poll->work, func);
init_waitqueue_func_entry(&poll->wait, vhost_poll_wakeup);
init_poll_funcptr(&poll->table, vhost_poll_func);
poll->mask = mask;
+ poll->dev = dev;
}
/* Start polling a file. We add ourselves to file's wait queue. The caller must
@@ -97,7 +96,7 @@ void vhost_poll_flush(struct vhost_poll *poll)
void vhost_poll_queue(struct vhost_poll *poll)
{
- queue_work(vhost_workqueue, &poll->work);
+ queue_work(poll->dev->wq, &poll->work);
}
static void vhost_vq_reset(struct vhost_dev *dev,
@@ -129,6 +128,13 @@ long vhost_dev_init(struct vhost_dev *dev,
struct vhost_virtqueue *vqs, int nvqs)
{
int i;
+ char vhost_name[20];
+
+ snprintf(vhost_name, 20, "vhost-%d", current->pid);
+ dev->wq = create_singlethread_workqueue_in_current_cg(vhost_name);
+ if (!dev->wq)
+ return -ENOMEM;
+
dev->vqs = vqs;
dev->nvqs = nvqs;
mutex_init(&dev->mutex);
@@ -144,7 +150,7 @@ long vhost_dev_init(struct vhost_dev *dev,
if (dev->vqs[i].handle_kick)
vhost_poll_init(&dev->vqs[i].poll,
dev->vqs[i].handle_kick,
- POLLIN);
+ POLLIN, dev);
}
return 0;
}
@@ -217,6 +223,8 @@ void vhost_dev_cleanup(struct vhost_dev *dev)
if (dev->mm)
mmput(dev->mm);
dev->mm = NULL;
+
+ destroy_workqueue(dev->wq);
}
static int log_access_ok(void __user *log_base, u64 addr, unsigned long sz)
@@ -1105,16 +1113,3 @@ void vhost_disable_notify(struct vhost_virtqueue *vq)
vq_err(vq, "Failed to enable notification at %p: %d\n",
&vq->used->flags, r);
}
-
-int vhost_init(void)
-{
- vhost_workqueue = create_singlethread_workqueue("vhost");
- if (!vhost_workqueue)
- return -ENOMEM;
- return 0;
-}
-
-void vhost_cleanup(void)
-{
- destroy_workqueue(vhost_wo
[PATCH 1/3] cgroups: Add an API to attach a task to current task's cgroup
Add a new kernel API to attach a task to current task's cgroup
in all the active hierarchies.
Signed-off-by: Sridhar Samudrala
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -570,6 +570,7 @@ struct task_struct *cgroup_iter_next(struct cgroup *cgrp,
void cgroup_iter_end(struct cgroup *cgrp, struct cgroup_iter *it);
int cgroup_scan_tasks(struct cgroup_scanner *scan);
int cgroup_attach_task(struct cgroup *, struct task_struct *);
+int cgroup_attach_task_current_cg(struct task_struct *);
/*
* CSS ID is ID for cgroup_subsys_state structs under subsys. This only works
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 6d870f2..6cfeb06 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1788,6 +1788,29 @@ out:
return retval;
}
+/**
+ * cgroup_attach_task_current_cg - attach task 'tsk' to current task's cgroup
+ * @tsk: the task to be attached
+ */
+int cgroup_attach_task_current_cg(struct task_struct *tsk)
+{
+ struct cgroupfs_root *root;
+ struct cgroup *cur_cg;
+ int retval = 0;
+
+ cgroup_lock();
+ for_each_active_root(root) {
+ cur_cg = task_cgroup_from_root(current, root);
+ retval = cgroup_attach_task(cur_cg, tsk);
+ if (retval)
+ break;
+ }
+ cgroup_unlock();
+
+ return retval;
+}
+EXPORT_SYMBOL_GPL(cgroup_attach_task_current_cg);
+
/*
* Attach task with pid 'pid' to cgroup 'cgrp'. Call with cgroup_mutex
* held. May take task_lock of task
--
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
[PATCH 2/3] workqueue: Add an API to create a singlethread workqueue attached to the current task's cgroup
Add a new kernel API to create a singlethread workqueue and attach it's
task to current task's cgroup and cpumask.
Signed-off-by: Sridhar Samudrala
diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index 9466e86..6d6f301 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -211,6 +211,7 @@ __create_workqueue_key(const char *name, int singlethread,
#define create_freezeable_workqueue(name) __create_workqueue((name), 1, 1, 0)
#define create_singlethread_workqueue(name) __create_workqueue((name), 1, 0, 0)
+extern struct workqueue_struct
*create_singlethread_workqueue_in_current_cg(char *name);
extern void destroy_workqueue(struct workqueue_struct *wq);
extern int queue_work(struct workqueue_struct *wq, struct work_struct *work);
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 5bfb213..6ba226e 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -35,6 +35,7 @@
#include
#define CREATE_TRACE_POINTS
#include
+#include
/*
* The per-CPU workqueue (if single thread, we always use the first
@@ -193,6 +194,45 @@ static const struct cpumask *cpu_singlethread_map
__read_mostly;
*/
static cpumask_var_t cpu_populated_map __read_mostly;
+static struct task_struct *get_singlethread_wq_task(struct workqueue_struct
*wq)
+{
+ return (per_cpu_ptr(wq->cpu_wq, singlethread_cpu))->thread;
+}
+
+/* Create a singlethread workqueue and attach it's task to the current task's
+ * cgroup and set it's cpumask to the current task's cpumask.
+ */
+struct workqueue_struct *create_singlethread_workqueue_in_current_cg(char
*name)
+{
+ struct workqueue_struct *wq;
+ struct task_struct *task;
+ cpumask_var_t mask;
+
+ wq = create_singlethread_workqueue(name);
+ if (!wq)
+ goto out;
+
+ if (!alloc_cpumask_var(&mask, GFP_KERNEL))
+ goto err;
+
+ if (sched_getaffinity(current->pid, mask))
+ goto err;
+
+ task = get_singlethread_wq_task(wq);
+ if (sched_setaffinity(task->pid, mask))
+ goto err;
+
+ if (cgroup_attach_task_current_cg(task))
+ goto err;
+out:
+ return wq;
+err:
+ destroy_workqueue(wq);
+ wq = NULL;
+ goto out;
+}
+EXPORT_SYMBOL_GPL(create_singlethread_workqueue_in_current_cg);
+
/* If it's single threaded, it isn't in the list of workqueues. */
static inline int is_wq_single_threaded(struct workqueue_struct *wq)
{
--
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
[PATCH 0/3] Make vhost multi-threaded and associate each thread to its guest's cgroup/cpumask
The following set of patches create a new API to associate a workqueue to the current thread's cgroup and cpumask. This API is used by multi-threaded vhost to associate each thread to the corresponding guest's cgroup and cpumask. Thanks Sridhar -- 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
[RFC] Bug Day - June 1st, 2010
Hi, In an effort to improve the 0.13 release quality, I'd like to host a Bug Day on June 1st, 2010. I've setup a quick wiki page with some more info (http://wiki.qemu.org/BugDay/June2010). Here's my basic thinking: - Anyone who can should try to spend some time either triaging bugs, updating bug status, or actually fixing bugs. - We'll have a special IRC channel (#qemu-bugday) on OFTC. As many QEMU and KVM developers as possible should join this channel for that day to help assist people working on bugs. - We'll try to migrate as many confirmable bugs from the Source Forge tracker to Launchpad. If this is successful, we'll try to have regular bug days. Any suggestions on how to make the experience as fun and productive as possible are certainly appreciated! Regards, Anthony Liguori -- 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
Re: KVM call minutes for May 18
On 05/18/2010 04:34 PM, Brian Jackson wrote: A lot of the existing bugs are irrelevant and/or woefully out of date. I've been hesitant to go back and mess with too many old bugs for fear of making too much noise that I know isn't going to do anything useful (i.e. marking the 100 oldest bugs as Closed - Out Of Date) One activity for bug day should be migrating bugs from SF to Launchpad that can be confirmed. I don't know if SF has an expiration mechanism, but on Launchpad, you can mark a bug as needs info and if it isn't updated in 90 days, it automatically expires. - need more people involved w/ bug work And need a better way for those of us that do to be able to get ahold of devs to look at things that are actually important to users. Part of the idea of bug day is to get devs in an IRC channel so that people can ask questions in real time about bugs. - possible bug-day before next release - suggested June 1st Personally (and in general for volunteer projects), weekends are better for bugs days. That said, I realize that most of the developers for qemu/kvm do this for their day job. Not everyone has the same weekend due to TZ/country differences. That said, if the first bug day is successful, we can hold more and try to accommodate different groups of people. Regards, Anthony Liguori 0.12.4 bugs - migration regression...follow-up on email, open a bug ;-) -- 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 -- 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 -- 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
Re: [Qemu-devel] Re: KVM call agenda for May 18
On 05/18/2010 12:31 PM, Avi Kivity wrote: On 05/18/2010 05:34 PM, Anthony Liguori wrote: No. I don't think our goal is to ever fully convert monitor commands to QMP. Some commands simply don't make sense as QMP commands (like x and xp). Examining memory does make sense for QMP, although it is already available through the gdb protocol, so it's kind of redundant. The x and xp commands are meant to be used with all sorts of expressions. I agree examining memory makes sense but we certainly want a very different interface for it. Regards, Anthony Liguori -- 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
Re: KVM call minutes for May 18
On Tuesday 18 May 2010 09:29:25 Chris Wright wrote: > 0.13 release > - push out to July 1st > - esp. important to solidy/crispen QMP > - 1 rc to shake out brown paper bag bugs, then final release > > block i/o performance (high CPU consumption) > - memset can be removed (patch posted, queued by kwolf) > - cpu_physical_memory_rw known, should gather data > > block 1TB limit > - sounds like integer issue > - bug report needs to be updated (verify it's still happening in 0.12.4? > - should be able to easily reproduce (can use lvm to create sparse volume) > > sourceforge bug tracker... > - sucks Agreed. > - unclear if there's active triage I do. I go in every couple of weeks and go through the last two pages of bugs or so. > - anthony prefers the launchpad instance I prefer one tracker that more than just I look at. If that's launchpad, I'm fine with that. Avi/KVM devs, what are your feelings? > - alex likes the sf email to list, wuld be good to keep that feature It looks (at first glance) that we can still have this functionality. It's certainly available to individuals. > - had to migrate existing bugs (be nice if we could stop sf from growing) A lot of the existing bugs are irrelevant and/or woefully out of date. I've been hesitant to go back and mess with too many old bugs for fear of making too much noise that I know isn't going to do anything useful (i.e. marking the 100 oldest bugs as Closed - Out Of Date) > - need more people involved w/ bug work And need a better way for those of us that do to be able to get ahold of devs to look at things that are actually important to users. > - possible bug-day before next release > - suggested June 1st Personally (and in general for volunteer projects), weekends are better for bugs days. That said, I realize that most of the developers for qemu/kvm do this for their day job. > > 0.12.4 bugs > - migration regression...follow-up on email, open a bug ;-) > -- > 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 -- 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
Re: [PATCH +stable] block: don't attempt to merge overlapping requests
On Tue, May 18, 2010 at 8:41 PM, Michael Tokarev wrote: > But actually I don't quite see where that dependency is: guest > does not know how its data is cached on host... I was thinking of this bit in linux-2.6:drivers/block/virtio_blk.c: /* If barriers are supported, tell block layer that queue is ordered */ if (virtio_has_feature(vdev, VIRTIO_BLK_F_FLUSH)) blk_queue_ordered(q, QUEUE_ORDERED_DRAIN_FLUSH, virtblk_prepare_flush); else if (virtio_has_feature(vdev, VIRTIO_BLK_F_BARRIER)) blk_queue_ordered(q, QUEUE_ORDERED_TAG, NULL); I was wondering whether we have something wrong, causing the guest to perform overlapping write requests without draining the queue or flushing. Stefan -- 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
Re: KVM call agenda for May 18
* Brian Jackson (i...@theiggy.com) wrote: > On Tuesday 18 May 2010 08:52:36 Anthony Liguori wrote: > > On 05/18/2010 01:59 AM, Brian Jackson wrote: > > > On Monday 17 May 2010 22:23:46 Chris Wright wrote: > > >> Please send in any agenda items you are interested in covering. > > >> > > >> If we have a lack of agenda items I'll cancel the week's call. > > > > > > Perceived long standing bugs that nobody seems to care about. There are a > > > few, one of which is the> 1TB [1] bug that has existed for 4+ months. > > > > s/care about/know about/g > > > > This should be filed in launchpad as a qemu bug and it should be tested > > against the latest git. This bug sounds like we're using an int to > > represent sector offset somewhere but there's not enough info in the bug > > report to figure out for sure. I just audited the virtio-blk -> raw -> > > aio=threads path and I don't see an obvious place that we're getting it > > wrong. > > > > > And others. > > > > Bugs that affect qemu should be filed in launchpad. Launchpad has nice > > features like the able to mark bugs as affecting many users which help > > raise visibility. I can't speak for the source forge tracker, but I do > > regular triage on launchpad for qemu bugs. > > > I wonder how everyone would feel about closing the kvm tracker to new > submissions and move everything over to launchpad? Yeah, this was suggested on the call today. Anthony's sending out an email proposal on better bug tracking thanks, -chris -- 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
Re: KVM call agenda for May 18
On Tuesday 18 May 2010 08:52:36 Anthony Liguori wrote: > On 05/18/2010 01:59 AM, Brian Jackson wrote: > > On Monday 17 May 2010 22:23:46 Chris Wright wrote: > >> Please send in any agenda items you are interested in covering. > >> > >> If we have a lack of agenda items I'll cancel the week's call. > > > > Perceived long standing bugs that nobody seems to care about. There are a > > few, one of which is the> 1TB [1] bug that has existed for 4+ months. > > s/care about/know about/g > > This should be filed in launchpad as a qemu bug and it should be tested > against the latest git. This bug sounds like we're using an int to > represent sector offset somewhere but there's not enough info in the bug > report to figure out for sure. I just audited the virtio-blk -> raw -> > aio=threads path and I don't see an obvious place that we're getting it > wrong. > > > And others. > > Bugs that affect qemu should be filed in launchpad. Launchpad has nice > features like the able to mark bugs as affecting many users which help > raise visibility. I can't speak for the source forge tracker, but I do > regular triage on launchpad for qemu bugs. I wonder how everyone would feel about closing the kvm tracker to new submissions and move everything over to launchpad? > > Regards, > > Anthony Liguori > > > This can wait for a later call if necessary... not worth a call on it's > > own. > > > > > > Etc: > > [1] > > http://sourceforge.net/tracker/?func=detail&aid=2933400&group_id=180599&; > > atid=893831 > > > >> thanks, > >> -chris > >> -- > >> 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 > > > > -- > > 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 -- 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
Re: [PATCH +stable] block: don't attempt to merge overlapping requests
18.05.2010 23:37, Stefan Hajnoczi wrote: I just caught up on mails and saw you had already mentioned that overlapping writes from the guest look fishy in the "the>1Tb block issue". Cache mode might still be interesting because it affects how guest virtio-blk chooses queue ordering mode. What I can say for sure is that the issue mentioned (>1Tb block) occurs regardless of the cache mode. I tried all 3, with exactly the same results (well, not entirely exactly, since the prob depends on timing too, and timing is different depending on the cache mode), and performed all further tests with cache=writeback since it's the mode which lets the guest to finish mkfs'ing the 1.5Tb "disk" in a reasonable time (or else it takes hours). But actually I don't quite see where that dependency is: guest does not know how its data is cached on host... /mjt -- 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
Re: [PATCH +stable] block: don't attempt to merge overlapping requests
I just caught up on mails and saw you had already mentioned that overlapping writes from the guest look fishy in the "the >1Tb block issue". Cache mode might still be interesting because it affects how guest virtio-blk chooses queue ordering mode. Stefan -- 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
Re: [PATCH +stable] block: don't attempt to merge overlapping requests
On Tue, May 18, 2010 at 6:18 PM, Avi Kivity wrote: > The block multiwrite code pretends to be able to merge overlapping requests, > but doesn't do so in fact. This leads to I/O errors (for example on mkfs > of a large virtio disk). Are overlapping write requests correct guest behavior? I thought the ordering semantics require a flush between overlapping writes to ensure A is written before B. What cache= mode are you running? Stefan -- 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
Re: the >1Tb block issue
18.05.2010 22:38, Michael Tokarev пишет:
18.05.2010 22:09, Avi Kivity wrote:
On 05/18/2010 09:03 PM, Michael Tokarev wrote:
18.05.2010 21:38, Avi Kivity wrote:
[Qemu-devel] [PATCH +stable] block: don't attempt to merge overlapping
requests
quick tests shows it works correctly so far.
At least it went further than before, not
stopping at the "usual" sector 3145727872.
Hmm. Ide has no queue, hence no mergeing,
that's why it does not occur with ide,
right? :)
[]
Yes. Why would Linux post overlapping requests? makes
0x
sense.
[]
Note also that it's not as on the original bugreport -
there, the sector# is apparently different:
http://sourceforge.net/tracker/?func=detail&aid=2933400&group_id=180599&atid=893831
I don't think it's related to a particular sector number.
I added a debug printf into the place that is touched
by the patch mentioned above, to print the case where
the request were merged before that patch but not any
more with it applied:
if (reqs[i].sector == oldreq_last) {
merge = 1;
}
else if (reqs[i].sector < oldreq_last)
fprintf(stderr, "NOT mergeing:\n"
" reqs[i].sector=%Ld oldreq_last=%Ld\n"
" reqs[outidx].sector=%Ld reqs[outidx].nb_sectors=%d\n"
, reqs[i].sector, oldreq_last,
reqs[outidx].sector, reqs[outidx].nb_sectors);
In a few runs it showed different info (and I modified the
printf line 2 times too):
NOT mergeing: reqs[i].sector=92306456 oldreq_last=3145728000
NOT mergeing:
reqs[i].sector=92322056 oldreq_last=3145728000
reqs[outidx].sector=3145727872
NOT mergeing:
reqs[i].sector=0 oldreq_last=3145728000
reqs[outidx].sector=3145727872 reqs[outidx].nb_sectors=128
NOT mergeing:
reqs[i].sector=0 oldreq_last=3145728000
reqs[outidx].sector=3145727872 reqs[outidx].nb_sectors=128
NOT mergeing:
reqs[i].sector=92308152 oldreq_last=3145728000
reqs[outidx].sector=3145727872 reqs[outidx].nb_sectors=128
NOT mergeing:
reqs[i].sector=0 oldreq_last=3145728000
reqs[outidx].sector=3145727872 reqs[outidx].nb_sectors=128
So it's definitely timing-related somehow (esp. it changes
when interrupting mkfs and immediately starting again), and
shows different values, but for me it's - apparently - always
reqs[outidx].sector=3145727872 together with some other sector.
And once I hit "Send" it showed another:
NOT mergeing:
reqs[i].sector=760 oldreq_last=3141599488
reqs[outidx].sector=3141597896 reqs[outidx].nb_sectors=1592
so it's not the case here ;)
/mjt
--
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
Re: the >1Tb block issue
18.05.2010 22:09, Avi Kivity wrote:
On 05/18/2010 09:03 PM, Michael Tokarev wrote:
18.05.2010 21:38, Avi Kivity wrote:
[Qemu-devel] [PATCH +stable] block: don't attempt to merge overlapping
requests
quick tests shows it works correctly so far.
At least it went further than before, not
stopping at the "usual" sector 3145727872.
Hmm. Ide has no queue, hence no mergeing,
that's why it does not occur with ide,
right? :)
[]
Yes. Why would Linux post overlapping requests? makes 0x
sense.
[]
Note also that it's not as on the original bugreport -
there, the sector# is apparently different:
http://sourceforge.net/tracker/?func=detail&aid=2933400&group_id=180599&atid=893831
I don't think it's related to a particular sector number.
I added a debug printf into the place that is touched
by the patch mentioned above, to print the case where
the request were merged before that patch but not any
more with it applied:
if (reqs[i].sector == oldreq_last) {
merge = 1;
}
else if (reqs[i].sector < oldreq_last)
fprintf(stderr, "NOT mergeing:\n"
" reqs[i].sector=%Ld oldreq_last=%Ld\n"
" reqs[outidx].sector=%Ld reqs[outidx].nb_sectors=%d\n"
, reqs[i].sector, oldreq_last,
reqs[outidx].sector, reqs[outidx].nb_sectors);
In a few runs it showed different info (and I modified the
printf line 2 times too):
NOT mergeing: reqs[i].sector=92306456 oldreq_last=3145728000
NOT mergeing:
reqs[i].sector=92322056 oldreq_last=3145728000
reqs[outidx].sector=3145727872
NOT mergeing:
reqs[i].sector=0 oldreq_last=3145728000
reqs[outidx].sector=3145727872 reqs[outidx].nb_sectors=128
NOT mergeing:
reqs[i].sector=0 oldreq_last=3145728000
reqs[outidx].sector=3145727872 reqs[outidx].nb_sectors=128
NOT mergeing:
reqs[i].sector=92308152 oldreq_last=3145728000
reqs[outidx].sector=3145727872 reqs[outidx].nb_sectors=128
NOT mergeing:
reqs[i].sector=0 oldreq_last=3145728000
reqs[outidx].sector=3145727872 reqs[outidx].nb_sectors=128
So it's definitely timing-related somehow (esp. it changes
when interrupting mkfs and immediately starting again), and
shows different values, but for me it's - apparently - always
reqs[outidx].sector=3145727872 together with some other sector.
/mjt
--
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
Re: the >1Tb block issue
On 05/18/2010 09:03 PM, Michael Tokarev wrote: 18.05.2010 21:38, Avi Kivity wrote: [Qemu-devel] [PATCH +stable] block: don't attempt to merge overlapping requests quick tests shows it works correctly so far. At least it went further than before, not stopping at the "usual" sector 3145727872. Hmm. Ide has no queue, hence no mergeing, that's why it does not occur with ide, right? :) Yes. I tried multiple times to reproduce it with if=scsi (queue_depth=16 for the sym53c8xx driver). I can't. JFYI.. ;) Merging needs explicit support in the block device emulation, which scsi lacks. Interesting... Yes. Why would Linux post overlapping requests? makes 0x sense. It's mkfs. mkfs simply writes to the block device, even if it does issue overlapping writes, Linux shouldn't. Either the writes contain the same content in the overlapping section, in which case it's redundant, or they don't, and we have data corruption in the making. Not sure why, but yes, maybe it's a guest bug after all. It's a host bug for sure, with a potential for a guest bug. Note that I'm running 64bit kernel on the guest (2.6.32.9-amd64). Note also that it's not as on the original bugreport - there, the sector# is apparently different: http://sourceforge.net/tracker/?func=detail&aid=2933400&group_id=180599&atid=893831 I don't think it's related to a particular sector number. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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
Re: the >1Tb block issue
18.05.2010 21:38, Avi Kivity wrote: [Qemu-devel] [PATCH +stable] block: don't attempt to merge overlapping requests quick tests shows it works correctly so far. At least it went further than before, not stopping at the "usual" sector 3145727872. Hmm. Ide has no queue, hence no mergeing, that's why it does not occur with ide, right? :) Yes. I tried multiple times to reproduce it with if=scsi (queue_depth=16 for the sym53c8xx driver). I can't. JFYI.. ;) (And this kinda explains why the bug does not occur when run under strace; which also indicates that it isn't necessary easy to trigger it, too). Interesting... Yes. Why would Linux post overlapping requests? makes 0x sense. It's mkfs. Not sure why, but yes, maybe it's a guest bug after all. Note that I'm running 64bit kernel on the guest (2.6.32.9-amd64). Note also that it's not as on the original bugreport - there, the sector# is apparently different: http://sourceforge.net/tracker/?func=detail&aid=2933400&group_id=180599&atid=893831 There may be a guest bug in here too. Christoph? /mjt -- 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
Re: [PATCHv2] vhost-net: utilize PUBLISH_USED_IDX feature
On 05/18/2010 05:21 AM, Michael S. Tsirkin wrote: With PUBLISH_USED_IDX, guest tells us which used entries it has consumed. This can be used to reduce the number of interrupts: after we write a used entry, if the guest has not yet consumed the previous entry, or if the guest has already consumed the new entry, we do not need to interrupt. This imporves bandwidth by 30% under some workflows. Seems to be missing the cacheline alignment. Rusty's clarification did not satisfy me, I think it's needed. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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
Re: [Qemu-devel] Re: KVM call agenda for May 18
On Tue, 18 May 2010 17:16:54 +0100 "Daniel P. Berrange" wrote: > On Tue, May 18, 2010 at 01:00:40PM -0300, Luiz Capitulino wrote: > > On Tue, 18 May 2010 15:55:41 +0100 > > "Daniel P. Berrange" wrote: > > > > > On Tue, May 18, 2010 at 09:34:06AM -0500, Anthony Liguori wrote: > > > > On 05/18/2010 09:09 AM, Daniel P. Berrange wrote: > > > > >On Tue, May 18, 2010 at 08:53:19AM -0500, Anthony Liguori wrote: > > > > > > > > > >>On 05/17/2010 10:23 PM, Chris Wright wrote: > > > > >> > > > > >>>Please send in any agenda items you are interested in covering. > > > > >>> > > > > >>>If we have a lack of agenda items I'll cancel the week's call. > > > > >>> > > > > >>> > > > > >>- Slipping 0.13 release out to July 1st. > > > > >> > > > > >What is the plan wrt QMP and 0.13 ? Is the intention to have 100%[1] > > > > >of the > > > > >existing monitor commands converted to QMP? > > > > > > > > No. I don't think our goal is to ever fully convert monitor commands > > > > to > > > > QMP. Some commands simply don't make sense as QMP commands (like x and > > > > xp). > > > > > > We're a really long way from a complete conversion even ignoring > > > commands which don't make sense in QMP. The current state almost > > > covers the commands libvirt currently uses, but there's much more > > > beyond that. > > > > As far as I understood it, the plan for the first QMP release has always > > been to only convert the subset of commands relevant/used by libvirt. > > Well we've evolved the plan several times since QMP started & the set > of commands used by libvirt has evolved too! So I just want to define > exactly what we're proposing to support for 0.13 release. The current set of libvirt used commands plus the must haves ones, this is the maximum we can be committed with for the next release. If time allows, I will pick more from the outstanding list. > > > I don't think we can claim all those are irrelevant for QMP. > > > > > > So are we still targetting complete conversion of relevant commands > > > for 0.13, or is it just going to be a stepping stone where declare > > > QMP stable, but known to be incomplete for coverage of commands ? > > > > The first thing to do is to agree on what a 'complete coverage' would be, > > what we have been trying to do since January is to provide a complete set > > for libvirt, our unique well known client so far. > > > > Apart from the 'outstanding' set above, can you elaborate on how > > QMP on 0.13 would not satisfy libvirt needs? > > The must haves are blockdev_add, and the commit/delvm/loadvm/savevm > stuff, since they're already in use. > > The problem I fear is that we're aiming for a moving target here. > > eg, by the time QEMU 0.13 comes out libvirt may have received patches > using yet more QEMU monitor commands. So the list I mention above is > my best guesstimate at the commands that could appear in libvirt in > the not too distant future. The more of those we can support the better > so that we avoid geting into a case where QEMU 0.13 is released, but a > yet newer libvirt wants extra QMP commands that weren't included in 0.13. This problem isn't 0.13 specific as I expect new Monitor commands to be added in qemu at every release. It's true that QMP makes this more evident due its limited set, still we have to deal with the fact that the command set is always going to be extended. Here's what I think we should do: 1. Clients should check for the availability of commands by issuing query-commands. Eg. A) Issue query-commands at startup and cache its output B) Before issuing any command, check whether it's supported C) Issue an error message if the command is not supported 2. Both projects should work closely, so that features are in sync at every release 3. We could create an official 'priority list' in qemu's tree, with a listing of commands to be converted for the next release and clients should work closely by suggesting changes to this list -- 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
[ kvm-Bugs-2989366 ] huge memory leak (qemu-kvm 0.12.3)
Bugs item #2989366, was opened at 2010-04-19 16:47
Message generated for change (Comment added) made by avik
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2989366&group_id=180599
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: tgr (tgr1)
Assigned to: Nobody/Anonymous (nobody)
Summary: huge memory leak (qemu-kvm 0.12.3)
Initial Comment:
CPU: Xeon E5450
KVM: qemu-kvm 0.12.3
Host: Debian Squeeze amd64, kernel 2.6.32
Guest: Debian Lenny amd64, kernel 2.6.26
qemu command line below (no helpers like libvirt used)
whether the problem goes away if using the -no-kvm-irqchip or -no-kvm-pit
switch: seems unrelated
whether the problem also appears with the -no-kvm switch: load profile of the
guest makes running without KVM infeasible
The problem: after 4 days, the kvm process of a guest run with -mem 3072 takes
12 GB VSZ / 9 GB RSS - grows until OOM ("kvm invoked oom-killer" in dmesg).
At that point the guest shows more than 2 GB of free memory.
qemu command line:
kvm -smp 4 -m 3072 -net nic,vlan=0,model=virtio,name=eth0,macaddr=x:x:x:x:x:x
-net tap,vlan=0,ifname=tap6 -net
nic,vlan=1,model=virtio,name=eth1,macaddr=x:x:x:x:x:x -net
tap,vlan=1,ifname=tap7 -drive if=virtio,file=/dev/x/x-rootfs,index=0 -drive
if=virtio,file=/dev/x/x-swap,index=1 -name x -nographic -kernel
/boot/vmlinuz-2.6.26-2-amd64 -initrd /boot/initrd.img-2.6.26-2-amd64 -append
root=/dev/vda console=ttyS0 -echr 2 -serial
mon:telnet:localhost:12344,server,nowait -monitor
unix:/var/run/kvm-x,server,nowait -daemonize -watchdog i6300esb
-watchdog-action reset
(the monitor on both telnet and unix socket is intentional, the one on the
socket is only used for sending system_reset and system_powerdown qemu
commands).
--
>Comment By: Avi Kivity (avik)
Date: 2010-05-18 20:44
Message:
Should be fixed in qemu-kvm-0.12.4.
--
Comment By: trevoro (trevoro)
Date: 2010-05-18 20:25
Message:
I am experiencing an identical issue on an AMD Sempron with qemu-kvm
0.12.3.
We have a few virtual machines running on this host. After a few days this
is what the memory utilization looks like for the KVM processes.
be95ae3e-5f79-11df-b0c0-540001bf0689 1024M: vsz=1241M rss=706M
3bd6f690-5c65-11df-9fb1-5400013f4a54 512M: vsz=675M rss=466M
c103e4e4-5e00-11df-94fe-540001fccc62256M: vsz=1470M rss=301M
0c068dba-5df8-11df-938c-5400015669e3 256M: vsz=7646M rss=2560M
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2989366&group_id=180599
--
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
Re: the >1Tb block issue
On 05/18/2010 08:34 PM, Michael Tokarev wrote: 18.05.2010 21:29, Avi Kivity wrote: On 05/18/2010 06:52 PM, Michael Tokarev wrote: I just re-verified it on current stable qemu-kvm-0.12.4. The issue is still here, trivial to trigger. Can you try the patch I just posted? Applied this one: [Qemu-devel] [PATCH +stable] block: don't attempt to merge overlapping requests quick tests shows it works correctly so far. At least it went further than before, not stopping at the "usual" sector 3145727872. Hmm. Ide has no queue, hence no mergeing, that's why it does not occur with ide, right? :) Yes. Interesting... Yes. Why would Linux post overlapping requests? makes 0x sense. There may be a guest bug in here too. Christoph? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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
Re: the >1Tb block issue
18.05.2010 21:29, Avi Kivity wrote: On 05/18/2010 06:52 PM, Michael Tokarev wrote: I just re-verified it on current stable qemu-kvm-0.12.4. The issue is still here, trivial to trigger. Can you try the patch I just posted? Applied this one: [Qemu-devel] [PATCH +stable] block: don't attempt to merge overlapping requests quick tests shows it works correctly so far. At least it went further than before, not stopping at the "usual" sector 3145727872. Hmm. Ide has no queue, hence no mergeing, that's why it does not occur with ide, right? :) Interesting... /mjt -- 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
Re: [Qemu-devel] Re: KVM call agenda for May 18
On 05/18/2010 05:34 PM, Anthony Liguori wrote: No. I don't think our goal is to ever fully convert monitor commands to QMP. Some commands simply don't make sense as QMP commands (like x and xp). Examining memory does make sense for QMP, although it is already available through the gdb protocol, so it's kind of redundant. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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
Re: the >1Tb block issue
On 05/18/2010 06:52 PM, Michael Tokarev wrote: I just re-verified it on current stable qemu-kvm-0.12.4. The issue is still here, trivial to trigger. Can you try the patch I just posted? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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
Re: [PATCH v5 4/5] Inter-VM shared memory PCI device
On 05/18/2010 07:58 PM, Cam Macdonell wrote: My question is how to I unregister the physical memory so it is not copied on migration (for the role=peer case). There isn't a cpu_unregister_physical_memory(). It doesn't need to be unregistered, simply marked not migratable. Perhaps a flags argument to c_r_p_m(). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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
[ kvm-Bugs-2989366 ] huge memory leak (qemu-kvm 0.12.3)
Bugs item #2989366, was opened at 2010-04-19 13:47
Message generated for change (Comment added) made by trevoro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2989366&group_id=180599
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: tgr (tgr1)
Assigned to: Nobody/Anonymous (nobody)
Summary: huge memory leak (qemu-kvm 0.12.3)
Initial Comment:
CPU: Xeon E5450
KVM: qemu-kvm 0.12.3
Host: Debian Squeeze amd64, kernel 2.6.32
Guest: Debian Lenny amd64, kernel 2.6.26
qemu command line below (no helpers like libvirt used)
whether the problem goes away if using the -no-kvm-irqchip or -no-kvm-pit
switch: seems unrelated
whether the problem also appears with the -no-kvm switch: load profile of the
guest makes running without KVM infeasible
The problem: after 4 days, the kvm process of a guest run with -mem 3072 takes
12 GB VSZ / 9 GB RSS - grows until OOM ("kvm invoked oom-killer" in dmesg).
At that point the guest shows more than 2 GB of free memory.
qemu command line:
kvm -smp 4 -m 3072 -net nic,vlan=0,model=virtio,name=eth0,macaddr=x:x:x:x:x:x
-net tap,vlan=0,ifname=tap6 -net
nic,vlan=1,model=virtio,name=eth1,macaddr=x:x:x:x:x:x -net
tap,vlan=1,ifname=tap7 -drive if=virtio,file=/dev/x/x-rootfs,index=0 -drive
if=virtio,file=/dev/x/x-swap,index=1 -name x -nographic -kernel
/boot/vmlinuz-2.6.26-2-amd64 -initrd /boot/initrd.img-2.6.26-2-amd64 -append
root=/dev/vda console=ttyS0 -echr 2 -serial
mon:telnet:localhost:12344,server,nowait -monitor
unix:/var/run/kvm-x,server,nowait -daemonize -watchdog i6300esb
-watchdog-action reset
(the monitor on both telnet and unix socket is intentional, the one on the
socket is only used for sending system_reset and system_powerdown qemu
commands).
--
Comment By: trevoro (trevoro)
Date: 2010-05-18 17:25
Message:
I am experiencing an identical issue on an AMD Sempron with qemu-kvm
0.12.3.
We have a few virtual machines running on this host. After a few days this
is what the memory utilization looks like for the KVM processes.
be95ae3e-5f79-11df-b0c0-540001bf0689 1024M: vsz=1241M rss=706M
3bd6f690-5c65-11df-9fb1-5400013f4a54 512M: vsz=675M rss=466M
c103e4e4-5e00-11df-94fe-540001fccc62256M: vsz=1470M rss=301M
0c068dba-5df8-11df-938c-5400015669e3 256M: vsz=7646M rss=2560M
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2989366&group_id=180599
--
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
[PATCH +stable] block: don't attempt to merge overlapping requests
The block multiwrite code pretends to be able to merge overlapping requests,
but doesn't do so in fact. This leads to I/O errors (for example on mkfs
of a large virtio disk).
Signed-off-by: Avi Kivity
---
block.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/block.c b/block.c
index 48305b7..0e44e26 100644
--- a/block.c
+++ b/block.c
@@ -1956,8 +1956,8 @@ static int multiwrite_merge(BlockDriverState *bs,
BlockRequest *reqs,
int64_t oldreq_last = reqs[outidx].sector + reqs[outidx].nb_sectors;
// This handles the cases that are valid for all block drivers, namely
-// exactly sequential writes and overlapping writes.
-if (reqs[i].sector <= oldreq_last) {
+// exactly sequential writes
+if (reqs[i].sector == oldreq_last) {
merge = 1;
}
--
1.6.6.1
--
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
Re: [PATCH v5 4/5] Inter-VM shared memory PCI device
On Mon, May 10, 2010 at 10:52 AM, Anthony Liguori wrote: >> Yes, I think the ack is the way to go, so the guest has to be aware of >> it. Would setting a flag in the driver-specific config space be an >> acceptable ack that the shared region is now mapped? >> > > You know it's mapped because it's mapped when the pci map function returns. > You don't need the guest to explicitly tell you. > I've been playing with migration. It appears that the memory is preserved on migration in the default case which makes sense as it is part of the qemu memory allocation. In my current implementation, I "map" the shared memory in by calling cpu_register_physical_memory() with the offset returned from qemu_ram_map(). My question is how to I unregister the physical memory so it is not copied on migration (for the role=peer case). There isn't a cpu_unregister_physical_memory(). Cam -- 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
Re: the >1Tb block issue
On Tue, May 18, 2010 at 08:51:55PM +0400, Michael Tokarev wrote: > 18.05.2010 19:52, Michael Tokarev wrote: > >I just re-verified it on current stable > >qemu-kvm-0.12.4. The issue is still here, > >trivial to trigger. > > > >kvm-img create test.raw 1500G > >kvm ... \ > >-drive file=test.raw,if=virtio > > > >it fails right on the mkfs stage: > > > >mkfs.ext4 /dev/vdb > >Writing inode tables: end_request: I/O error, dev vdb, sector 3145727872 > >Buffer I/O error on device vdb, logical block 393215984 > >lost page write due to I/O error on vdb > >Buffer I/O error on device vdb, logical block 393215985 > >... > >Buffer I/O error on device vdb, logical block 393215993 > > > >After that it continues the mkfs process, but I doubt it will > >produce a good filesystem. > > A few more data point, for what it's worth. > > I tried running it under strace, but in that case the issue does > not occur: mkfs wents on without errors. That puzzles me: timing > problem? > > It always fails at the same place: sector 3145727872. This > is - apparently - somewhere at the end of my 1500Gb file. > Hmmm. 3145727872*512 = 0x -- Gleb. -- 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
Re: the >1Tb block issue
18.05.2010 19:52, Michael Tokarev wrote: I just re-verified it on current stable qemu-kvm-0.12.4. The issue is still here, trivial to trigger. kvm-img create test.raw 1500G kvm ... \ -drive file=test.raw,if=virtio it fails right on the mkfs stage: mkfs.ext4 /dev/vdb Writing inode tables: end_request: I/O error, dev vdb, sector 3145727872 Buffer I/O error on device vdb, logical block 393215984 lost page write due to I/O error on vdb Buffer I/O error on device vdb, logical block 393215985 ... Buffer I/O error on device vdb, logical block 393215993 After that it continues the mkfs process, but I doubt it will produce a good filesystem. A few more data point, for what it's worth. I tried running it under strace, but in that case the issue does not occur: mkfs wents on without errors. That puzzles me: timing problem? It always fails at the same place: sector 3145727872. This is - apparently - somewhere at the end of my 1500Gb file. If I hit Ctrl+C to stop it, mkfs will sit there forever, waiting for sync_file_pages. I tried both 32 and 64bit host with 64bit guest. The effect is exactly the same. So far, only virtio has this problem. I tested with if=ide, it's slower but it went much further without any error. It's still running, but at this rate it will run for some hours more ;) At least it does not spew errors like the virtio case. That seems to work, the filesystem looks healthy. /mjt -- 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
Re: [Qemu-devel] Re: KVM call agenda for May 18
On 05/18/2010 11:16 AM, Daniel P. Berrange wrote: The must haves are blockdev_add, and the commit/delvm/loadvm/savevm stuff, since they're already in use. The problem I fear is that we're aiming for a moving target here. eg, by the time QEMU 0.13 comes out libvirt may have received patches using yet more QEMU monitor commands. libvirt could just stop taking patches that use monitor commands. There's no way we're going to break the deadlock if we don't work together here. Regards, Anthony Liguori -- 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
Re: [Qemu-devel] Re: KVM call agenda for May 18
On Tue, May 18, 2010 at 01:00:40PM -0300, Luiz Capitulino wrote: > On Tue, 18 May 2010 15:55:41 +0100 > "Daniel P. Berrange" wrote: > > > On Tue, May 18, 2010 at 09:34:06AM -0500, Anthony Liguori wrote: > > > On 05/18/2010 09:09 AM, Daniel P. Berrange wrote: > > > >On Tue, May 18, 2010 at 08:53:19AM -0500, Anthony Liguori wrote: > > > > > > > >>On 05/17/2010 10:23 PM, Chris Wright wrote: > > > >> > > > >>>Please send in any agenda items you are interested in covering. > > > >>> > > > >>>If we have a lack of agenda items I'll cancel the week's call. > > > >>> > > > >>> > > > >>- Slipping 0.13 release out to July 1st. > > > >> > > > >What is the plan wrt QMP and 0.13 ? Is the intention to have 100%[1] of > > > >the > > > >existing monitor commands converted to QMP? > > > > > > No. I don't think our goal is to ever fully convert monitor commands to > > > QMP. Some commands simply don't make sense as QMP commands (like x and > > > xp). > > > > We're a really long way from a complete conversion even ignoring > > commands which don't make sense in QMP. The current state almost > > covers the commands libvirt currently uses, but there's much more > > beyond that. > > As far as I understood it, the plan for the first QMP release has always > been to only convert the subset of commands relevant/used by libvirt. Well we've evolved the plan several times since QMP started & the set of commands used by libvirt has evolved too! So I just want to define exactly what we're proposing to support for 0.13 release. > > I don't think we can claim all those are irrelevant for QMP. > > > > So are we still targetting complete conversion of relevant commands > > for 0.13, or is it just going to be a stepping stone where declare > > QMP stable, but known to be incomplete for coverage of commands ? > > The first thing to do is to agree on what a 'complete coverage' would be, > what we have been trying to do since January is to provide a complete set > for libvirt, our unique well known client so far. > > Apart from the 'outstanding' set above, can you elaborate on how > QMP on 0.13 would not satisfy libvirt needs? The must haves are blockdev_add, and the commit/delvm/loadvm/savevm stuff, since they're already in use. The problem I fear is that we're aiming for a moving target here. eg, by the time QEMU 0.13 comes out libvirt may have received patches using yet more QEMU monitor commands. So the list I mention above is my best guesstimate at the commands that could appear in libvirt in the not too distant future. The more of those we can support the better so that we avoid geting into a case where QEMU 0.13 is released, but a yet newer libvirt wants extra QMP commands that weren't included in 0.13. Regards, Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- 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
Guest-induced heap overrun
There's a bug in the VNC code that overruns the heap whenever the horizontal resolution isn't a multiple of 16. Here's how to trigger it: Step 1: build a linux kernel with CONFIG_FB_VESA=y. The one you're running right now probably works. Step 2: -vga std -kernel bzImage -append 'vga=898' -vnc localhost:2 Step 3: Connect and disconnect VNC a few times. This can also be triggered on Windows, etc. I can't trigger it on upstream qemu because 1400x1050 isn't listed, cirrusfb is too broken to force that mode, and vmwgfx seems to be even more broken right now. (I'm way too lazy to make an image containing X just for this.) This bug is present in F13 and in Avi's tree from a week or so ago. I can't test the latest -git because that one segfaults instantly no matter what I do. I'll leave the actual exploit as an exercise to the reader. I'm emailing here because the bug is easiest to trigger in qemu-kvm and because both Red Hat / Fedora and upstream qemu have been ignoring a security bug for over two weeks. See: https://bugs.launchpad.net/qemu/+bug/575887 (Upstream bug) https://bugzilla.redhat.com/show_bug.cgi?id=583850 (Fedora bug) --Andy -- 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
Re: [Qemu-devel] Re: KVM call agenda for May 18
On Tue, 18 May 2010 15:55:41 +0100
"Daniel P. Berrange" wrote:
> On Tue, May 18, 2010 at 09:34:06AM -0500, Anthony Liguori wrote:
> > On 05/18/2010 09:09 AM, Daniel P. Berrange wrote:
> > >On Tue, May 18, 2010 at 08:53:19AM -0500, Anthony Liguori wrote:
> > >
> > >>On 05/17/2010 10:23 PM, Chris Wright wrote:
> > >>
> > >>>Please send in any agenda items you are interested in covering.
> > >>>
> > >>>If we have a lack of agenda items I'll cancel the week's call.
> > >>>
> > >>>
> > >>- Slipping 0.13 release out to July 1st.
> > >>
> > >What is the plan wrt QMP and 0.13 ? Is the intention to have 100%[1] of the
> > >existing monitor commands converted to QMP?
> >
> > No. I don't think our goal is to ever fully convert monitor commands to
> > QMP. Some commands simply don't make sense as QMP commands (like x and xp).
>
> We're a really long way from a complete conversion even ignoring
> commands which don't make sense in QMP. The current state almost
> covers the commands libvirt currently uses, but there's much more
> beyond that.
As far as I understood it, the plan for the first QMP release has always
been to only convert the subset of commands relevant/used by libvirt.
We've been trying to figure out this set for a long time.
> > Is there a set of commands that you think need to be converted that
> > currently aren't?
>
> Notable outstanding commands that libvirt has a non-negligable
> chance of wanting to use in the not too distant future
>
> - blockdev_add/del (to replace drive_add/del)
Markus is working on this.
> - commit/delvm/loadvm/savevm
I did a first try, but errors in those handlers are a mess and didn't
map well to QMP. I think QError improvements are needed to get this done.
> - screendump
> - set_link
Both already converted.
> - mouse_{move,button,set}
> - sendkey
> - acl_{add,remove,policy,reset,show}
> - boot_set
> - watchdog_action
Not converted and I'm not sure how hard they are.
> The full list of unconverted commands though is much long:
[...]
> I don't think we can claim all those are irrelevant for QMP.
>
> So are we still targetting complete conversion of relevant commands
> for 0.13, or is it just going to be a stepping stone where declare
> QMP stable, but known to be incomplete for coverage of commands ?
The first thing to do is to agree on what a 'complete coverage' would be,
what we have been trying to do since January is to provide a complete set
for libvirt, our unique well known client so far.
Apart from the 'outstanding' set above, can you elaborate on how
QMP on 0.13 would not satisfy libvirt needs?
--
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
Re: the >1Tb block issue
On Tue, May 18, 2010 at 07:52:45PM +0400, Michael Tokarev wrote: > I just re-verified it on current stable > qemu-kvm-0.12.4. The issue is still here, > trivial to trigger. > > kvm-img create test.raw 1500G > kvm ... \ > -drive file=test.raw,if=virtio > > it fails right on the mkfs stage: > > mkfs.ext4 /dev/vdb > Writing inode tables: end_request: I/O error, dev vdb, sector 3145727872 > Buffer I/O error on device vdb, logical block 393215984 > lost page write due to I/O error on vdb > Buffer I/O error on device vdb, logical block 393215985 > ... > Buffer I/O error on device vdb, logical block 393215993 > > After that it continues the mkfs process, but I doubt it will > produce a good filesystem. > > So far, only virtio has this problem. I tested with if=ide, it's > slower but it went much further without any error. It's still > running, but at this rate it will run for some hours more ;) > At least it does not spew errors like the virtio case. FYI this is a really useful tool for validating correctness of the block layer. http://people.redhat.com/sct/src/verify-data/ Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- 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
the >1Tb block issue
I just re-verified it on current stable qemu-kvm-0.12.4. The issue is still here, trivial to trigger. kvm-img create test.raw 1500G kvm ... \ -drive file=test.raw,if=virtio it fails right on the mkfs stage: mkfs.ext4 /dev/vdb Writing inode tables: end_request: I/O error, dev vdb, sector 3145727872 Buffer I/O error on device vdb, logical block 393215984 lost page write due to I/O error on vdb Buffer I/O error on device vdb, logical block 393215985 ... Buffer I/O error on device vdb, logical block 393215993 After that it continues the mkfs process, but I doubt it will produce a good filesystem. So far, only virtio has this problem. I tested with if=ide, it's slower but it went much further without any error. It's still running, but at this rate it will run for some hours more ;) At least it does not spew errors like the virtio case. Unfortunately I don't have enough free space to test. Yes the file is sparse, but it grows quite fast when mkfs is running, and I'm not sure the ~100Gb free space on the largest filesystem I have will be enough for it... but let's see. /mjt /mjt -- 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
Re: [Qemu-devel] Re: KVM call agenda for May 18
Markus Armbruster writes: [...] >> - set_link > > Patch posted weeks ago, still not merged. Correction: it got merged weeks ago, as commit 5369e3c0. I got confused. [...] -- 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
Re: [Qemu-devel] Re: KVM call agenda for May 18
"Daniel P. Berrange" writes:
> On Tue, May 18, 2010 at 09:34:06AM -0500, Anthony Liguori wrote:
>> On 05/18/2010 09:09 AM, Daniel P. Berrange wrote:
>> >On Tue, May 18, 2010 at 08:53:19AM -0500, Anthony Liguori wrote:
>> >
>> >>On 05/17/2010 10:23 PM, Chris Wright wrote:
>> >>
>> >>>Please send in any agenda items you are interested in covering.
>> >>>
>> >>>If we have a lack of agenda items I'll cancel the week's call.
>> >>>
>> >>>
>> >>- Slipping 0.13 release out to July 1st.
>> >>
>> >What is the plan wrt QMP and 0.13 ? Is the intention to have 100%[1] of the
>> >existing monitor commands converted to QMP?
>>
>> No. I don't think our goal is to ever fully convert monitor commands to
>> QMP. Some commands simply don't make sense as QMP commands (like x and xp).
>
> We're a really long way from a complete conversion even ignoring
> commands which don't make sense in QMP. The current state almost
> covers the commands libvirt currently uses, but there's much more
> beyond that.
>
>> Is there a set of commands that you think need to be converted that
>> currently aren't?
>
> Notable outstanding commands that libvirt has a non-negligable
> chance of wanting to use in the not too distant future
>
> - blockdev_add/del (to replace drive_add/del)
Working on it. It's hairy.
> - commit/delvm/loadvm/savevm
Luiz posted an RFC patch. It's hairy.
> - screendump
Haven't looked into it.
> - set_link
Patch posted weeks ago, still not merged.
> - mouse_{move,button,set}
> - sendkey
> - acl_{add,remove,policy,reset,show}
> - boot_set
> - watchdog_action
Same as screendump.
> The full list of unconverted commands though is much long:
[...]
> I don't think we can claim all those are irrelevant for QMP.
>
> So are we still targetting complete conversion of relevant commands
> for 0.13, or is it just going to be a stepping stone where declare
> QMP stable, but known to be incomplete for coverage of commands ?
Completeness and stability are mostly orthogonal. If we get the
fundamentals right, we can add missing stuff without destabilizing
existing stuff. To get them right, we need to cover enough material to
develop our understanding of the problems, and to enable real use.
Until libvirt can use QMP, we fail on "real use".
--
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
[PATCH net-next] ixgbe: return error in set_rar when index out of range
Return -1 when set_rar index is out of range
Signed-off-by: Shirley Ma
---
drivers/net/ixgbe/ixgbe_common.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_common.c
b/drivers/net/ixgbe/ixgbe_common.c
index 1159d91..77b3cf4 100644
--- a/drivers/net/ixgbe/ixgbe_common.c
+++ b/drivers/net/ixgbe/ixgbe_common.c
@@ -1188,6 +1188,7 @@ s32 ixgbe_set_rar_generic(struct ixgbe_hw *hw, u32
index, u8 *addr, u32 vmdq,
IXGBE_WRITE_REG(hw, IXGBE_RAH(index), rar_high);
} else {
hw_dbg(hw, "RAR index %d is out of range.\n", index);
+ return -1;
}
return 0;
--
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
Re: [Qemu-devel] Re: KVM call agenda for May 18
On 05/18/2010 09:55 AM, Daniel P. Berrange wrote:
On Tue, May 18, 2010 at 09:34:06AM -0500, Anthony Liguori wrote:
On 05/18/2010 09:09 AM, Daniel P. Berrange wrote:
On Tue, May 18, 2010 at 08:53:19AM -0500, Anthony Liguori wrote:
On 05/17/2010 10:23 PM, Chris Wright wrote:
Please send in any agenda items you are interested in covering.
If we have a lack of agenda items I'll cancel the week's call.
- Slipping 0.13 release out to July 1st.
What is the plan wrt QMP and 0.13 ? Is the intention to have 100%[1] of the
existing monitor commands converted to QMP?
No. I don't think our goal is to ever fully convert monitor commands to
QMP. Some commands simply don't make sense as QMP commands (like x and xp).
We're a really long way from a complete conversion even ignoring
commands which don't make sense in QMP. The current state almost
covers the commands libvirt currently uses, but there's much more
beyond that.
Is there a set of commands that you think need to be converted that
currently aren't?
Notable outstanding commands that libvirt has a non-negligable
chance of wanting to use in the not too distant future
- blockdev_add/del (to replace drive_add/del)
- commit/delvm/loadvm/savevm
- screendump
- set_link
- mouse_{move,button,set}
- sendkey
- acl_{add,remove,policy,reset,show}
- boot_set
- watchdog_action
The full list of unconverted commands though is much long:
Thanks. A lot of these should be easy to convert.
$ grep cmd qemu-monitor.hx | grep -v cmd_new | grep -v async
.mhandler.cmd = do_help_cmd,
We don't need this.
.mhandler.cmd = do_commit,
.mhandler.cmd = do_logfile,
.mhandler.cmd = do_log,
I think we can skip log and logfile.
.mhandler.cmd = do_savevm,
.mhandler.cmd = do_loadvm,
.mhandler.cmd = do_delvm,
.mhandler.cmd = do_singlestep,
.mhandler.cmd = do_gdbserver,
.mhandler.cmd = do_memory_dump,
.mhandler.cmd = do_physical_memory_dump,
I'd prefer to skip the memory dump commands.
.mhandler.cmd = do_print,
We can skip this.
.mhandler.cmd = do_ioport_read,
.mhandler.cmd = do_ioport_write,
.mhandler.cmd = do_sendkey,
.mhandler.cmd = do_sum,
We can skip do_sum.
.mhandler.cmd = do_usb_add,
.mhandler.cmd = do_usb_del,
.mhandler.cmd = do_mouse_move,
.mhandler.cmd = do_mouse_button,
.mhandler.cmd = do_mouse_set,
.mhandler.cmd = do_wav_capture,
.mhandler.cmd = do_stop_capture,
I'd prefer we skip wav capture.
.mhandler.cmd = do_boot_set,
.mhandler.cmd = do_inject_nmi,
.mhandler.cmd = drive_hot_add,
.mhandler.cmd = net_host_device_add,
.mhandler.cmd = net_host_device_remove,
.mhandler.cmd = net_slirp_hostfwd_add,
.mhandler.cmd = net_slirp_hostfwd_remove,
.mhandler.cmd = do_watchdog_action,
.mhandler.cmd = do_acl_show,
.mhandler.cmd = do_acl_policy,
.mhandler.cmd = do_acl_add,
.mhandler.cmd = do_acl_remove,
.mhandler.cmd = do_acl_reset,
.mhandler.cmd = do_inject_mce,
$ grep 'mhandler.info' monitor.c | grep -v info_new | grep -v async
.mhandler.info = do_info_network,
.mhandler.info = do_info_registers,
.mhandler.info = do_info_history,
.mhandler.info = irq_info,
.mhandler.info = pic_info,
.mhandler.info = tlb_info,
.mhandler.info = mem_info,
.mhandler.info = do_info_jit,
.mhandler.info = do_info_numa,
.mhandler.info = usb_info,
.mhandler.info = usb_host_info,
.mhandler.info = do_info_profile,
.mhandler.info = do_info_capture,
.mhandler.info = do_info_snapshots,
.mhandler.info = pcmcia_info,
.mhandler.info = do_info_cpu_stats,
.mhandler.info = do_info_usernet,
.mhandler.info = do_info_qtree,
.mhandler.info = do_info_qdm,
.mhandler.info = do_info_roms,
I'd rather not convert info commands until there were users. Info
commands don't map well to QMP because of their lack of structure.
Regards,
Anthony Liguori
I don't think we can claim all those are irrelevant for QMP.
So are we still targetting complete conversion of relevant commands
for 0.13, or is it just going to be a stepping stone where declare
QMP stable, but known to be incomplete for coverage of commands ?
Daniel
--
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
Re: [RFC] 0.13.0 Release plan
On 05/18/2010 09:52 AM, Luiz Capitulino wrote: On Tue, 18 May 2010 09:32:32 -0500 Anthony Liguori wrote: Hi, Here's my current thinking for the 0.13.0 release. Since there's a lot of activity going on with QMP, I'd like to move the release out to July 1st. Here's what I'd like to do between now and then: - Do a detailed review of the QMP specification by sending out portions of the spec to the mailing list and waiting for at least 3 acks (Stefan/Anthony) Agreed. Actually I was wondering if this shouldn't be QMP's development plan, ie. any QMP change which is protocol visible, must: 1. Add the proper entry in qmp-commands.txt 2. Get three ACKs on the list Yes, I think that's a good idea. Of course that we need qmp-commands.txt merged. Jan has just finished incorporating its contents in qemu-monitor.hx, now qmp-commands.txt is generated from there. I will fix the doc's reported problems in his series and submit it. - Redesign QError to be more consistent (Markus/Luiz) Yes, we have all issues pointed out by Avi too. I plan to look at them as soon as the document is merged. However, the ones used by libvirt should be considered with extra care. - Host a bug day on June 1st (more details in later note) Excellent idea, suggest asking in that thread if anyone volunteers to be the issue tracker's 'maintainer' (main job is bug triage). If anyone volunteers, that would be great but it's definitely a tough job. I'm going to setup a wiki page with some information about how to participate in the Bug Day and then I'll send out another note later today. Regards, Anthony Liguori - Freeze stable-0.13 on June 21st and release 0.13.0-rc - Accept only bug fixes for stable-0.13 - 0.13.0-rc2 release on June 28th - 0.13.0 release on July 1st ACK Any feedback and/or suggestions would be appreciated. Regards, Anthony Liguori -- 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
Re: RFC: kvmclock / tsc server side fix
On 05/18/2010 04:08 AM, Glauber Costa wrote: On Mon, May 17, 2010 at 09:38:30AM -1000, Zachary Amsden wrote: On 05/17/2010 05:36 AM, Glauber Costa wrote: On Fri, May 14, 2010 at 04:07:43PM -1000, Zachary Amsden wrote: I believe this fixes the root cause of the kvmclock warp. It's quite a plausible phenomenon, and explains why it was so easy to produce. You mean this is the case for both SMP and UP, or just UP as we talked before? It's possible on both SMP and UP, guest and host. It is impossible on UP host unless special circumstances come into play (one of my patches created these circumstances). I don't get the role of upscale in your patch. Frequency changes are already handled by the cpufreq notifier. The only purpose of upscale is to downscale the measurement of delta used for counting stats if CPU frequency was raised since last observed. This is because moving to a faster TSC rate means we might have counted some cycles at the wrong rate while the rate was in transition. It doesn't much matter, as the delta for which "overrun" is logged was computed wrong anyway. mind sending the stats part in a separate patch? Yeah, part of this was badly broken. I'll clean up my patches and resend as a series today. Zach Or today. Nasty bug. -- 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
Re: [Qemu-devel] Re: KVM call agenda for May 18
On Tue, May 18, 2010 at 09:34:06AM -0500, Anthony Liguori wrote:
> On 05/18/2010 09:09 AM, Daniel P. Berrange wrote:
> >On Tue, May 18, 2010 at 08:53:19AM -0500, Anthony Liguori wrote:
> >
> >>On 05/17/2010 10:23 PM, Chris Wright wrote:
> >>
> >>>Please send in any agenda items you are interested in covering.
> >>>
> >>>If we have a lack of agenda items I'll cancel the week's call.
> >>>
> >>>
> >>- Slipping 0.13 release out to July 1st.
> >>
> >What is the plan wrt QMP and 0.13 ? Is the intention to have 100%[1] of the
> >existing monitor commands converted to QMP?
>
> No. I don't think our goal is to ever fully convert monitor commands to
> QMP. Some commands simply don't make sense as QMP commands (like x and xp).
We're a really long way from a complete conversion even ignoring
commands which don't make sense in QMP. The current state almost
covers the commands libvirt currently uses, but there's much more
beyond that.
> Is there a set of commands that you think need to be converted that
> currently aren't?
Notable outstanding commands that libvirt has a non-negligable
chance of wanting to use in the not too distant future
- blockdev_add/del (to replace drive_add/del)
- commit/delvm/loadvm/savevm
- screendump
- set_link
- mouse_{move,button,set}
- sendkey
- acl_{add,remove,policy,reset,show}
- boot_set
- watchdog_action
The full list of unconverted commands though is much long:
$ grep cmd qemu-monitor.hx | grep -v cmd_new | grep -v async
.mhandler.cmd = do_help_cmd,
.mhandler.cmd = do_commit,
.mhandler.cmd = do_logfile,
.mhandler.cmd = do_log,
.mhandler.cmd = do_savevm,
.mhandler.cmd = do_loadvm,
.mhandler.cmd = do_delvm,
.mhandler.cmd = do_singlestep,
.mhandler.cmd = do_gdbserver,
.mhandler.cmd = do_memory_dump,
.mhandler.cmd = do_physical_memory_dump,
.mhandler.cmd = do_print,
.mhandler.cmd = do_ioport_read,
.mhandler.cmd = do_ioport_write,
.mhandler.cmd = do_sendkey,
.mhandler.cmd = do_sum,
.mhandler.cmd = do_usb_add,
.mhandler.cmd = do_usb_del,
.mhandler.cmd = do_mouse_move,
.mhandler.cmd = do_mouse_button,
.mhandler.cmd = do_mouse_set,
.mhandler.cmd = do_wav_capture,
.mhandler.cmd = do_stop_capture,
.mhandler.cmd = do_boot_set,
.mhandler.cmd = do_inject_nmi,
.mhandler.cmd = drive_hot_add,
.mhandler.cmd = net_host_device_add,
.mhandler.cmd = net_host_device_remove,
.mhandler.cmd = net_slirp_hostfwd_add,
.mhandler.cmd = net_slirp_hostfwd_remove,
.mhandler.cmd = do_watchdog_action,
.mhandler.cmd = do_acl_show,
.mhandler.cmd = do_acl_policy,
.mhandler.cmd = do_acl_add,
.mhandler.cmd = do_acl_remove,
.mhandler.cmd = do_acl_reset,
.mhandler.cmd = do_inject_mce,
$ grep 'mhandler.info' monitor.c | grep -v info_new | grep -v async
.mhandler.info = do_info_network,
.mhandler.info = do_info_registers,
.mhandler.info = do_info_history,
.mhandler.info = irq_info,
.mhandler.info = pic_info,
.mhandler.info = tlb_info,
.mhandler.info = mem_info,
.mhandler.info = do_info_jit,
.mhandler.info = do_info_numa,
.mhandler.info = usb_info,
.mhandler.info = usb_host_info,
.mhandler.info = do_info_profile,
.mhandler.info = do_info_capture,
.mhandler.info = do_info_snapshots,
.mhandler.info = pcmcia_info,
.mhandler.info = do_info_cpu_stats,
.mhandler.info = do_info_usernet,
.mhandler.info = do_info_qtree,
.mhandler.info = do_info_qdm,
.mhandler.info = do_info_roms,
I don't think we can claim all those are irrelevant for QMP.
So are we still targetting complete conversion of relevant commands
for 0.13, or is it just going to be a stepping stone where declare
QMP stable, but known to be incomplete for coverage of commands ?
Daniel
--
|: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org-o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
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
Re: [RFC] 0.13.0 Release plan
On Tue, 18 May 2010 09:32:32 -0500 Anthony Liguori wrote: > Hi, > > Here's my current thinking for the 0.13.0 release. Since there's a lot > of activity going on with QMP, I'd like to move the release out to July 1st. > > Here's what I'd like to do between now and then: > > - Do a detailed review of the QMP specification by sending out > portions of the spec to the mailing list and waiting for at least 3 acks > (Stefan/Anthony) Agreed. Actually I was wondering if this shouldn't be QMP's development plan, ie. any QMP change which is protocol visible, must: 1. Add the proper entry in qmp-commands.txt 2. Get three ACKs on the list Of course that we need qmp-commands.txt merged. Jan has just finished incorporating its contents in qemu-monitor.hx, now qmp-commands.txt is generated from there. I will fix the doc's reported problems in his series and submit it. > - Redesign QError to be more consistent (Markus/Luiz) Yes, we have all issues pointed out by Avi too. I plan to look at them as soon as the document is merged. However, the ones used by libvirt should be considered with extra care. > - Host a bug day on June 1st (more details in later note) Excellent idea, suggest asking in that thread if anyone volunteers to be the issue tracker's 'maintainer' (main job is bug triage). > - Freeze stable-0.13 on June 21st and release 0.13.0-rc > - Accept only bug fixes for stable-0.13 > - 0.13.0-rc2 release on June 28th > - 0.13.0 release on July 1st ACK > > Any feedback and/or suggestions would be appreciated. > > Regards, > > Anthony Liguori > -- 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
Re: [Qemu-devel] Re: KVM call agenda for May 18
On 05/18/2010 09:09 AM, Daniel P. Berrange wrote: On Tue, May 18, 2010 at 08:53:19AM -0500, Anthony Liguori wrote: On 05/17/2010 10:23 PM, Chris Wright wrote: Please send in any agenda items you are interested in covering. If we have a lack of agenda items I'll cancel the week's call. - Slipping 0.13 release out to July 1st. What is the plan wrt QMP and 0.13 ? Is the intention to have 100%[1] of the existing monitor commands converted to QMP? No. I don't think our goal is to ever fully convert monitor commands to QMP. Some commands simply don't make sense as QMP commands (like x and xp). Is there a set of commands that you think need to be converted that currently aren't? Regards, Anthony Liguori There are still quite alot of monitor commands not converted and given the time take to get this far, it seems optimistic to expect completion by July, let alone a feature freeze date preceeding that. Regards, Daniel [1] Excluding obsolete commands like drive_add, pci_add replaced by device_add -- 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
[RFC] 0.13.0 Release plan
Hi, Here's my current thinking for the 0.13.0 release. Since there's a lot of activity going on with QMP, I'd like to move the release out to July 1st. Here's what I'd like to do between now and then: - Do a detailed review of the QMP specification by sending out portions of the spec to the mailing list and waiting for at least 3 acks (Stefan/Anthony) - Redesign QError to be more consistent (Markus/Luiz) - Host a bug day on June 1st (more details in later note) - Freeze stable-0.13 on June 21st and release 0.13.0-rc - Accept only bug fixes for stable-0.13 - 0.13.0-rc2 release on June 28th - 0.13.0 release on July 1st Any feedback and/or suggestions would be appreciated. Regards, Anthony Liguori -- 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
KVM call minutes for May 18
0.13 release - push out to July 1st - esp. important to solidy/crispen QMP - 1 rc to shake out brown paper bag bugs, then final release block i/o performance (high CPU consumption) - memset can be removed (patch posted, queued by kwolf) - cpu_physical_memory_rw known, should gather data block 1TB limit - sounds like integer issue - bug report needs to be updated (verify it's still happening in 0.12.4? - should be able to easily reproduce (can use lvm to create sparse volume) sourceforge bug tracker... - sucks - unclear if there's active triage - anthony prefers the launchpad instance - alex likes the sf email to list, wuld be good to keep that feature - had to migrate existing bugs (be nice if we could stop sf from growing) - need more people involved w/ bug work - possible bug-day before next release - suggested June 1st 0.12.4 bugs - migration regression...follow-up on email, open a bug ;-) -- 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
Re: [Qemu-devel] Re: KVM call agenda for May 18
On Tue, May 18, 2010 at 08:53:19AM -0500, Anthony Liguori wrote: > On 05/17/2010 10:23 PM, Chris Wright wrote: > >Please send in any agenda items you are interested in covering. > > > >If we have a lack of agenda items I'll cancel the week's call. > > > > - Slipping 0.13 release out to July 1st. What is the plan wrt QMP and 0.13 ? Is the intention to have 100%[1] of the existing monitor commands converted to QMP? There are still quite alot of monitor commands not converted and given the time take to get this far, it seems optimistic to expect completion by July, let alone a feature freeze date preceeding that. Regards, Daniel [1] Excluding obsolete commands like drive_add, pci_add replaced by device_add -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- 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
Re: RFC: kvmclock / tsc server side fix
On Mon, May 17, 2010 at 09:38:30AM -1000, Zachary Amsden wrote: > On 05/17/2010 05:36 AM, Glauber Costa wrote: > >On Fri, May 14, 2010 at 04:07:43PM -1000, Zachary Amsden wrote: > >>I believe this fixes the root cause of the kvmclock warp. It's > >>quite a plausible phenomenon, and explains why it was so easy to > >>produce. > >> > >You mean this is the case for both SMP and UP, or just UP as we talked > >before? > > It's possible on both SMP and UP, guest and host. It is impossible > on UP host unless special circumstances come into play (one of my > patches created these circumstances). > > >I don't get the role of upscale in your patch. Frequency changes are > >already handled by the cpufreq notifier. > > The only purpose of upscale is to downscale the measurement of delta > used for counting stats if CPU frequency was raised since last > observed. This is because moving to a faster TSC rate means we > might have counted some cycles at the wrong rate while the rate was > in transition. It doesn't much matter, as the delta for which > "overrun" is logged was computed wrong anyway. mind sending the stats part in a separate patch? > > I'll clean up my patches and resend as a series today. > > Zach -- 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
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
Alexander Graf wrote: Peter Lieven wrote: Alexander Graf wrote: Peter Lieven wrote: we are running on intel xeons here: That might be the reason. Does it break when passing -no-kvm? processor: 0 vendor_id: GenuineIntel cpu family: 6 model: 26 model name: Intel(R) Xeon(R) CPU L5530 @ 2.40GHz stepping: 5 cpu MHz: 2394.403 cache size: 8192 KB physical id: 1 siblings: 4 core id: 0 cpu cores: 4 apicid: 16 initial apicid: 16 fpu: yes fpu_exception: yes cpuid level: 11 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology tsc_reliable nonstop_tsc pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid bogomips: 4788.80 clflush size: 64 cache_alignment: 64 address sizes: 40 bits physical, 48 bits virtual power management: kvm-kmod is 2.6.32.7 ... which commandline parameters do you supply to qemu-kvm? None :) It seems to stop working if i supply -no-kvm-irqchip. Can you try to reproduce this? We introduced that parameter because we encountered some problems with the e1000 kernel driver stopped to work in some guests after live migration with a "nobody cared about interupt" (i don't know the exact error anymore). supplying -no-kvm-irqchip made live migration of these guests possible... Sounds that familiar to someone? So it works with the in-kernel irqchip? That's the normally supported configuration anyways. If migration fails with that, that's a different thing and definitely needs to be addressed. Yes, it seems, I got the machine booting ~10 times without any problems. I will try to reproduce the error condition after migration and come back to the list. Thanks for your help, Peter Alex -- 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
Re: KVM call agenda for May 18
On 05/17/2010 10:23 PM, Chris Wright wrote: Please send in any agenda items you are interested in covering. If we have a lack of agenda items I'll cancel the week's call. - Slipping 0.13 release out to July 1st. - Block I/O performance (high CPU consumption) Regards, Anthony Liguori thanks, -chris -- 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 -- 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
Re: KVM call agenda for May 18
On 05/18/2010 01:59 AM, Brian Jackson wrote: On Monday 17 May 2010 22:23:46 Chris Wright wrote: Please send in any agenda items you are interested in covering. If we have a lack of agenda items I'll cancel the week's call. Perceived long standing bugs that nobody seems to care about. There are a few, one of which is the> 1TB [1] bug that has existed for 4+ months. s/care about/know about/g This should be filed in launchpad as a qemu bug and it should be tested against the latest git. This bug sounds like we're using an int to represent sector offset somewhere but there's not enough info in the bug report to figure out for sure. I just audited the virtio-blk -> raw -> aio=threads path and I don't see an obvious place that we're getting it wrong. And others. Bugs that affect qemu should be filed in launchpad. Launchpad has nice features like the able to mark bugs as affecting many users which help raise visibility. I can't speak for the source forge tracker, but I do regular triage on launchpad for qemu bugs. Regards, Anthony Liguori This can wait for a later call if necessary... not worth a call on it's own. Etc: [1] http://sourceforge.net/tracker/?func=detail&aid=2933400&group_id=180599&atid=893831 thanks, -chris -- 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 -- 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 -- 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
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
Peter Lieven wrote: > Alexander Graf wrote: >> Peter Lieven wrote: >> >>> we are running on intel xeons here: >>> >> >> That might be the reason. Does it break when passing -no-kvm? >> >> >>> processor: 0 >>> vendor_id: GenuineIntel >>> cpu family: 6 >>> model: 26 >>> model name: Intel(R) Xeon(R) CPU L5530 @ 2.40GHz >>> stepping: 5 >>> cpu MHz: 2394.403 >>> cache size: 8192 KB >>> physical id: 1 >>> siblings: 4 >>> core id: 0 >>> cpu cores: 4 >>> apicid: 16 >>> initial apicid: 16 >>> fpu: yes >>> fpu_exception: yes >>> cpuid level: 11 >>> wp: yes >>> flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge >>> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe >>> syscall rdtscp lm constant_tsc arch_perfmon pebs bts rep_good >>> xtopology tsc_reliable nonstop_tsc pni dtes64 monitor ds_cpl vmx est >>> tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm tpr_shadow >>> vnmi flexpriority ept vpid >>> bogomips: 4788.80 >>> clflush size: 64 >>> cache_alignment: 64 >>> address sizes: 40 bits physical, 48 bits virtual >>> power management: >>> >>> kvm-kmod is 2.6.32.7 >>> ... >>> >>> which commandline parameters do you supply to qemu-kvm? >>> >> >> None :) >> > It seems to stop working if i supply -no-kvm-irqchip. Can you try to > reproduce this? > > We introduced that parameter because we encountered some problems with > the e1000 kernel driver stopped to work in some > guests after live migration with a "nobody cared about interupt" (i > don't know the exact error anymore). supplying > -no-kvm-irqchip made live migration of these guests possible... > Sounds that familiar to someone? So it works with the in-kernel irqchip? That's the normally supported configuration anyways. If migration fails with that, that's a different thing and definitely needs to be addressed. Alex -- 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
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
Peter Lieven writes: > Starting mail service (Postfix) > NMI Watchdog detected LOCKUP on CPU 0 You could simply turn off the NMI watchdog (nmi_watchdog=0 at the kernel command line) Perhaps the PMU emulation is not complete and nmi watchdog needs PMU. It's not really needed normally. -Andi -- a...@linux.intel.com -- Speaking for myself only. -- 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
Re: qemu-kvm hangs if multipath device is queing
Am 18.05.2010 13:10, schrieb Peter Lieven: > hi kevin, > > here is the backtrace of (hopefully) all threads: > > ^C > Program received signal SIGINT, Interrupt. > [Switching to Thread 0x7f39b72656f0 (LWP 10695)] > 0x7f39b6c3ea94 in __lll_lock_wait () from /lib/libpthread.so.0 > > (gdb) thread apply all bt > > Thread 2 (Thread 0x7f39b57b8950 (LWP 10698)): > #0 0x7f39b6c3eedb in read () from /lib/libpthread.so.0 > #1 0x0049e723 in qemu_laio_completion_cb (opaque=0x22b4010) at > linux-aio.c:125 > #2 0x0049e8ad in laio_cancel (blockacb=0x22ba310) at > linux-aio.c:184 I think it's stuck here in an endless loop: while (laiocb->ret == -EINPROGRESS) qemu_laio_completion_cb(laiocb->ctx); Can you verify this by single-stepping one or two loop iterations? ret and errno after the read call could be interesting, too. We'll be stuck in an endless loop if the request doesn't complete, which might well happen in your scenario. Not sure what the right thing to do is. We probably need to fail the bdrv_aio_cancel to avoid blocking the whole program, but I have no idea what device emulations should do on that condition. As long as we can't handle that condition correctly, leaving the hang in place is probably the best option. Maybe add some sleep to avoid 100% CPU consumption. Kevin -- 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
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
Alexander Graf wrote: Peter Lieven wrote: we are running on intel xeons here: That might be the reason. Does it break when passing -no-kvm? processor: 0 vendor_id: GenuineIntel cpu family: 6 model: 26 model name: Intel(R) Xeon(R) CPU L5530 @ 2.40GHz stepping: 5 cpu MHz: 2394.403 cache size: 8192 KB physical id: 1 siblings: 4 core id: 0 cpu cores: 4 apicid: 16 initial apicid: 16 fpu: yes fpu_exception: yes cpuid level: 11 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology tsc_reliable nonstop_tsc pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid bogomips: 4788.80 clflush size: 64 cache_alignment: 64 address sizes: 40 bits physical, 48 bits virtual power management: kvm-kmod is 2.6.32.7 ... which commandline parameters do you supply to qemu-kvm? None :) It seems to stop working if i supply -no-kvm-irqchip. Can you try to reproduce this? We introduced that parameter because we encountered some problems with the e1000 kernel driver stopped to work in some guests after live migration with a "nobody cared about interupt" (i don't know the exact error anymore). supplying -no-kvm-irqchip made live migration of these guests possible... Sounds that familiar to someone? Peter which kernel parameters do you use for the sles 10 guest? Just the default. I took the SP1 DVD, installed it and booted it up. All is fine: $ ./x86_64-softmmu/qemu-system-x86_64 -snapshot /media/studio/images/SUSE/sles10/sles10sp1.x86_64.raw -vnc :10 Running on Intel might be the culprit though. I'll try and check if booting the image on an Intel box works. Alex -- 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
Re: [PATCH RFC] virtio_blk: Use blk-iopoll for host->guest notify
On Tue, May 18 2010, Stefan Hajnoczi wrote: > On Fri, May 14, 2010 at 05:30:56PM -0500, Brian Jackson wrote: > > Any preliminary numbers? latency, throughput, cpu use? What about comparing > > different "weights"? > > I am running benchmarks and will report results when they are in. I'm very interested as well, I have been hoping for some more adoption of this. I have mptsas and mpt2sas patches pending as well. I have not done enough and fully exhaustive weight analysis, so note me down for wanting such an analysis on virtio_blk as well. -- Jens Axboe -- 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
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
Peter Lieven wrote: > we are running on intel xeons here: That might be the reason. Does it break when passing -no-kvm? > > processor: 0 > vendor_id: GenuineIntel > cpu family: 6 > model: 26 > model name: Intel(R) Xeon(R) CPU L5530 @ 2.40GHz > stepping: 5 > cpu MHz: 2394.403 > cache size: 8192 KB > physical id: 1 > siblings: 4 > core id: 0 > cpu cores: 4 > apicid: 16 > initial apicid: 16 > fpu: yes > fpu_exception: yes > cpuid level: 11 > wp: yes > flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge > mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe > syscall rdtscp lm constant_tsc arch_perfmon pebs bts rep_good > xtopology tsc_reliable nonstop_tsc pni dtes64 monitor ds_cpl vmx est > tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm tpr_shadow > vnmi flexpriority ept vpid > bogomips: 4788.80 > clflush size: 64 > cache_alignment: 64 > address sizes: 40 bits physical, 48 bits virtual > power management: > > kvm-kmod is 2.6.32.7 > ... > > which commandline parameters do you supply to qemu-kvm? None :) > > which kernel parameters do you use for the sles 10 guest? Just the default. I took the SP1 DVD, installed it and booted it up. All is fine: $ ./x86_64-softmmu/qemu-system-x86_64 -snapshot /media/studio/images/SUSE/sles10/sles10sp1.x86_64.raw -vnc :10 Running on Intel might be the culprit though. I'll try and check if booting the image on an Intel box works. Alex -- 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
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
Alexander Graf wrote: Peter, Peter Lieven wrote: hi alex, here is a backtrace of the sles 10 sp1 vm running on qemu-kvm 0.12.4. hanging at boot. Please do not top post! Seriously. One more time and I'll stop responding. I tried to reproduce this locally on an openSUSE 11.1 system using latest qemu-kvm.git/stable-0.12 which should basically be 0.12.4: $ /sbin/modinfo kvm-intel ... version:kvm-kmod-78.2.6.30.1-20.4 ... ag...@busu:~/git/qemu-kvm> cat /proc/cpuinfo processor: 0 vendor_id: AuthenticAMD cpu family: 16 model: 2 model name: AMD Phenom(tm) 9550 Quad-Core Processor stepping: 3 cpu MHz: 1100.000 cache size: 512 KB physical id: 0 siblings: 4 core id: 0 cpu cores: 4 apicid: 0 initial apicid: 0 fpu: yes fpu_exception: yes cpuid level: 5 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs bogomips: 4409.11 TLB size: 1024 4K pages clflush size: 64 cache_alignment: 64 address sizes: 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate The freshly installed sles10 sp1 image works just fine. we are running on intel xeons here: processor: 0 vendor_id: GenuineIntel cpu family: 6 model: 26 model name: Intel(R) Xeon(R) CPU L5530 @ 2.40GHz stepping: 5 cpu MHz: 2394.403 cache size: 8192 KB physical id: 1 siblings: 4 core id: 0 cpu cores: 4 apicid: 16 initial apicid: 16 fpu: yes fpu_exception: yes cpuid level: 11 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology tsc_reliable nonstop_tsc pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid bogomips: 4788.80 clflush size: 64 cache_alignment: 64 address sizes: 40 bits physical, 48 bits virtual power management: kvm-kmod is 2.6.32.7 ... which commandline parameters do you supply to qemu-kvm? which kernel parameters do you use for the sles 10 guest? -- 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
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
Peter, Peter Lieven wrote: > hi alex, > > here is a backtrace of the sles 10 sp1 vm running on qemu-kvm 0.12.4. > hanging at boot. Please do not top post! Seriously. One more time and I'll stop responding. I tried to reproduce this locally on an openSUSE 11.1 system using latest qemu-kvm.git/stable-0.12 which should basically be 0.12.4: $ /sbin/modinfo kvm-intel ... version:kvm-kmod-78.2.6.30.1-20.4 ... ag...@busu:~/git/qemu-kvm> cat /proc/cpuinfo processor: 0 vendor_id: AuthenticAMD cpu family: 16 model: 2 model name: AMD Phenom(tm) 9550 Quad-Core Processor stepping: 3 cpu MHz: 1100.000 cache size: 512 KB physical id: 0 siblings: 4 core id: 0 cpu cores: 4 apicid: 0 initial apicid: 0 fpu: yes fpu_exception: yes cpuid level: 5 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs bogomips: 4409.11 TLB size: 1024 4K pages clflush size: 64 cache_alignment: 64 address sizes: 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate The freshly installed sles10 sp1 image works just fine. -- 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
Re: [Qemu-devel] Qemu-KVM 0.12.3 and Multipath -> Assertion
Am 18.05.2010 13:13, schrieb Peter Lieven: > hi, > > will this patch make it into 0.12.4.1 ? > > br, > peter Anthony, can you please cherry-pick commit 38d8dfa1 into stable-0.12? Kevin > > Christoph Hellwig wrote: >> On Tue, May 04, 2010 at 04:01:35PM +0200, Kevin Wolf wrote: >> >>> Great, I'm going to submit it as a proper patch then. >>> >>> Christoph, by now I'm pretty sure it's right, but can you have another >>> look if this is correct, anyway? >>> >> >> It looks correct to me - we really shouldn't update the the fields >> until bdrv_aio_cancel has returned. In fact we cannot cancel a request >> more often than we can, so there's a fairly high chance it will >> complete. >> >> >> Reviewed-by: Christoph Hellwig -- 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
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
during my tests i also got the following error: Freeing initrd memory: 2860k freed not found! ..MP-BIOS bug: 8254 timer not connected to IO-APIC failed. timer doesn't work through the IO-APIC - disabling NMI Watchdog! -- 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
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
hi alex, here is a backtrace of the sles 10 sp1 vm running on qemu-kvm 0.12.4. hanging at boot. a colleguage is meanwhile upgraded a cloned system to sp3 to see if it is also not working. ^C Program received signal SIGINT, Interrupt. [Switching to Thread 0x7f0b753c76f0 (LWP 25532)] 0x7f0b73e13742 in select () from /lib/libc.so.6 (gdb) thread apply all bt Thread 5 (Thread 0x7f0b72115950 (LWP 25546)): #0 0x7f0b73e12cd7 in ioctl () from /lib/libc.so.6 #1 0x0042b945 in kvm_run (env=0x201cb10) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:921 #2 0x0042cea2 in kvm_cpu_exec (env=0x201cb10) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1651 #3 0x0042d62c in kvm_main_loop_cpu (env=0x201cb10) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1893 #4 0x0042d76d in ap_main_loop (_env=0x201cb10) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1943 #5 0x7f0b74d983ba in start_thread () from /lib/libpthread.so.0 #6 0x7f0b73e1afcd in clone () from /lib/libc.so.6 #7 0x in ?? () Thread 4 (Thread 0x7f0b72916950 (LWP 25545)): #0 0x7f0b73d69461 in sigtimedwait () from /lib/libc.so.6 #1 0x0042d1e5 in kvm_main_loop_wait (env=0x200ed90, timeout=1000) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1752 #2 0x0042d64a in kvm_main_loop_cpu (env=0x200ed90) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1896 #3 0x0042d76d in ap_main_loop (_env=0x200ed90) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1943 #4 0x7f0b74d983ba in start_thread () from /lib/libpthread.so.0 #5 0x7f0b73e1afcd in clone () from /lib/libc.so.6 #6 0x in ?? () Thread 3 (Thread 0x7f0b73117950 (LWP 25544)): #0 0x7f0b73d69461 in sigtimedwait () from /lib/libc.so.6 #1 0x0042d1e5 in kvm_main_loop_wait (env=0x2001010, timeout=1000) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1752 #2 0x0042d64a in kvm_main_loop_cpu (env=0x2001010) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1896 #3 0x0042d76d in ap_main_loop (_env=0x2001010) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1943 #4 0x7f0b74d983ba in start_thread () from /lib/libpthread.so.0 #5 0x7f0b73e1afcd in clone () from /lib/libc.so.6 #6 0x in ?? () Thread 2 (Thread 0x7f0b73918950 (LWP 25543)): #0 0x7f0b73d69461 in sigtimedwait () from /lib/libc.so.6 #1 0x0042d1e5 in kvm_main_loop_wait (env=0x1fe75b0, timeout=1000) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1752 #2 0x0042d64a in kvm_main_loop_cpu (env=0x1fe75b0) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1896 #3 0x0042d76d in ap_main_loop (_env=0x1fe75b0) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1943 #4 0x7f0b74d983ba in start_thread () from /lib/libpthread.so.0 #5 0x7f0b73e1afcd in clone () from /lib/libc.so.6 #6 0x in ?? () Thread 1 (Thread 0x7f0b753c76f0 (LWP 25532)): ---Type to continue, or q to quit--- #0 0x7f0b73e13742 in select () from /lib/libc.so.6 #1 0x0040c25a in main_loop_wait (timeout=1000) at /usr/src/qemu-kvm-0.12.4/vl.c:3994 #2 0x0042dcf1 in kvm_main_loop () at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:2126 #3 0x0040c98c in main_loop () at /usr/src/qemu-kvm-0.12.4/vl.c:4212 #4 0x0041054b in main (argc=43, argv=0x7fffcc0c3398, envp=0x7fffcc0c34f8) at /usr/src/qemu-kvm-0.12.4/vl.c:6252 Alexander Graf wrote: On 18.05.2010, at 13:08, Peter Lieven wrote: Alexander Graf wrote: On 18.05.2010, at 13:01, Peter Lieven wrote: hi alex, unfortunately -cpu host, -cpu qemu64, -cpu core2duo, -cpu kvm64 (which should be default) doesn't help all other cpus available are 32-bit afaik. as i said if i boot with with kernel parameter "nohpet", but acpi on the guest just hangs at 100% cpu. would a backtrace help? Sigh. Is there any way to upgrade the system to SP3? Preferably incl. the latest maintenance update? yes, we will try this. if you don't suspect it is a generall problem with qemu-kvm that should be fixed. keep you posted. Alright. Installing SLES10 SP1 in a VM in parallel. Alex -- Mit freundlichen Grüßen/Kind Regards Peter Lieven .. KAMP Netzwerkdienste GmbH Vestische Str. 89-91 | 46117 Oberhausen Tel: +49 (0) 208.89 402-50 | Fax: +49 (0) 208.89 402-40 mailto:p...@kamp.de | http://www.kamp.de Geschäftsführer: Heiner Lante | Michael Lante Amtsgericht Duisburg | HRB Nr. 12154 USt-Id-Nr.: DE 120607556 . -- 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
Re: virtio: imply disable_cb on callbacks
Rusty, the patch "virtio: imply disable_cb on callbacks" is on your tree. I'd like to figure out how it works: for example: diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c --- a/drivers/block/virtio_blk.c +++ b/drivers/block/virtio_blk.c @@ -69,6 +69,8 @@ static void blk_done(struct virtqueue *v /* In case queue is stopped waiting for more buffers. */ blk_start_queue(vblk->disk->queue); spin_unlock_irqrestore(&vblk->lock, flags); + + vq->vq_ops->enable_cb(vq); } static bool do_req(struct request_queue *q, struct virtio_blk *vblk, Since this does not check the return status from enable_cb, it seems we could loose an interrupt if it arrives between poll and callback enable? Same might apply to other devices. Thanks, -- MST -- 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
Re: [PATCHv2] vhost-net: utilize PUBLISH_USED_IDX feature
"Michael S. Tsirkin" wrote:
> With PUBLISH_USED_IDX, guest tells us which used entries
> it has consumed. This can be used to reduce the number
> of interrupts: after we write a used entry, if the guest has not yet
> consumed the previous entry, or if the guest has already consumed the
> new entry, we do not need to interrupt.
> This imporves bandwidth by 30% under some workflows.
>
> Signed-off-by: Michael S. Tsirkin
> ---
>
> This is on top of Rusty's tree and depends on the virtio patch.
>
> Changes from v1:
> fix build
Minor nit if you have to respin it:
> /* This actually signals the guest, using eventfd. */
> -void vhost_signal(struct vhost_dev *dev, struct vhost_virtqueue *vq)
> +static void vhost_signal(struct vhost_dev *dev, struct vhost_virtqueue *vq)
> {
> __u16 flags;
> + __u16 used;
local var named "used" here
> /* Flush out used index updates. This is paired
>* with the barrier that the Guest executes when enabling
>* interrupts. */
> @@ -1053,6 +1057,17 @@ void vhost_signal(struct vhost_dev *dev, struct
> vhost_virtqueue *vq)
>!vhost_has_feature(dev, VIRTIO_F_NOTIFY_ON_EMPTY)))
> return;
>
> + if (vhost_has_feature(dev, VIRTIO_RING_F_PUBLISH_USED)) {
> + __u16 used;
and a "more" local one also named "used" :)
I guess you want to remove the previous declaration, as var is only used
in this block.
> + if (get_user(used, vq->last_used)) {
> + vq_err(vq, "Failed to get last used idx");
> + return;
> + }
> +
> + if (used != (u16)(vq->last_used_idx - 1))
> + return;
> + }
> +
> /* Signal the Guest tell them we used something up. */
> if (vq->call_ctx)
> eventfd_signal(vq->call_ctx, 1);
Rest of patch looks ok, and as a bonus un-export two functions.
Later, Juan.
--
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
Re: [QEMU-KVM]: Megasas + TCM_Loop + SG_IO into Windows XP guests
On Tue, 2010-05-18 at 11:43 +0200, Hannes Reinecke wrote: > Nicholas A. Bellinger wrote: > > On Fri, 2010-05-14 at 02:42 -0700, Nicholas A. Bellinger wrote: > >> On Fri, 2010-05-14 at 09:22 +0200, Hannes Reinecke wrote: > >>> Nicholas A. Bellinger wrote: > Greetings Hannes and co, > > >> > >>> Let's see if I can find some time working on the megasas emulation. > >>> Maybe I find something. > >>> Last time I checked it was with a Windows7 build, but I didn't do > >>> any real tests there. Basically just checking if the system boots up :-) > >>> > >> Nothing fancy just yet. This is involving a normal NTFS filesystem > >> format on a small TCM/FILEIO LUN using scsi-generic and a userspace > >> FILEIO with scsi-disk. > >> > >> This involves the XP guest waiting until the very last READ_10 once the > >> format has completed (eg: all WRITE and VERIFY CDBs complete with GOOD > >> status AFAICT) before announcing that mkfs.ntfs failed without any > >> helpful exception message (due to missing metadata of some sort I would > >> assume..?) > >> > >> So perhaps dumping QEMU and TCM_Loop SCSI payloads to determine if any > >> correct blocks from megasas_handle_io() are actually making it out to > >> KVM host is going to be my next option. ;) > >> > > > > Greetings Hannes, > > > > So I spent some more time with XP guests this weekend, and I noticed two > > things immediately when using hw/lsi53c895a.c instead of hw/megasas.c > > with the same two TCM_Loop SAS LUNs via SG_IO from last week: > > > > 1) With lsi53c895a, XP guests are able to boot successfully w/ out the > > synchronous SG_IO hack that is currently required to get past the first > > 36-byte INQUIRY for megasas + XP SP2 > > > > 2) With lsi53c895a, XP is able to successfully create and mount a NTFS > > filesystem, reboot, and read blocks appear to be functioning properly. > > FYI I have not run any 'write known pattern then read-back and compare > > blocks' data integrity tests from with in the XP guests just yet, but I > > am confident that TCM scatterlist -> se_mem_t mapping is working as > > expected on the KVM Host. > > > > Futhermore, after formatting a 5 GB TCM/FILEIO LUN with lsi53c895a, and > > then rebooting with megasas with the same two configured TCM_Loop SG_IO > > devices, it appears to be able to mount and read blocks successfully. > > Attempting to write new blocks on the mounted filesystem also appears to > > work to some degree, but throughput slows down to a crawl during XP > > guest buffer cache flush, which is likely attributed to the use of my > > quick SYNC SG_IO hack. > > > > So it appears that there are two seperate issues here, and AFAICT they > > both look to be XP and megasas specific. For #2, it may be something > > about the format of the incoming scatterlists generated during XP's > > mkfs.ntfs that is causing some issues. While watching output during fs > > creation, I noticed the following WRITE_10s with a starting 4088 byte > > scatterlist and a trailing 8 byte scatterlist: > > > > megasas: writel mmio 40: 2b0b003 > > megasas: Found mapped frame 2 context 82b0b000 pa 2b0b000 > > megasas: Enqueue frame context 82b0b000 tail 493 busy 1 > > megasas: LD SCSI dev 2 lun 0 sdev 0xdc0230 xfer 16384 > > scsi-generic: Using cur_addr: 0x0ff6c008 cur_len: 0x0ff8 > > scsi-generic: Adding iovec for mem: 0x7f1783b96008 len: 0x0ff8 > > scsi-generic: Using cur_addr: 0x0fd6e000 cur_len: 0x1000 > > scsi-generic: Adding iovec for mem: 0x7f1783998000 len: 0x1000 > > scsi-generic: Using cur_addr: 0x0fe2f000 cur_len: 0x1000 > > scsi-generic: Adding iovec for mem: 0x7f1783a59000 len: 0x1000 > > scsi-generic: Using cur_addr: 0x0fdf cur_len: 0x1000 > > scsi-generic: Adding iovec for mem: 0x7f1783a1a000 len: 0x1000 > > scsi-generic: Using cur_addr: 0x0fded000 cur_len: 0x0008 > > scsi-generic: Adding iovec for mem: 0x7f1783a17000 len: 0x0008 > > scsi-generic: execute IOV: iovec_count: 5, dxferp: 0xd92420, dxfer_len: > > 16384 > > scsi-generic: ---> Issuing SG_IO CDB len 10: 0x2a 00 00 > > 00 fa be 00 00 20 00 > > scsi-generic: scsi_write_complete() ret = 0 > > scsi-generic: Command complete 0x0xd922c0 tag=0x82b0b000 status=0 > > megasas: LD SCSI req 0xd922c0 cmd 0xda92c0 lun 0xdc0230 finished with > > status 0 len 16384 > > megasas: Complete frame context 82b0b000 tail 493 busy 0 doorbell 0 > > > > Also, the final READ_10 that produces the 'could not create filesystem' > > exception is for LBA 63 and XP looking for the first FS blocks after > > GPT. > > > > Could there be some breakage in megasas with a length < PAGE_SIZE for > > the scatterlist..?As lsi53c895a seems to work OK for this case, is > > there something about the logic of parsing the incoming struct > > scatterlists that is different between the two HBA drivers..? AFAICT > > bot
Re: [Qemu-devel] Qemu-KVM 0.12.3 and Multipath -> Assertion
hi, will this patch make it into 0.12.4.1 ? br, peter Christoph Hellwig wrote: On Tue, May 04, 2010 at 04:01:35PM +0200, Kevin Wolf wrote: Great, I'm going to submit it as a proper patch then. Christoph, by now I'm pretty sure it's right, but can you have another look if this is correct, anyway? It looks correct to me - we really shouldn't update the the fields until bdrv_aio_cancel has returned. In fact we cannot cancel a request more often than we can, so there's a fairly high chance it will complete. Reviewed-by: Christoph Hellwig -- Mit freundlichen Grüßen/Kind Regards Peter Lieven .. KAMP Netzwerkdienste GmbH Vestische Str. 89-91 | 46117 Oberhausen Tel: +49 (0) 208.89 402-50 | Fax: +49 (0) 208.89 402-40 mailto:p...@kamp.de | http://www.kamp.de Geschäftsführer: Heiner Lante | Michael Lante Amtsgericht Duisburg | HRB Nr. 12154 USt-Id-Nr.: DE 120607556 . -- 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
Re: qemu-kvm hangs if multipath device is queing
hi kevin, here is the backtrace of (hopefully) all threads: ^C Program received signal SIGINT, Interrupt. [Switching to Thread 0x7f39b72656f0 (LWP 10695)] 0x7f39b6c3ea94 in __lll_lock_wait () from /lib/libpthread.so.0 (gdb) thread apply all bt Thread 2 (Thread 0x7f39b57b8950 (LWP 10698)): #0 0x7f39b6c3eedb in read () from /lib/libpthread.so.0 #1 0x0049e723 in qemu_laio_completion_cb (opaque=0x22b4010) at linux-aio.c:125 #2 0x0049e8ad in laio_cancel (blockacb=0x22ba310) at linux-aio.c:184 #3 0x0049a309 in bdrv_aio_cancel (acb=0x22ba310) at block.c:1800 #4 0x00587a52 in dma_aio_cancel (acb=0x22ba170) at /usr/src/qemu-kvm-0.12.4/dma-helpers.c:138 #5 0x0049a309 in bdrv_aio_cancel (acb=0x22ba170) at block.c:1800 #6 0x00444aac in ide_dma_cancel (bm=0x2800fd8) at /usr/src/qemu-kvm-0.12.4/hw/ide/core.c:2834 #7 0x00445001 in bmdma_cmd_writeb (opaque=0x2800fd8, addr=49152, val=8) at /usr/src/qemu-kvm-0.12.4/hw/ide/pci.c:44 #8 0x004c85f0 in ioport_write (index=0, address=49152, data=8) at ioport.c:80 #9 0x004c8977 in cpu_outb (addr=49152, val=8 '\b') at ioport.c:198 #10 0x00429731 in kvm_handle_io (port=49152, data=0x7f39b7263000, direction=1, size=1, count=1) at /usr/src/qemu-kvm-0.12.4/kvm-all.c:535 #11 0x0042bb8b in kvm_run (env=0x22ba5d0) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:968 #12 0x0042cea2 in kvm_cpu_exec (env=0x22ba5d0) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1651 #13 0x0042d62c in kvm_main_loop_cpu (env=0x22ba5d0) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1893 #14 0x0042d76d in ap_main_loop (_env=0x22ba5d0) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1943 #15 0x7f39b6c383ba in start_thread () from /lib/libpthread.so.0 #16 0x7f39b5cbafcd in clone () from /lib/libc.so.6 #17 0x in ?? () Thread 1 (Thread 0x7f39b72656f0 (LWP 10695)): #0 0x7f39b6c3ea94 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x7f39b6c3a190 in _L_lock_102 () from /lib/libpthread.so.0 #2 0x7f39b6c39a7e in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x0042e739 in kvm_mutex_lock () at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:2524 #4 0x0042e76e in qemu_mutex_lock_iothread () at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:2537 #5 0x0040c262 in main_loop_wait (timeout=1000) at /usr/src/qemu-kvm-0.12.4/vl.c:3995 #6 0x0042dcf1 in kvm_main_loop () at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:2126 #7 0x0040c98c in main_loop () at /usr/src/qemu-kvm-0.12.4/vl.c:4212 #8 0x0041054b in main (argc=30, argv=0x7fff019f1ca8, envp=0x7fff019f1da0) at /usr/src/qemu-kvm-0.12.4/vl.c:6252 -- 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
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
On 18.05.2010, at 13:08, Peter Lieven wrote: > Alexander Graf wrote: >> On 18.05.2010, at 13:01, Peter Lieven wrote: >> >> >>> hi alex, >>> >>> unfortunately -cpu host, -cpu qemu64, -cpu core2duo, -cpu kvm64 (which >>> should be default) doesn't help >>> all other cpus available are 32-bit afaik. >>> >>> as i said if i boot with with kernel parameter "nohpet", but acpi on the >>> guest just hangs at 100% cpu. >>> >>> would a backtrace help? >>> >> >> Sigh. Is there any way to upgrade the system to SP3? Preferably incl. the >> latest maintenance update? >> > yes, we will try this. if you don't suspect it is a generall problem with > qemu-kvm that should > be fixed. keep you posted. Alright. Installing SLES10 SP1 in a VM in parallel. Alex -- 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
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
Alexander Graf wrote: On 18.05.2010, at 13:01, Peter Lieven wrote: hi alex, unfortunately -cpu host, -cpu qemu64, -cpu core2duo, -cpu kvm64 (which should be default) doesn't help all other cpus available are 32-bit afaik. as i said if i boot with with kernel parameter "nohpet", but acpi on the guest just hangs at 100% cpu. would a backtrace help? Sigh. Is there any way to upgrade the system to SP3? Preferably incl. the latest maintenance update? yes, we will try this. if you don't suspect it is a generall problem with qemu-kvm that should be fixed. keep you posted. thanks for you help, peter Alex -- Mit freundlichen Grüßen/Kind Regards Peter Lieven .. KAMP Netzwerkdienste GmbH Vestische Str. 89-91 | 46117 Oberhausen Tel: +49 (0) 208.89 402-50 | Fax: +49 (0) 208.89 402-40 mailto:p...@kamp.de | http://www.kamp.de Geschäftsführer: Heiner Lante | Michael Lante Amtsgericht Duisburg | HRB Nr. 12154 USt-Id-Nr.: DE 120607556 . -- 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
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
On 18.05.2010, at 13:01, Peter Lieven wrote: > hi alex, > > unfortunately -cpu host, -cpu qemu64, -cpu core2duo, -cpu kvm64 (which should > be default) doesn't help > all other cpus available are 32-bit afaik. > > as i said if i boot with with kernel parameter "nohpet", but acpi on the > guest just hangs at 100% cpu. > > would a backtrace help? Sigh. Is there any way to upgrade the system to SP3? Preferably incl. the latest maintenance update? Alex -- 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
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
hi alex, unfortunately -cpu host, -cpu qemu64, -cpu core2duo, -cpu kvm64 (which should be default) doesn't help all other cpus available are 32-bit afaik. as i said if i boot with with kernel parameter "nohpet", but acpi on the guest just hangs at 100% cpu. would a backtrace help? br, peter Alexander Graf wrote: On 18.05.2010, at 12:12, Peter Lieven wrote: hi alex, what 64-bit -cpu types do you suggest? For starters I'd say try -cpu host. Alex -- Mit freundlichen Grüßen/Kind Regards Peter Lieven .. KAMP Netzwerkdienste GmbH Vestische Str. 89-91 | 46117 Oberhausen Tel: +49 (0) 208.89 402-50 | Fax: +49 (0) 208.89 402-40 mailto:p...@kamp.de | http://www.kamp.de Geschäftsführer: Heiner Lante | Michael Lante Amtsgericht Duisburg | HRB Nr. 12154 USt-Id-Nr.: DE 120607556 . -- 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
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
On 18.05.2010, at 12:12, Peter Lieven wrote: > hi alex, > > what 64-bit -cpu types do you suggest? For starters I'd say try -cpu host. Alex -- 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
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
Hi Peter, On 18.05.2010, at 12:18, Peter Lieven wrote: > Sorry, ommitted your questions. This particular system > is still runnung on Please don't top post. > > /kernel: /2.6.31-14-server, /bin: /qemu-kvm-0.12.2, /mod: /kvm-kmod-2.6.32.7 This looks reasonable. Alex -- 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
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
Sorry, ommitted your questions. This particular system
is still runnung on
/kernel: /2.6.31-14-server, /bin: /qemu-kvm-0.12.2, /mod: /kvm-kmod-2.6.32.7
If there where any fixes improvements I can try on:
/kernel: /2.6.33.3, /bin: /qemu-kvm-0.12.4, /mod: /2.6.33.3
BR,
Peter
Alexander Graf wrote:
On 18.05.2010, at 11:57, Peter Lieven wrote:
Alexander Graf wrote:
On 18.05.2010, at 11:14, Peter Lieven wrote:
Hi,
we try to migrate some Suse Linux Enterprise 10 64-bit guests from abandoned
Virtual Iron by Iron Port to qemu-kvm 0.12.4. Unfortunately the guests are not
very stable by now. With ACPI they end up in a kernel panic at boot time and
without
they occasionally hang during boot or shortly after.
Could you please post the panics you get? What does hang during boot mean?
with acpi=off it hangs after starting powersaved
The easiest way to get them is probably to start the guest with -serial stdio and pass
"console=ttyS0" on the grub command line.
without acpi=off it hangs always with a lookup. one time it happened directly
after initializing hpet0.
btw, is it safe to turn of hpet for linux guests in genereal?
regarding missing kvm-clock. i made the experience that some guests crash after
live migration
with clocksource=kvm_clock while they don't with clocksource=acpi_pm. this is
off topic here,
but its also something i would like to debug with someone.
Starting cupsddone
Starting ZENworks Management Daemon done
IA-32 Microcode Update Driver v1.14 unregistered
Starting INET services. (xinetd) done
Checking/updating CPU microcode done
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
IPv6 over IPv4 tunneling driver
..dead
Try to get initial date and time via NTP from 212.110.100.1 done
Starting network time protocol daemon (NTPD) done
Starting Name Service Cache Daemondone
NetBackup SAN Client Fibre Transport daemon started.
Starting powersaved: done
Starting mail service (Postfix)
NMI Watchdog detected LOCKUP on CPU 0
What host kernel are you running on? Or rather, what host kvm module version?
CPU 0
Modules linked in: ipv6 button battery ac apparmor aamatch_pcre loop usbhid
dm_mod 8139cp mii uhci_hcd e1000 i2c_piix4 usbcore ide_cd i2c_core cdrom
parport_pc lp parport ext3 jbd sg sym53c8xx scsi_transport_spi edd fan thermal
processor piix sd_mod scsi_mod ide_disk ide_core
Pid: 3134, comm: powersaved Not tainted 2.6.16.46-0.12-smp #1
This looks old. The SP3 GM version is 2.6.16.60-0.54.5. This release is
definitely out of support :(.
After some searching I found the RPM. That's the SLES10 SP1 GM kernel version.
I don't think anyone ever tested that one on kvm.
RIP: 0010:[] {paranoid_restore+81}
Yeah, great. That one's not helpful at all:
0x802dabf1 : iretq
RSP: :8041afd8 EFLAGS: 00010086
RAX: 88021d50 RBX: 88021e18 RCX: b4c562b6
RDX: 01f7 RSI: 88021e18 RDI: 01f7
RBP: R08: 04e2 R09: 80417d60
R10: 001f R11: 8800752c R12: 88021d00
R13: 04e2 R14: 80417dac R15: 0040
FS: 2ae1d26ee760() GS:803be000() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 00555b30 CR3: 000210fe9000 CR4: 06e0
Process powersaved (pid: 3134, threadinfo 810210ff2000, task
810211f83850)
Stack: 802dabf1 0010 00010086 8041afd8
Call Trace: {paranoid_restore+81}
{paranoid_restore+81}
Code: 48 cf 65 48 8b 0c 25 10 00 00 00 48 81 e9 d8 1f 00 00 8b 59
console shuts up ...
<0>Kernel panic - not syncing: Aiee, killing interrupt handler!
Please try out different values for -cpu. I think powersaved gets confused by
the invalid CPU type we're emulating.
Alex
--
Mit freundlichen Grüßen/Kind Regards
Peter Lieven
..
KAMP Netzwerkdienste GmbH
Vestische Str. 89-91 | 46117 Oberhausen
Tel: +49 (0) 208.89 402-50 | Fax: +49 (0) 208.89 402-40
mailto:p...@kamp.de | http://www.kamp.de
Geschäftsführer: Heiner Lante | Michael Lante
Amtsgericht Duisburg | HRB Nr. 12154
USt-Id-Nr.: DE 120607556
.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
hi alex,
what 64-bit -cpu types do you suggest?
when i boot the kernel with "nohpet" it simply hangs shortly after
powersaved...
br,
peter
Alexander Graf wrote:
On 18.05.2010, at 11:57, Peter Lieven wrote:
Alexander Graf wrote:
On 18.05.2010, at 11:14, Peter Lieven wrote:
Hi,
we try to migrate some Suse Linux Enterprise 10 64-bit guests from abandoned
Virtual Iron by Iron Port to qemu-kvm 0.12.4. Unfortunately the guests are not
very stable by now. With ACPI they end up in a kernel panic at boot time and
without
they occasionally hang during boot or shortly after.
Could you please post the panics you get? What does hang during boot mean?
with acpi=off it hangs after starting powersaved
The easiest way to get them is probably to start the guest with -serial stdio and pass
"console=ttyS0" on the grub command line.
without acpi=off it hangs always with a lookup. one time it happened directly
after initializing hpet0.
btw, is it safe to turn of hpet for linux guests in genereal?
regarding missing kvm-clock. i made the experience that some guests crash after
live migration
with clocksource=kvm_clock while they don't with clocksource=acpi_pm. this is
off topic here,
but its also something i would like to debug with someone.
Starting cupsddone
Starting ZENworks Management Daemon done
IA-32 Microcode Update Driver v1.14 unregistered
Starting INET services. (xinetd) done
Checking/updating CPU microcode done
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
IPv6 over IPv4 tunneling driver
..dead
Try to get initial date and time via NTP from 212.110.100.1 done
Starting network time protocol daemon (NTPD) done
Starting Name Service Cache Daemondone
NetBackup SAN Client Fibre Transport daemon started.
Starting powersaved: done
Starting mail service (Postfix)
NMI Watchdog detected LOCKUP on CPU 0
What host kernel are you running on? Or rather, what host kvm module version?
CPU 0
Modules linked in: ipv6 button battery ac apparmor aamatch_pcre loop usbhid
dm_mod 8139cp mii uhci_hcd e1000 i2c_piix4 usbcore ide_cd i2c_core cdrom
parport_pc lp parport ext3 jbd sg sym53c8xx scsi_transport_spi edd fan thermal
processor piix sd_mod scsi_mod ide_disk ide_core
Pid: 3134, comm: powersaved Not tainted 2.6.16.46-0.12-smp #1
This looks old. The SP3 GM version is 2.6.16.60-0.54.5. This release is
definitely out of support :(.
After some searching I found the RPM. That's the SLES10 SP1 GM kernel version.
I don't think anyone ever tested that one on kvm.
RIP: 0010:[] {paranoid_restore+81}
Yeah, great. That one's not helpful at all:
0x802dabf1 : iretq
RSP: :8041afd8 EFLAGS: 00010086
RAX: 88021d50 RBX: 88021e18 RCX: b4c562b6
RDX: 01f7 RSI: 88021e18 RDI: 01f7
RBP: R08: 04e2 R09: 80417d60
R10: 001f R11: 8800752c R12: 88021d00
R13: 04e2 R14: 80417dac R15: 0040
FS: 2ae1d26ee760() GS:803be000() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 00555b30 CR3: 000210fe9000 CR4: 06e0
Process powersaved (pid: 3134, threadinfo 810210ff2000, task
810211f83850)
Stack: 802dabf1 0010 00010086 8041afd8
Call Trace: {paranoid_restore+81}
{paranoid_restore+81}
Code: 48 cf 65 48 8b 0c 25 10 00 00 00 48 81 e9 d8 1f 00 00 8b 59
console shuts up ...
<0>Kernel panic - not syncing: Aiee, killing interrupt handler!
Please try out different values for -cpu. I think powersaved gets confused by
the invalid CPU type we're emulating.
Alex
--
Mit freundlichen Grüßen/Kind Regards
Peter Lieven
..
KAMP Netzwerkdienste GmbH
Vestische Str. 89-91 | 46117 Oberhausen
Tel: +49 (0) 208.89 402-50 | Fax: +49 (0) 208.89 402-40
mailto:p...@kamp.de | http://www.kamp.de
Geschäftsführer: Heiner Lante | Michael Lante
Amtsgericht Duisburg | HRB Nr. 12154
USt-Id-Nr.: DE 120607556
.
--
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
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
On 18.05.2010, at 11:57, Peter Lieven wrote:
> Alexander Graf wrote:
>> On 18.05.2010, at 11:14, Peter Lieven wrote:
>>
>>
>>> Hi,
>>>
>>> we try to migrate some Suse Linux Enterprise 10 64-bit guests from abandoned
>>> Virtual Iron by Iron Port to qemu-kvm 0.12.4. Unfortunately the guests are
>>> not
>>> very stable by now. With ACPI they end up in a kernel panic at boot time
>>> and without
>>> they occasionally hang during boot or shortly after.
>>>
>>
>> Could you please post the panics you get? What does hang during boot mean?
>>
> with acpi=off it hangs after starting powersaved
>> The easiest way to get them is probably to start the guest with -serial
>> stdio and pass "console=ttyS0" on the grub command line.
>>
>>
> without acpi=off it hangs always with a lookup. one time it happened directly
> after initializing hpet0.
> btw, is it safe to turn of hpet for linux guests in genereal?
>
> regarding missing kvm-clock. i made the experience that some guests crash
> after live migration
> with clocksource=kvm_clock while they don't with clocksource=acpi_pm. this is
> off topic here,
> but its also something i would like to debug with someone.
>
>
> Starting cupsddone
> Starting ZENworks Management Daemon done
> IA-32 Microcode Update Driver v1.14 unregistered
> Starting INET services. (xinetd) done
> Checking/updating CPU microcode done
> NET: Registered protocol family 10
> lo: Disabled Privacy Extensions
> IPv6 over IPv4 tunneling driver
> ..dead
> Try to get initial date and time via NTP from 212.110.100.1 done
> Starting network time protocol daemon (NTPD) done
> Starting Name Service Cache Daemondone
> NetBackup SAN Client Fibre Transport daemon started.
> Starting powersaved: done
> Starting mail service (Postfix)
> NMI Watchdog detected LOCKUP on CPU 0
What host kernel are you running on? Or rather, what host kvm module version?
> CPU 0
> Modules linked in: ipv6 button battery ac apparmor aamatch_pcre loop usbhid
> dm_mod 8139cp mii uhci_hcd e1000 i2c_piix4 usbcore ide_cd i2c_core cdrom
> parport_pc lp parport ext3 jbd sg sym53c8xx scsi_transport_spi edd fan
> thermal processor piix sd_mod scsi_mod ide_disk ide_core
> Pid: 3134, comm: powersaved Not tainted 2.6.16.46-0.12-smp #1
This looks old. The SP3 GM version is 2.6.16.60-0.54.5. This release is
definitely out of support :(.
After some searching I found the RPM. That's the SLES10 SP1 GM kernel version.
I don't think anyone ever tested that one on kvm.
> RIP: 0010:[] {paranoid_restore+81}
Yeah, great. That one's not helpful at all:
0x802dabf1 : iretq
> RSP: :8041afd8 EFLAGS: 00010086
> RAX: 88021d50 RBX: 88021e18 RCX: b4c562b6
> RDX: 01f7 RSI: 88021e18 RDI: 01f7
> RBP: R08: 04e2 R09: 80417d60
> R10: 001f R11: 8800752c R12: 88021d00
> R13: 04e2 R14: 80417dac R15: 0040
> FS: 2ae1d26ee760() GS:803be000() knlGS:
> CS: 0010 DS: ES: CR0: 8005003b
> CR2: 00555b30 CR3: 000210fe9000 CR4: 06e0
> Process powersaved (pid: 3134, threadinfo 810210ff2000, task
> 810211f83850)
> Stack: 802dabf1 0010 00010086 8041afd8
>
>
> Call Trace: {paranoid_restore+81}
> {paranoid_restore+81}
>
> Code: 48 cf 65 48 8b 0c 25 10 00 00 00 48 81 e9 d8 1f 00 00 8b 59
> console shuts up ...
> <0>Kernel panic - not syncing: Aiee, killing interrupt handler!
Please try out different values for -cpu. I think powersaved gets confused by
the invalid CPU type we're emulating.
Alex
--
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
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
Alexander Graf wrote:
On 18.05.2010, at 11:14, Peter Lieven wrote:
Hi,
we try to migrate some Suse Linux Enterprise 10 64-bit guests from abandoned
Virtual Iron by Iron Port to qemu-kvm 0.12.4. Unfortunately the guests are not
very stable by now. With ACPI they end up in a kernel panic at boot time and
without
they occasionally hang during boot or shortly after.
Could you please post the panics you get? What does hang during boot mean?
with acpi=off it hangs after starting powersaved
The easiest way to get them is probably to start the guest with -serial stdio and pass
"console=ttyS0" on the grub command line.
without acpi=off it hangs always with a lookup. one time it happened
directly after initializing hpet0.
btw, is it safe to turn of hpet for linux guests in genereal?
regarding missing kvm-clock. i made the experience that some guests
crash after live migration
with clocksource=kvm_clock while they don't with clocksource=acpi_pm.
this is off topic here,
but its also something i would like to debug with someone.
Starting cupsddone
Starting ZENworks Management Daemon done
IA-32 Microcode Update Driver v1.14 unregistered
Starting INET services. (xinetd) done
Checking/updating CPU microcode done
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
IPv6 over IPv4 tunneling driver
..dead
Try to get initial date and time via NTP from 212.110.100.1 done
Starting network time protocol daemon (NTPD) done
Starting Name Service Cache Daemondone
NetBackup SAN Client Fibre Transport daemon started.
Starting powersaved: done
Starting mail service (Postfix)
NMI Watchdog detected LOCKUP on CPU 0
CPU 0
Modules linked in: ipv6 button battery ac apparmor aamatch_pcre loop
usbhid dm_mod 8139cp mii uhci_hcd e1000 i2c_piix4 usbcore ide_cd
i2c_core cdrom parport_pc lp parport ext3 jbd sg sym53c8xx
scsi_transport_spi edd fan thermal processor piix sd_mod scsi_mod
ide_disk ide_core
Pid: 3134, comm: powersaved Not tainted 2.6.16.46-0.12-smp #1
RIP: 0010:[] {paranoid_restore+81}
RSP: :8041afd8 EFLAGS: 00010086
RAX: 88021d50 RBX: 88021e18 RCX: b4c562b6
RDX: 01f7 RSI: 88021e18 RDI: 01f7
RBP: R08: 04e2 R09: 80417d60
R10: 001f R11: 8800752c R12: 88021d00
R13: 04e2 R14: 80417dac R15: 0040
FS: 2ae1d26ee760() GS:803be000() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 00555b30 CR3: 000210fe9000 CR4: 06e0
Process powersaved (pid: 3134, threadinfo 810210ff2000, task
810211f83850)
Stack: 802dabf1 0010 00010086 8041afd8
Call Trace: {paranoid_restore+81}
{paranoid_restore+81}
Code: 48 cf 65 48 8b 0c 25 10 00 00 00 48 81 e9 d8 1f 00 00 8b 59
console shuts up ...
<0>Kernel panic - not syncing: Aiee, killing interrupt handler!
Has anyone experience with suitable kvm and/or kernel parameters to get
this stable?
It should be reasonably stable already. The only issue I'm aware of is the
missing kvm-clock, so don't expect your timekeeping inside the guest to be 100%
sane.
Alex
--
Mit freundlichen Grüßen/Kind Regards
Peter Lieven
..
KAMP Netzwerkdienste GmbH
Vestische Str. 89-91 | 46117 Oberhausen
Tel: +49 (0) 208.89 402-50 | Fax: +49 (0) 208.89 402-40
mailto:p...@kamp.de | http://www.kamp.de
Geschäftsführer: Heiner Lante | Michael Lante
Amtsgericht Duisburg | HRB Nr. 12154
USt-Id-Nr.: DE 120607556
.
--
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
Re: [QEMU-KVM]: Megasas + TCM_Loop + SG_IO into Windows XP guests
Nicholas A. Bellinger wrote: > On Fri, 2010-05-14 at 02:42 -0700, Nicholas A. Bellinger wrote: >> On Fri, 2010-05-14 at 09:22 +0200, Hannes Reinecke wrote: >>> Nicholas A. Bellinger wrote: Greetings Hannes and co, >> >>> Let's see if I can find some time working on the megasas emulation. >>> Maybe I find something. >>> Last time I checked it was with a Windows7 build, but I didn't do >>> any real tests there. Basically just checking if the system boots up :-) >>> >> Nothing fancy just yet. This is involving a normal NTFS filesystem >> format on a small TCM/FILEIO LUN using scsi-generic and a userspace >> FILEIO with scsi-disk. >> >> This involves the XP guest waiting until the very last READ_10 once the >> format has completed (eg: all WRITE and VERIFY CDBs complete with GOOD >> status AFAICT) before announcing that mkfs.ntfs failed without any >> helpful exception message (due to missing metadata of some sort I would >> assume..?) >> >> So perhaps dumping QEMU and TCM_Loop SCSI payloads to determine if any >> correct blocks from megasas_handle_io() are actually making it out to >> KVM host is going to be my next option. ;) >> > > Greetings Hannes, > > So I spent some more time with XP guests this weekend, and I noticed two > things immediately when using hw/lsi53c895a.c instead of hw/megasas.c > with the same two TCM_Loop SAS LUNs via SG_IO from last week: > > 1) With lsi53c895a, XP guests are able to boot successfully w/ out the > synchronous SG_IO hack that is currently required to get past the first > 36-byte INQUIRY for megasas + XP SP2 > > 2) With lsi53c895a, XP is able to successfully create and mount a NTFS > filesystem, reboot, and read blocks appear to be functioning properly. > FYI I have not run any 'write known pattern then read-back and compare > blocks' data integrity tests from with in the XP guests just yet, but I > am confident that TCM scatterlist -> se_mem_t mapping is working as > expected on the KVM Host. > > Futhermore, after formatting a 5 GB TCM/FILEIO LUN with lsi53c895a, and > then rebooting with megasas with the same two configured TCM_Loop SG_IO > devices, it appears to be able to mount and read blocks successfully. > Attempting to write new blocks on the mounted filesystem also appears to > work to some degree, but throughput slows down to a crawl during XP > guest buffer cache flush, which is likely attributed to the use of my > quick SYNC SG_IO hack. > > So it appears that there are two seperate issues here, and AFAICT they > both look to be XP and megasas specific. For #2, it may be something > about the format of the incoming scatterlists generated during XP's > mkfs.ntfs that is causing some issues. While watching output during fs > creation, I noticed the following WRITE_10s with a starting 4088 byte > scatterlist and a trailing 8 byte scatterlist: > > megasas: writel mmio 40: 2b0b003 > megasas: Found mapped frame 2 context 82b0b000 pa 2b0b000 > megasas: Enqueue frame context 82b0b000 tail 493 busy 1 > megasas: LD SCSI dev 2 lun 0 sdev 0xdc0230 xfer 16384 > scsi-generic: Using cur_addr: 0x0ff6c008 cur_len: 0x0ff8 > scsi-generic: Adding iovec for mem: 0x7f1783b96008 len: 0x0ff8 > scsi-generic: Using cur_addr: 0x0fd6e000 cur_len: 0x1000 > scsi-generic: Adding iovec for mem: 0x7f1783998000 len: 0x1000 > scsi-generic: Using cur_addr: 0x0fe2f000 cur_len: 0x1000 > scsi-generic: Adding iovec for mem: 0x7f1783a59000 len: 0x1000 > scsi-generic: Using cur_addr: 0x0fdf cur_len: 0x1000 > scsi-generic: Adding iovec for mem: 0x7f1783a1a000 len: 0x1000 > scsi-generic: Using cur_addr: 0x0fded000 cur_len: 0x0008 > scsi-generic: Adding iovec for mem: 0x7f1783a17000 len: 0x0008 > scsi-generic: execute IOV: iovec_count: 5, dxferp: 0xd92420, dxfer_len: 16384 > scsi-generic: ---> Issuing SG_IO CDB len 10: 0x2a 00 00 > 00 fa be 00 00 20 00 > scsi-generic: scsi_write_complete() ret = 0 > scsi-generic: Command complete 0x0xd922c0 tag=0x82b0b000 status=0 > megasas: LD SCSI req 0xd922c0 cmd 0xda92c0 lun 0xdc0230 finished with status > 0 len 16384 > megasas: Complete frame context 82b0b000 tail 493 busy 0 doorbell 0 > > Also, the final READ_10 that produces the 'could not create filesystem' > exception is for LBA 63 and XP looking for the first FS blocks after > GPT. > > Could there be some breakage in megasas with a length < PAGE_SIZE for > the scatterlist..?As lsi53c895a seems to work OK for this case, is > there something about the logic of parsing the incoming struct > scatterlists that is different between the two HBA drivers..? AFAICT > both are using Gerd's common code in hw/scsi-bus.c, unless there is > something about megasas_map_sgl() that is causing issues with the > above..? > The usual disclaimer here: I'm less than happy with the current SCSI disk handling. Currently we
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
On 18.05.2010, at 11:14, Peter Lieven wrote: > Hi, > > we try to migrate some Suse Linux Enterprise 10 64-bit guests from abandoned > Virtual Iron by Iron Port to qemu-kvm 0.12.4. Unfortunately the guests are not > very stable by now. With ACPI they end up in a kernel panic at boot time and > without > they occasionally hang during boot or shortly after. Could you please post the panics you get? What does hang during boot mean? The easiest way to get them is probably to start the guest with -serial stdio and pass "console=ttyS0" on the grub command line. > Has anyone experience with suitable kvm and/or kernel parameters to get > this stable? It should be reasonably stable already. The only issue I'm aware of is the missing kvm-clock, so don't expect your timekeeping inside the guest to be 100% sane. Alex -- 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
Suggested Parameters for SLES 10 64-bit
Hi, we try to migrate some Suse Linux Enterprise 10 64-bit guests from abandoned Virtual Iron by Iron Port to qemu-kvm 0.12.4. Unfortunately the guests are not very stable by now. With ACPI they end up in a kernel panic at boot time and without they occasionally hang during boot or shortly after. Has anyone experience with suitable kvm and/or kernel parameters to get this stable? Thanks, Peter -- 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
Re: [PATCH] KVM: powerpc: fix init/exit annotation
On 18.05.2010, at 09:34, Jean Delvare wrote: > kvmppc_e500_exit() is a module_exit function, so it should be tagged > with __exit, not __init. The incorrect annotation was added by commit > 2986b8c72c272ea58edd37903b042c6da985627d. > > Signed-off-by: Jean Delvare > Cc: Stephen Rothwell > Cc: Avi Kivity > Cc: sta...@kernel.org Good catch! Signed-off-by: Alexander Graf Alex -- 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
Re: [PATCH RFC] virtio_blk: Use blk-iopoll for host->guest notify
On Fri, May 14, 2010 at 05:30:56PM -0500, Brian Jackson wrote: > Any preliminary numbers? latency, throughput, cpu use? What about comparing > different "weights"? I am running benchmarks and will report results when they are in. Stefan -- 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
Re: KVM on RHEL5.5
Hi all， thanks very much， it works after cold boot! tianjing On Fri, May 14, 2010 at 8:59 PM, Amos Kong wrote: > On Fri, May 14, 2010 at 4:33 PM, Alexander Graf wrote: >> On 14.05.2010, at 10:10, TianJing wrote: >>> Hi all, >>> >>> i am trying to install kvm on RHEL5.5, the server is power leader >>> S5000VSA, the CPU is intel E5335, and i check that it support vm. >>> when i run the commamd: modprobe kvm_intel >>> i got the following error message:FATAL: Error inserting kvm_intel >>> (/lib/modules/2.6.26.5-45.fc9.x86_64/extra/kvm-intel.ko): Operation >>> not supported >>> and also i find in the /var/log/dmesg: kvm: disables by bios. >>> so i turn on the VT in the bios,and reboot the server. >>> but again i got the some error,but nothing in the /var/log/dmesg. >>> >>> any ideas? >> >> After enabling VT in the bios you need to power cycle the machine. A simple >> reboot doesn't help. > > Yes, I also touched this problem. problem was resolved after cold boot. > -- 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
