similar to: Re: Multi Queue KVM Support

Hello experts, I tried upgrading libvirt and compiled version 1.1.1 The problem is that when I run "virsh version" I get the following output: Compiled against library: libvirt 1.1.1 Using library: libvirt 1.1.1 Using API: QEMU 1.1.1 Running hypervisor: QEMU 0.12.1 The problem is that it reports that the Running hypervisor is: QEMU 0.12.1 I wanted to upgrade everything to the latest

Il 20/08/2013 12:42, Timon Wang ha scritto: > [root@localhost /]# ls -l /dev/VM-IMAGES-BACKUP-DO-NOT-REMOVE/q_disk > lrwxrwxrwx. 1 root root 8 8月 20 17:38 > /dev/VM-IMAGES-BACKUP-DO-NOT-REMOVE/q_disk -> ../dm-13 > [root@localhost /]# sg_inq /dev/VM-IMAGES-BACKUP-DO-NOT-REMOVE/q_disk > standard INQUIRY: > PQual=0 Device_type=0 RMB=0 version=0x05 [SPC-3] > [AERC=0]

On Tue, Aug 20, 2013 at 4:33 PM, Paolo Bonzini <pbonzini@redhat.com> wrote: > Il 20/08/2013 08:00, Timon Wang ha scritto: >> <disk type='file' device='disk'> >> <driver name='qemu' type='raw' cache='none'/> >> <source file='/home/images/win2008_2_sys'/> >> <target

Thanks, the whole iSCSI LUN have been passed to the VM. But I test it with scsicmd, and found that the driver may be not support SPC-3, but if i use this by microsoft iscsi initiator, I can pass all the scsi3_test tests. Tool can be found here: http://www.symantec.com/business/support/index?page=content&id=TECH72086 It's this means that the scsi passthrough windows driver does not

Il 20/08/2013 08:00, Timon Wang ha scritto: > <disk type='file' device='disk'> > <driver name='qemu' type='raw' cache='none'/> > <source file='/home/images/win2008_2_sys'/> > <target dev='hda' bus='ide'/> > <boot order='3'/> > <address

[root@localhost /]# ls -l /dev/VM-IMAGES-BACKUP-DO-NOT-REMOVE/q_disk lrwxrwxrwx. 1 root root 8 8月 20 17:38 /dev/VM-IMAGES-BACKUP-DO-NOT-REMOVE/q_disk -> ../dm-13 [root@localhost /]# sg_inq /dev/VM-IMAGES-BACKUP-DO-NOT-REMOVE/q_disk standard INQUIRY: PQual=0 Device_type=0 RMB=0 version=0x05 [SPC-3] [AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=0 SCCS=1 ACC=0 TPGS=1

Il 19/03/2014 21:14, Waiman Long ha scritto: > This patch adds a KVM init function to activate the unfair queue > spinlock in a KVM guest when the PARAVIRT_UNFAIR_LOCKS kernel config > option is selected. > > Signed-off-by: Waiman Long <Waiman.Long at hp.com> > --- > arch/x86/kernel/kvm.c | 17 +++++++++++++++++ > 1 files changed, 17 insertions(+), 0 deletions(-)

Il 19/03/2014 21:14, Waiman Long ha scritto: > This patch adds a KVM init function to activate the unfair queue > spinlock in a KVM guest when the PARAVIRT_UNFAIR_LOCKS kernel config > option is selected. > > Signed-off-by: Waiman Long <Waiman.Long at hp.com> > --- > arch/x86/kernel/kvm.c | 17 +++++++++++++++++ > 1 files changed, 17 insertions(+), 0 deletions(-)

On Tue, Jun 17, 2014 at 11:53 PM, Paolo Bonzini <pbonzini at redhat.com> wrote: > Il 17/06/2014 17:50, Ming Lei ha scritto: > >>> > It would be nice to allocate virtqueues dynamically instead of >>> > hardcoding the limit. virtio-scsi also allocates virtqueues >>> > dynamically. >> >> virtio-scsi may have lots of LUN, but virtio-blk only

On Wed, Jun 18, 2014 at 12:34 AM, Paolo Bonzini <pbonzini at redhat.com> wrote: > Il 17/06/2014 18:00, Ming Lei ha scritto: > >>> > If you want to do queue steering based on the guest VCPU number, the >>> > number >>> > of queues must be = to the number of VCPUs shouldn't it? >>> > >>> > I tried using a divisor of the

Il 20/08/2013 11:59, Timon Wang ha scritto: > On Tue, Aug 20, 2013 at 4:33 PM, Paolo Bonzini <pbonzini@redhat.com> wrote: >> Il 20/08/2013 08:00, Timon Wang ha scritto: >>> <disk type='file' device='disk'> >>> <driver name='qemu' type='raw' cache='none'/> >>> <source

On 03/14/2014 04:42 AM, Paolo Bonzini wrote: > Il 13/03/2014 20:13, Waiman Long ha scritto: >>>> >>> >>> This should also disable the unfair path. >>> >>> Paolo >>> >> >> The unfair lock uses a different jump label and does not require any >> special PV ops. There is a separate init function for that. > > Yeah,

Il 26/02/2014 16:14, Waiman Long ha scritto: > This patch adds a KVM init function to activate the unfair queue > spinlock in a KVM guest when the PARAVIRT_UNFAIR_LOCKS kernel config > option is selected. > > Signed-off-by: Waiman Long <Waiman.Long at hp.com> > --- > arch/x86/kernel/kvm.c | 17 +++++++++++++++++ > 1 files changed, 17 insertions(+), 0 deletions(-)

Il 26/02/2014 16:14, Waiman Long ha scritto: > This patch adds a KVM init function to activate the unfair queue > spinlock in a KVM guest when the PARAVIRT_UNFAIR_LOCKS kernel config > option is selected. > > Signed-off-by: Waiman Long <Waiman.Long at hp.com> > --- > arch/x86/kernel/kvm.c | 17 +++++++++++++++++ > 1 files changed, 17 insertions(+), 0 deletions(-)

On 06/03/2014 08:48 AM, Paolo Bonzini wrote: > Il 02/06/2014 23:58, Eric Dumazet ha scritto: >> This looks dubious >> >> What about using kfree_rcu() instead ? > > It would lead to unbound allocation from userspace. > >> translate_desc() still uses rcu_read_lock(), its not clear if the mutex >> is really held. > > Yes, vhost_get_vq_desc must be

On 06/03/2014 08:48 AM, Paolo Bonzini wrote: > Il 02/06/2014 23:58, Eric Dumazet ha scritto: >> This looks dubious >> >> What about using kfree_rcu() instead ? > > It would lead to unbound allocation from userspace. > >> translate_desc() still uses rcu_read_lock(), its not clear if the mutex >> is really held. > > Yes, vhost_get_vq_desc must be

On 03/13/2014 09:59 AM, Paolo Bonzini wrote: > Il 12/03/2014 19:54, Waiman Long ha scritto: >> @@ -807,8 +889,13 @@ void __init kvm_spinlock_init(void) >> if (!kvm_para_has_feature(KVM_FEATURE_PV_UNHALT)) >> return; >> >> +#ifdef CONFIG_QUEUE_SPINLOCK >> + pv_lock_ops.kick_cpu = kvm_kick_cpu_type; >> + pv_lock_ops.hibernate =

I don't know if lsisas1078 controller in qemu is not work property or I did not configure it correct. Sometimes I can see the lun which passed to the vm, sometimes not. I have tried that controller before, and sometimes the vm will crash because qemu process quit, but I did not get the detail logs about the process quit. I am wondering if lsisas1078 is still not stable or I did not config it

On 03/20/2014 03:01 PM, Paolo Bonzini wrote: > > No! Please do what I asked you to do. You are not handling Hyper-V or > VMWare. Just use X86_FEATURE_HYPERVISOR and it will cover all > hypervisors that actually follow Intel's guidelines. > And for those that don't, we should turn on X86_FEATURE_HYPERVISOR in the Linux enumeration code as we do for other features we

On Thu, Aug 28, 2014 at 12:46 PM, Paolo Bonzini <pbonzini at redhat.com> wrote: > Il 28/08/2014 18:22, Andy Lutomirski ha scritto: >> Is there a non-cpuid interface between QEMU and KVM for this? > > No. Hmm. Then, assuming that someone manages to allocate a cross-hypervisor MSR number for this, what am I supposed to do in the KVM code? Just make it available