Re: VIA Eden X4

"Matwey V. Kornilov" writes: > Hello, > > According to WikiPedia VIA claims x86 hardware assisted virtualization > for VIA Eden X4 CPU. > Does anybody know if it is supported by Linux KVM? > I can't say for sure but my guess is that it should work since VIA implements

Re: x86: Don't report guest userspace emulation error to userspace, why ?

Paolo Bonzini <pbonz...@redhat.com> writes: > On 10/12/2015 18:58, Bandan Das wrote: >>> > Allowing userspace to stop the guest with an emulation failure is a >> This one I don't :) Userspace started the guest after all, there are other >> ways for it to kill the

Re: x86: Don't report guest userspace emulation error to userspace, why ?

Paolo Bonzini <pbonz...@redhat.com> writes: >> Paolo Bonzini <pbonz...@redhat.com> writes: >> > On 10/12/2015 18:58, Bandan Das wrote: >> >>> > Allowing userspace to stop the guest with an emulation failure is a >> >> This one I don't

Re: x86: Don't report guest userspace emulation error to userspace, why ?

Paolo Bonzini <pbonz...@redhat.com> writes: > On 09/12/2015 23:18, Bandan Das wrote: >> Commit a2b9e6c1a35afcc09: >> >> KVM: x86: Don't report guest userspace emulation error to userspace >> >> Commit fc3a9157d314 ("KVM: X86: Don't repor

x86: Don't report guest userspace emulation error to userspace, why ?

Commit a2b9e6c1a35afcc09: KVM: x86: Don't report guest userspace emulation error to userspace Commit fc3a9157d314 ("KVM: X86: Don't report L2 emulation failures to user-space") disabled the reporting of L2 (nested guest) emulation failures to userspace due to race-condition

Re: [PATCH] KVM: nVMX: remove incorrect vpid check in nested invvpid emulation

Haozhong Zhang <haozhong.zh...@intel.com> writes: > On 11/25/15 10:45, Bandan Das wrote: >> Haozhong Zhang <haozhong.zh...@intel.com> writes: >> >> > This patch removes the vpid check when emulating nested invvpid >> > instruction of type

Re: [PATCH] KVM: nVMX: remove incorrect vpid check in nested invvpid emulation

Haozhong Zhang writes: > This patch removes the vpid check when emulating nested invvpid > instruction of type all-contexts invalidation. The existing code is > incorrect because: > (1) According to Intel SDM Vol 3, Section "INVVPID - Invalidate > Translations

Re: [PATCH] Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS

Joerg Roedel <j...@8bytes.org> writes: > On Tue, Oct 06, 2015 at 01:59:27PM -0400, Bandan Das wrote: >> Joerg Roedel <j...@8bytes.org> writes: >> > >> > So svm->vmcb->control.next_rip is only written by hardware or in >> > svm_

Re: [PATCH] kvm: svm: Only propagate next_rip when guest supports it

Joerg Roedel writes: > On Wed, Oct 07, 2015 at 01:03:35PM +0200, Joerg Roedel wrote: >> But we don't care if L1 writes something into its own next_rip, as we >> never read this value from its VMCB. We only copy the next_rip value we >> get from our shadow-vmcb to it on an

Re: [PATCH] Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS

Joerg Roedel <j...@8bytes.org> writes: > On Thu, Oct 01, 2015 at 06:31:27PM -0400, Bandan Das wrote: >> >> @@ -514,7 +514,7 @@ static void skip_emulated_instruction(struct kvm_vcpu >> >> *vcpu) >> >> struct vcpu_svm *svm = to_svm(vcpu); >>

Re: [PATCH] Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS

Joerg Roedel <j...@8bytes.org> writes: > On Mon, Oct 05, 2015 at 01:42:43PM -0400, Bandan Das wrote: >> Joerg Roedel <j...@8bytes.org> writes: >> >> > On Mon, Oct 05, 2015 at 12:54:43PM -0400, Bandan Das wrote: >> >> Joerg Roedel <j...@8bytes.o

Re: [PATCH] Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS

Joerg Roedel <j...@8bytes.org> writes: > On Mon, Oct 05, 2015 at 12:54:43PM -0400, Bandan Das wrote: >> Joerg Roedel <j...@8bytes.org> writes: >> The problems is that the next_rip field could be stale. If the processor >> supports >> next_rip, then

Re: [PATCH] Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS

Dirk Müller writes: >> So the right fix would be to just set the guests next_rip to 0 when we >> emulate vmrun, just like real hardware does, no? > > Like this? (Note: I’m not sure what I’m doing here..). I Agree with you that > the warning > for this seems excessive, I’ve

Re: [PATCH] Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS

Joerg Roedel <j...@8bytes.org> writes: > On Thu, Oct 01, 2015 at 06:31:27PM -0400, Bandan Das wrote: >> Paolo Bonzini <pbonz...@redhat.com> writes: >> >> > On 01/10/2015 13:43, Dirk Müller wrote: >> >> diff --git a/arch/x86/kvm/svm.c b/arch/x

Re: [PATCH] Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS

Dirk Müller writes: >> I added the warning so that we catch if the next_rip field is being written >> to (even if the feature isn't supported) by a buggy L1 hypervisor. > > Interesting, so how about this patch? > > > From c5c8ea255d680f972cbdfc835cdf352fa78897ae Mon Sep 17

Re: [PATCH] Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS

Paolo Bonzini writes: > On 01/10/2015 13:43, Dirk Müller wrote: >> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c >> index 94b7d15..0a42859 100644 >> --- a/arch/x86/kvm/svm.c >> +++ b/arch/x86/kvm/svm.c >> @@ -514,7 +514,7 @@ static void

Re: [PATCH] KVM: nVMX: emulate the INVVPID instruction

Paolo Bonzini <pbonz...@redhat.com> writes: > On 24/09/2015 17:45, Bandan Das wrote: >> > However, I have applied the patch to kvm/queue. Please send the changes >> > separately, and I will squash them in the existing VPID patch. >> >> Please don't d

Re: [PATCH] KVM: nVMX: emulate the INVVPID instruction

Paolo Bonzini writes: ... >> @@ -7189,7 +7189,28 @@ static int handle_invept(struct kvm_vcpu *vcpu) >> >> static int handle_invvpid(struct kvm_vcpu *vcpu) >> { >> -kvm_queue_exception(vcpu, UD_VECTOR); >> +u32 vmx_instruction_info; >> +unsigned long type; >> +

Re: [PATCH 1/2] KVM: introduce __vmx_flush_tlb to handle specific vpid

Wanpeng Li writes: > Introduce __vmx_flush_tlb() to handle specific vpid. > > Signed-off-by: Wanpeng Li > --- > arch/x86/kvm/vmx.c | 21 + > 1 file changed, 13 insertions(+), 8 deletions(-) > > diff --git a/arch/x86/kvm/vmx.c

Re: [PATCH] KVM: nVMX: nested VPID emulation

Wanpeng Li writes: > VPID is used to tag address space and avoid a TLB flush. Currently L0 use > the same VPID to run L1 and all its guests. KVM flushes VPID when switching > between L1 and L2. > > This patch advertises VPID to the L1 hypervisor, then address space of

Re: [RFC PATCH 4/5] KVM: x86: enable unhandled MSR exits for vmx

Peter Hornyack peterhorny...@google.com writes: Set the vm's unhandled_msr_exits flag when user space calls the KVM_ENABLE_CAP ioctl with KVM_CAP_UNHANDLED_MSR_EXITS. After kvm fails to handle a guest rdmsr or wrmsr, check this flag and exit to user space with KVM_EXIT_MSR rather than

Re: [RFC PATCH 3/5] KVM: x86: add msr_exits_supported to kvm_x86_ops

Peter Hornyack peterhorny...@google.com writes: msr_exits_supported will be checked when user space attempts to enable the KVM_CAP_UNHANDLED_MSR_EXITS capability for the vm. This is needed because MSR exit support will be implemented for vmx but not svm later in this patchset. Is svm future

Re: [RFC PATCH 0/5] KVM: x86: exit to user space on unhandled MSR accesses

Peter Hornyack peterhorny...@google.com writes: On Wed, Aug 19, 2015 at 2:43 PM, Bandan Das b...@redhat.com wrote: Peter Hornyack peterhorny...@google.com writes: There are numerous MSRs that kvm does not currently handle. On Intel platforms we have observed guest VMs accessing some

Re: [RFC PATCH 0/5] KVM: x86: exit to user space on unhandled MSR accesses

Peter Hornyack peterhorny...@google.com writes: There are numerous MSRs that kvm does not currently handle. On Intel platforms we have observed guest VMs accessing some of these MSRs (for example, MSR_PLATFORM_INFO) and behaving poorly (to the point of guest OS crashes) when they receive a GP

Re: One off question: Hot vertical scaling of a KVM?

ROZUMNY, VICTOR vr9...@att.com writes: Hello- Your site states that one off questions might could be answered via email so here I am. I have limited knowledge of KVM, but it is my understanding that in order to vertically scale RAM for a KVM the guest needs to be shut down, resized, and

Re: Debian 8

Mathieu Charrette mathieu.charre...@phoenixsolutions.ca writes: Hi, I'm trying to install KVM on the latest version of Debian (so Debian 8) and it's not working. It always gives me a dependencies error. But when I install it on Debian 7.8, it works no problem. I was wondering if you would

Re: [RFC PATCH 1/4] vhost: Introduce a universal thread to serve all users

Michael S. Tsirkin m...@redhat.com writes: On Mon, Jul 13, 2015 at 12:07:32AM -0400, Bandan Das wrote: vhost threads are per-device, but in most cases a single thread is enough. This change creates a single thread that is used to serve all guests. However, this complicates cgroups

Re: [RFC PATCH 1/4] vhost: Introduce a universal thread to serve all users

Bandan Das b...@redhat.com writes: Michael S. Tsirkin m...@redhat.com writes: On Mon, Jul 13, 2015 at 12:07:32AM -0400, Bandan Das wrote: vhost threads are per-device, but in most cases a single thread is enough. This change creates a single thread that is used to serve all guests

Re: [RFC PATCH 0/4] Shared vhost design

Michael S. Tsirkin m...@redhat.com writes: On Sat, Aug 08, 2015 at 07:06:38PM -0400, Bandan Das wrote: Hi Michael, ... - does the design address the issue of VM 1 being blocked (e.g. because it hits swap) and blocking VM 2? Good question. I haven't thought of this yet. But IIUC

Re: [RFC PATCH 1/4] vhost: Introduce a universal thread to serve all users

complicated, and there's a good chance that it's impossible to migrate the vhost thread since it's serving other guests. I will address this in v2. Eyal Moscovici HL-Cloud Infrastructure Solutions IBM Haifa Research Lab From: Bandan Das b...@redhat.com To: kvm@vger.kernel.org Cc: net

Re: [RFC PATCH 0/4] Shared vhost design

Hi Michael, Michael S. Tsirkin m...@redhat.com writes: On Mon, Jul 13, 2015 at 12:07:31AM -0400, Bandan Das wrote: Hello, There have been discussions on improving the current vhost design. The first attempt, to my knowledge was Shirley Ma's patch to create a dedicated vhost worker per

Re: [PATCH kvm-unit-tests] x86: fix last commit

, because only code segment descriptors differ between 32- and 64-bit mode. In fact the same is true for %ss as well, so let's just remove the whole segment loading from load_tss. Thanks to Bandan Das for debugging. Reported-by: Shih-Wei Li shih...@cs.columbia.edu Signed-off-by: Paolo Bonzini

Re: [RFC PATCH 0/4] Shared vhost design

Eyal Moscovici eya...@il.ibm.com writes: ... We can start to implement polling, but I am unsure if the cgroups integration will be sufficient. The polling vhost thread should be scheduled all the time and just moving it from one cgroup to the other wont be sufficient. I think it needs a

Re: [PATCH kvm-unit-tests] x86: fix last commit

Paolo Bonzini pbonz...@redhat.com writes: On 01/08/2015 21:05, Bandan Das wrote: Shih-Wei Li shih...@cs.columbia.edu writes: Hi Paolo, I've tried to apply the patch, and found that it passed most of the problematic tests I mentioned earlier (IPI related, kvmclock_test). However

Re: kvm-unit-test failed to complete

Shih-Wei Li shih...@cs.columbia.edu writes: On Wed, Jul 29, 2015 at 2:38 PM, Shih-Wei Li shih...@cs.columbia.edu wrote: On Wed, Jul 29, 2015 at 2:30 PM, Christoffer Dall cd...@cs.columbia.edu wrote: Hi Shih-Wei, [Something weird happened when sending these e-mails, you sent two where one

Re: [RFC PATCH 0/4] Shared vhost design

it makes sense to add polling on top of these patches and get numbers for them too. Thoughts ? Bandan Eyal Moscovici HL-Cloud Infrastructure Solutions IBM Haifa Research Lab From: Bandan Das b...@redhat.com To: kvm@vger.kernel.org Cc: net...@vger.kernel.org, linux-ker

Re: max number of VCPUs

Ozgur O Kilic okil...@binghamton.edu writes: Hi, I was trying to find out the max number of vpcus and what is the reason of having that. I found 2 number about it one is the recommend max by KVM which is 160 and the other number was 255. Can someone tell me what are the reasons of this

Re: [PATCH v3 01/10] KVM: MMU: fix decoding cache type from MTRR

Alex Williamson alex.william...@redhat.com writes: On Wed, 2015-05-13 at 14:42 +0800, Xiao Guangrong wrote: There are some bugs in current get_mtrr_type(); 1: bit 1 of mtrr_state-enabled is corresponding bit 11 of IA32_MTRR_DEF_TYPE MSR which completely control MTRR's enablement that

[RFC PATCH 2/4] vhost: Limit the number of devices served by a single worker thread

work. We still keep moving around the worker thread to the cgroups of the device we are serving at the moment. Signed-off-by: Razya Ladelsky ra...@il.ibm.com Signed-off-by: Bandan Das b...@redhat.com --- drivers/vhost/net.c | 6 +-- drivers/vhost/scsi.c | 3 +- drivers/vhost/vhost.c | 135

[RFC PATCH 1/4] vhost: Introduce a universal thread to serve all users

...@il.ibm.com Signed-off-by: Bandan Das b...@redhat.com --- drivers/vhost/scsi.c | 15 +++-- drivers/vhost/vhost.c | 150 -- drivers/vhost/vhost.h | 19 +-- 3 files changed, 97 insertions(+), 87 deletions(-) diff --git a/drivers/vhost/scsi.c b

[RFC PATCH 4/4] vhost: Add cgroup-aware creation of worker threads

the devs_per_worker threshold Signed-off-by: Bandan Das b...@redhat.com --- drivers/vhost/vhost.c | 47 +++ 1 file changed, 39 insertions(+), 8 deletions(-) diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index 6a5d4c0..dc0fa37 100644 --- a/drivers

[RFC PATCH 3/4] cgroup: Introduce a function to compare cgroups

workers. Signed-off-by: Bandan Das b...@redhat.com --- include/linux/cgroup.h | 1 + kernel/cgroup.c| 40 2 files changed, 41 insertions(+) diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h index b9cb94c..606fb5b 100644 --- a/include/linux

[RFC PATCH 0/4] Shared vhost design

model. Ccing cgroups for input/comments. Many thanks to Razya Ladelsky and Eyal Moscovici, IBM for the initial patches, the helpful testing suggestions and discussions. Bandan Das (4): vhost: Introduce a universal thread to serve all users vhost: Limit the number of devices served by a single

Re: [PATCH] KVM: x86: Add host physical address width capability

Laszlo Ersek ler...@redhat.com writes: On 07/10/15 16:59, Paolo Bonzini wrote: On 10/07/2015 16:57, Laszlo Ersek wrote: ... In any case, please understand that I'm not campaigning for this warning :) IIRC the warning was your (very welcome!) idea after I reported the problem; I'm just

Re: [PATCH] KVM: x86: Add host physical address width capability

Paolo Bonzini pbonz...@redhat.com writes: On 09/07/2015 08:43, Laszlo Ersek wrote: On 07/09/15 08:09, Paolo Bonzini wrote: On 09/07/2015 00:36, Bandan Das wrote: Let userspace inquire the maximum physical address width of the host processors; this can be used to identify maximum memory

Re: [Qemu-devel] [PATCH] target-i386: Sanity check host processor physical address width

Laszlo Ersek ler...@redhat.com writes: ... First, see my comments on the KVM patch. Second, ram_size is not the right thing to compare. What should be checked is whether the highest guest-physical address that maps to RAM can be represented in the address width of the host processor (and

Re: [PATCH] KVM: x86: Add host physical address width capability

Bandan Das b...@redhat.com writes: Laszlo Ersek ler...@redhat.com writes: ... Yes. Without EPT, you don't hit the processor limitation with your setup, but the user should nevertheless still be notified. I disagree. In fact, I think shadow paging code should also emulate

Re: [PATCH] target-i386: Sanity check host processor physical address width

Paolo Bonzini pbonz...@redhat.com writes: On 09/07/2015 10:26, Laszlo Ersek wrote: Perhaps KVM could simply hide memory above the limit (i.e. treat it as MMIO), and the BIOS could remove RAM above the limit from the e820 memory map? I'd prefer to leave the guest firmware*s* out of

Re: [PATCH] KVM: x86: Add host physical address width capability

Laszlo Ersek ler...@redhat.com writes: ... Yes. Without EPT, you don't hit the processor limitation with your setup, but the user should nevertheless still be notified. I disagree. In fact, I think shadow paging code should also emulate this behavior if the gpa is out of range. I

Re: [Qemu-devel] [PATCH] target-i386: Sanity check host processor physical address width

Igor Mammedov imamm...@redhat.com writes: On Wed, 08 Jul 2015 18:42:01 -0400 Bandan Das b...@redhat.com wrote: If a Linux guest is assigned more memory than is supported by the host processor, the guest is unable to boot. That is expected, however, there's no message indicating the user

[PATCH] KVM: x86: Add host physical address width capability

Let userspace inquire the maximum physical address width of the host processors; this can be used to identify maximum memory that can be assigned to the guest. Reported-by: Laszlo Ersek ler...@redhat.com Signed-off-by: Bandan Das b...@redhat.com --- arch/x86/kvm/x86.c | 3 +++ include

[PATCH] target-i386: Sanity check host processor physical address width

Ersek ler...@redhat.com Signed-off-by: Bandan Das b...@redhat.com --- linux-headers/linux/kvm.h | 1 + target-i386/kvm.c | 6 ++ 2 files changed, 7 insertions(+) diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h index 3bac873..6afad49 100644 --- a/linux-headers/linux

Re: [Bug 100671] New: vmwrite error in vmx_vcpu_run

bugzilla-dae...@bugzilla.kernel.org writes: Can you please provide a little bit more information ? When does the write error happen and what guest/host are you running ? If it's a regression, would it be possible for you to bisect it ? Is Bug 100661 related to the same hardware ? Bandan

Re: Hang on reboot in FreeBSD guest on Linux KVM host

Paolo Bonzini pbonz...@redhat.com writes: ... I did this: 1) download http://download.pcbsd.org/iso/10.1-RELEASE/amd64/PCBSD10.1.2-x64-trueos-server.raw.xz and unpack it 2) run it with qemu-kvm -drive if=virtio,PCBSD10.1.2-x64-trueos-server.raw -smp 2 3) login as root/pcbsd, type reboot

Re: Hang on reboot in FreeBSD guest on Linux KVM host

John Nielsen li...@jnielsen.net writes: On Jun 17, 2014, at 10:48 AM, John Nielsen li...@jnielsen.net wrote: On Jun 17, 2014, at 12:05 AM, Gleb Natapov g...@kernel.org wrote: On Tue, Jun 17, 2014 at 06:21:23AM +0200, Paolo Bonzini wrote: Il 16/06/2014 18:47, John Nielsen ha scritto: On

[PATCH] KVM: nSVM: Check for NRIPS support before updating control field

() doesn't verify nrip support before accepting control.next_rip as valid, avoid writing this field if support isn't present. Signed-off-by: Bandan Das b...@redhat.com --- arch/x86/kvm/svm.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/svm.c b/arch/x86

Re: [PATCH v2] [x86/kvm] emulate.c: Fix comppilation warning

Rajat Jain raja...@google.com writes: Fix the following warning: arch/x86/kvm/emulate.c: In function '__do_insn_fetch_bytes': arch/x86/kvm/emulate.c:814:47: warning: 'linear' may be used uninitialized in this function [-Wmaybe-uninitialized] arch/x86/kvm/emulate.c:793:16: note: 'linear'

Re: [PATCH] kvm: x86: default legacy PCI device assignment support to n

Paolo Bonzini pbonz...@redhat.com writes: VFIO has proved itself a much better option than KVM's built-in device assignment. It is mature, provides better isolation because it enforces ACS, and even the userspace code is being tested on a wider variety of hardware these days than the legacy

Re: [PATCH] kvm: x86: default legacy PCI device assignment support to n

Paolo Bonzini pbonz...@redhat.com writes: On 04/06/2015 16:31, Bandan Das wrote: VFIO has proved itself a much better option than KVM's built-in device assignment. It is mature, provides better isolation because it enforces ACS, and even the userspace code is being tested on a wider

Re: [Bug 98841] New: android emulator broken since d7a2a24 kernel commit

bugzilla-dae...@bugzilla.kernel.org writes: https://bugzilla.kernel.org/show_bug.cgi?id=98841 Bug ID: 98841 Summary: android emulator broken since d7a2a24 kernel commit Product: Virtualization Version: unspecified Kernel Version: 3.17

Re: [PATCH 1/2] KVM: MMU: fix SMAP virtualization

Boris Ostrovsky boris.ostrov...@oracle.com writes: On 05/11/2015 10:55 AM, Xiao Guangrong wrote: KVM may turn a user page to a kernel page when kernel writes a readonly user page if CR0.WP = 1. This shadow page entry will be reused after SMAP is enabled so that kernel is allowed to access

Re: APIC_ID in apic_reg_write()

Jan Kiszka jan.kis...@siemens.com writes: ... Setting r/w permissions on a per-model is little overkill, don't you think ? If we want accurate behaviour, we should do this. If not, we probably better leave the code alone to avoid surprises for preexisting host/guest setups. Modern OSes do

Re: [PATCH] KVM: nVMX: Don't return error on nested bitmap memory allocation failure

Jan Kiszka jan.kis...@siemens.com writes: Am 2015-04-28 um 21:55 schrieb Bandan Das: If get_free_page() fails for nested bitmap area, it's evident that we are gonna get screwed anyway but returning failure because we failed allocating memory for a nested structure seems like an unnecessary

[PATCH RESEND kvm-unit-tests] x86/run: Rearrange the valid binary and testdev support checks

This extends the sanity checks done on known common Qemu binary paths when the user supplies a QEMU= on the command line Fixes: b895b967db94937d5b593c51b95eb32d2889a764 Signed-off-by: Bandan Das b...@redhat.com --- x86/run | 43 +++ 1 file changed, 19

[PATCH] KVM: nVMX: Don't return error on nested bitmap memory allocation failure

allocations. Signed-off-by: Bandan Das b...@redhat.com --- arch/x86/kvm/vmx.c | 29 +++-- 1 file changed, 15 insertions(+), 14 deletions(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index f7b6168..200bc5c 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c

Re: [PATCH kvm-unit-tests] x86/run: Rearrange the valid binary and testdev support checks

Ping, Paolo, did this slip through the cracks ? Bandan Das b...@redhat.com writes: This extends the sanity checks done on known common Qemu binary paths when the user supplies a QEMU= on the command line Fixes: b895b967db94937d5b593c51b95eb32d2889a764 Signed-off-by: Bandan Das b

Re: x2apic issues with Solaris and Xen guests

Michael Tokarev m...@tls.msk.ru writes: 20.04.2015 20:29, Jan Kiszka wrote: On 2015-04-20 19:07, Stefan Hajnoczi wrote: I wonder whether the following two x2apic issues are related: Solaris 10 U11 network doesn't work https://bugzilla.redhat.com/show_bug.cgi?id=1040500 kvm - fails to

Re: [PATCH] vt-x: Preserve host CR4.MCE value while in guest mode.

Ben Serebrin sereb...@google.com writes: I suggest changing the subject to KVM: VMX: Preserve host CR4.MCE value while in guest mode That keeps it consistent with the $SUBJECT naming convention KVM follows. If Paolo is ok with changing it in his tree directly, that's fine too. Bandan The

[PATCH] vhost: use kthread_run macro

Code Cleanup, kthread_run is a convenient wrapper around kthread_create() that even wakes up the process for us. Use it and remove no longer needed temp task_struct variable. Signed-off-by: Bandan Das b...@redhat.com --- drivers/vhost/vhost.c | 12 1 file changed, 4 insertions

Re: x86: Question regarding the reset value of LINT0

Nadav Amit nadav.a...@gmail.com writes: Avi Kivity avi.kiv...@gmail.com wrote: On 04/09/2015 09:21 PM, Nadav Amit wrote: Bandan Das b...@redhat.com wrote: Nadav Amit nadav.a...@gmail.com writes: Jan Kiszka jan.kis...@siemens.com wrote: On 2015-04-08 19:40, Nadav Amit wrote: Jan

Re: [PATCH] x86-run: Print a meaningful message if the qemu binary isn't found

Bandan Das b...@redhat.com writes: ... I think we still want to print this if the user supplied qemu has no test device support. I think this is better - --- a/x86/run +++ b/x86/run @@ -8,6 +8,7 @@ qemusystem=${QEMU:-qemu-system-x86_64} if ! [ -z ${QEMU} ] then qemu=${QEMU

Re: [PATCH] x86-run: Print a meaningful message if the qemu binary isn't found

Paolo Bonzini pbonz...@redhat.com writes: ... This breaks QEMU=... ./x86-run ./x86/msr.flat Fixed as follows: diff --git a/x86/run b/x86/run index d5adf8d..219a93b 100755 --- a/x86/run +++ b/x86/run @@ -20,16 +20,15 @@ else break fi done -fi -

Re: x86: Question regarding the reset value of LINT0

Nadav Amit nadav.a...@gmail.com writes: Jan Kiszka jan.kis...@siemens.com wrote: On 2015-04-08 19:40, Nadav Amit wrote: Jan Kiszka jan.kis...@siemens.com wrote: On 2015-04-08 18:59, Nadav Amit wrote: Jan Kiszka jan.kis...@siemens.com wrote: On 2015-04-08 18:40, Nadav Amit wrote: Hi,

Re: [PATCH v2 1/4] KVM: x86: INIT and reset sequences are different

Paolo Bonzini pbonz...@redhat.com writes: On 07/04/2015 18:17, Bandan Das wrote: I think a bool argument is good enough. QEMU has different functions, and init ends up doing save/reset/restore which is pretty ugly. Right, I meant that init could just be a wrapper so that it atleast shows

Re: [PATCH v2 1/4] KVM: x86: INIT and reset sequences are different

Paolo Bonzini pbonz...@redhat.com writes: On 02/04/2015 04:17, Bandan Das wrote: x86 architecture defines differences between the reset and INIT sequences. INIT does not initialize the FPU (including MMX, XMM, YMM, etc.), TSC, PMU, MSRs (in general), MTRRs machine-check, APIC ID, APIC

Re: [PATCH v2 1/4] KVM: x86: INIT and reset sequences are different

Nadav Amit na...@cs.technion.ac.il writes: x86 architecture defines differences between the reset and INIT sequences. INIT does not initialize the FPU (including MMX, XMM, YMM, etc.), TSC, PMU, MSRs (in general), MTRRs machine-check, APIC ID, APIC arbitration ID and BSP. EFER is supposed NOT

[PATCH] x86-run: Print a meaningful message if the qemu binary isn't found

Before: ./x86-run ./x86/msr.flat QEMU binary has no support for test device. Exiting. After: ./x86-run ./x86/msr.flat A QEMU binary was not found, You can set a custom location by using the QEMU=path environment variable Signed-off-by: Bandan Das b...@redhat.com --- x86/run | 37

Re: [Qemu-devel] E5-2620v2 - emulation stop error

Bandan Das b...@redhat.com writes: Andrey Korolyov and...@xdel.ru writes: ... http://xdel.ru/downloads/kvm-e5v2-issue/another-tracepoint-fail-with-apicv.dat.gz Something a bit more interesting, but the mess is happening just *after* NMI firing. What happens if NMI is turned off

Re: [Qemu-devel] E5-2620v2 - emulation stop error

Andrey Korolyov and...@xdel.ru writes: ... http://xdel.ru/downloads/kvm-e5v2-issue/another-tracepoint-fail-with-apicv.dat.gz Something a bit more interesting, but the mess is happening just *after* NMI firing. What happens if NMI is turned off on the host ? -- To unsubscribe from this list:

Re: Error upgrading vm from windows 8 to 8.1

coreys cor...@affinitygs.com writes: When I try to upgrade my guest windows 8 vm to window 8.1. I get the error of processor doesn't support CompareExchange128. Haven not been able to find any information about this error. I think that's because cmpxchg16b is not emulated yet: static int

Re: [Qemu-devel] E5-2620v2 - emulation stop error

Radim Krčmář rkrc...@redhat.com writes: 2015-03-26 21:24+0300, Andrey Korolyov: On Thu, Mar 26, 2015 at 8:40 PM, Radim Krčmář rkrc...@redhat.com wrote: 2015-03-26 20:08+0300, Andrey Korolyov: KVM internal error. Suberror: 2 extra data[0]: 80ef extra data[1]: 8b0d Btw. does

Re: [Qemu-devel] E5-2620v2 - emulation stop error

Hi Andrey, Andrey Korolyov and...@xdel.ru writes: On Mon, Mar 16, 2015 at 10:17 PM, Andrey Korolyov and...@xdel.ru wrote: For now, it looks like bug have a mixed Murphy-Heisenberg nature, as it appearance is very rare (compared to the number of actual launches) and most probably bounded to

Re: slow networking with VM virtio

[Ccing qemu-devel and kvm] Boylan, Ross ross.boy...@ucsf.edu writes: Running a Windows 7 VM under KVM, with virtio drivers, the networking was so slow as to be non-functional. As suggested in comment 11 of https://bugzilla.redhat.com/show_bug.cgi?id=855640, I did ethtool -K eth1 gro off

Re: [PATCH v2] KVM: nVMX: Add support for rdtscp

Jan Kiszka jan.kis...@web.de writes: ... --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -2467,6 +2467,7 @@ static void nested_vmx_setup_ctls_msrs(struct vcpu_vmx *vmx) vmx-nested.nested_vmx_secondary_ctls_low = 0; vmx-nested.nested_vmx_secondary_ctls_high =

Re: [PATCH v2] KVM: nVMX: Add support for rdtscp

Jan Kiszka jan.kis...@web.de writes: On 2015-03-23 18:01, Bandan Das wrote: Jan Kiszka jan.kis...@web.de writes: ... --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -2467,6 +2467,7 @@ static void nested_vmx_setup_ctls_msrs(struct vcpu_vmx *vmx) vmx

Re: [Qemu-devel] PCI passthrough of 40G ethernet interface (Openstack/KVM)

[Ccing netdev and Stefan] Bandan Das b...@redhat.com writes: jacob jacob opstk...@gmail.com writes: On Mon, Mar 16, 2015 at 2:12 PM, Bandan Das b...@redhat.com wrote: jacob jacob opstk...@gmail.com writes: I also see the following in dmesg in the VM. [0.095758] ACPI: PCI Root Bridge

Re: [PATCH] KVM: x86: call irq notifiers with directed EOI

Radim Krčmář rkrc...@redhat.com writes: kvm_ioapic_update_eoi() wasn't called if directed EOI was enabled. We need to do that for irq notifiers. (Like with edge interrupts.) Fix it by skipping EOI broadcast only. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=82211 Signed-off-by: Radim

Re: [PATCH] KVM: x86: call irq notifiers with directed EOI

Radim Krčmář rkrc...@redhat.com writes: kvm_ioapic_update_eoi() wasn't called if directed EOI was enabled. We need to do that for irq notifiers. (Like with edge interrupts.) Wow! It's interesting that this path is only hit with Xen as guest. I always thought of directed EOI as a security

Re: KVM emulation failure with recent kernel and QEMU Seabios

Gerd Hoffmann kra...@redhat.com writes: On Mo, 2015-03-16 at 14:16 -0400, Bandan Das wrote: Jan Kiszka jan.kis...@siemens.com writes: Am 2015-03-12 um 09:11 schrieb Gerd Hoffmann: On Do, 2015-03-12 at 09:09 +0100, Jan Kiszka wrote: Hi, apparently since the latest QEMU updates I'm

Re: [Qemu-devel] PCI passthrough of 40G ethernet interface (Openstack/KVM)

. This is the reason why i am suspecting if it is anything to do with KVM/libvirt. Both with regular PCI passthrough and VF passthrough i see issues. It is always pointing to some issue with packet transmission. Receive seems to work ok. On Thu, Mar 12, 2015 at 8:02 PM, Bandan Das b...@redhat.com

Re: KVM emulation failure with recent kernel and QEMU Seabios

Jan Kiszka jan.kis...@siemens.com writes: Am 2015-03-12 um 09:11 schrieb Gerd Hoffmann: On Do, 2015-03-12 at 09:09 +0100, Jan Kiszka wrote: Hi, apparently since the latest QEMU updates I'm getting this once in a while: http://www.seabios.org/pipermail/seabios/2015-March/008897.html

[PATCH] KVM: SVM: Fix confusing message if no exit handlers are installed

I hit this path on a AMD box and thought someone was playing a April Fool's joke on me. Signed-off-by: Bandan Das b...@redhat.com --- arch/x86/kvm/svm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c index cc618c8..4e77110 100644

Re: [Qemu-devel] PCI passthrough of 40G ethernet interface (Openstack/KVM)

jacob jacob opstk...@gmail.com writes: On Mon, Mar 16, 2015 at 2:12 PM, Bandan Das b...@redhat.com wrote: jacob jacob opstk...@gmail.com writes: I also see the following in dmesg in the VM. [0.095758] ACPI: PCI Root Bridge [PCI0] (domain [bus 00-ff]) [0.096006] acpi PNP0A03:00

Re: [PATCH] kvm: x86: svm: remove SVM_EXIT_READ_CR* intercepts

Joel Schopp joel.sch...@amd.com writes: There isn't really a valid reason for kvm to intercept cr* reads on svm hardware. The current kvm code just ends up returning the register Signed-off-by: Joel Schopp joel.sch...@amd.com --- arch/x86/kvm/svm.c | 41

Re: PCI passthrough of 40G ethernet interface (Openstack/KVM)

jacob jacob opstk...@gmail.com writes: Hi, Seeing failures when trying to do PCI passthrough of Intel XL710 40G interface to KVM vm. 0a:00.1 Ethernet controller: Intel Corporation Ethernet Controller XL710 for 40GbE QSFP+ (rev 01) You are assigning the PF right ? Does assigning VFs

Re: PCI passthrough of 40G ethernet interface (Openstack/KVM)

jacob jacob opstk...@gmail.com writes: On Thu, Mar 12, 2015 at 3:07 PM, Bandan Das b...@redhat.com wrote: jacob jacob opstk...@gmail.com writes: Hi, Seeing failures when trying to do PCI passthrough of Intel XL710 40G interface to KVM vm. 0a:00.1 Ethernet controller: Intel

Re: [Qemu-devel] E5-2620v2 - emulation stop error

Kevin O'Connor ke...@koconnor.net writes: ... Something is very odd here. When I run the above command (on an older AMD machine) I get: Found 128 cpu(s) max supported 128 cpu(s) That first value (1 vs 128) comes from QEMU (via cmos index 0x5f). That is, during smp init, SeaBIOS expects

Re: [Qemu-devel] E5-2620v2 - emulation stop error

Kevin O'Connor ke...@koconnor.net writes: On Wed, Mar 11, 2015 at 01:09:42PM -0400, Bandan Das wrote: Kevin O'Connor ke...@koconnor.net writes: ... Something is very odd here. When I run the above command (on an older AMD machine) I get: Found 128 cpu(s) max supported 128 cpu(s

Re: [Qemu-devel] E5-2620v2 - emulation stop error

Dr. David Alan Gilbert dgilb...@redhat.com writes: * Kevin O'Connor (ke...@koconnor.net) wrote: On Wed, Mar 11, 2015 at 02:45:31PM -0400, Kevin O'Connor wrote: On Wed, Mar 11, 2015 at 02:40:39PM -0400, Kevin O'Connor wrote: For what it's worth, I can't seem to trigger the problem if I move

Re: [Qemu-devel] E5-2620v2 - emulation stop error

Dr. David Alan Gilbert dgilb...@redhat.com writes: * Kevin O'Connor (ke...@koconnor.net) wrote: On Wed, Mar 11, 2015 at 04:52:03PM +, Dr. David Alan Gilbert wrote: * Kevin O'Connor (ke...@koconnor.net) wrote: So, I couldn't get this to fail on my older AMD machine at all with the

  1   2   3   >