On 2015-02-11 19:12, Kashyap Chamarthy wrote:
> Hi,
>
> This was tested with kernel-3.19.0-1.fc22) and QEMU (qemu-2.2.0-5.fc22)
> on L0 & L1.
>
>
> Description
> ---
>
> Inside L1, boot a nested KVM guest (L2) . Instead of a full blown
> guest, let's use `qemu-sanity-check` with KVM:
>
On 2015-02-10 14:14, Paolo Bonzini wrote:
> Signed-off-by: Paolo Bonzini
> ---
> external-module-compat-comm.h | 4
> external-module-compat.c | 8
> 2 files changed, 12 insertions(+)
>
> diff --git a/external-module-compat-comm.h b/external-module-compat-comm.h
> index d683c3
On 2015-02-10 17:18, Paolo Bonzini wrote:
> On 10/02/2015 17:15, Jan Kiszka wrote:
>>>> #define CR3_L_MODE_RESERVED_BITS 0xFF00ULL
>>>> +#define CR3_PCID_INVD (1UL << 63)
>> 1ULL (for i386)
>
> Already fixed:
>
> commi
On 2014-11-02 10:54, Nadav Amit wrote:
> Although Intel SDM mentions bit 63 is reserved, MOV to CR3 can have bit 63
> set.
> As Intel SDM states in section 4.10.4 "Invalidation of TLBs and
> Paging-Structure Caches": " MOV to CR3. ... If CR4.PCIDE = 1 and bit 63 of the
> instruction’s source opera
On 2015-01-28 16:43, Jan Kiszka wrote:
> On 2015-01-28 16:36, Alex Williamson wrote:
>> On Wed, 2015-01-28 at 16:02 +0100, Jan Kiszka wrote:
>>> Hi Alex,
>>>
>>> before getting dirty fingers in vain: what is the current status of
>>> handing an IGD GPU
On 2015-02-09 14:17, Paolo Bonzini wrote:
>
>
> On 06/02/2015 20:40, Jan Kiszka wrote:
>> On 2015-02-02 10:05, Paolo Bonzini wrote:
>>>
>>>
>>> On 02/02/2015 08:04, Jan Kiszka wrote:
>>>>>> +#if X86_FEATURE_XSAVEOPT < 10 * 32
>
Hi,
after fixing the VM_BUG_ON, my QEMU guest on the Jetson TK1 generally
refuses to boot. Once in a while it does, but quickly gets stuck again.
In one case I found this in the kernel log (never happened again so
far):
[ 762.022874] WARNING: CPU: 1 PID: 972 at
../arch/arm/kvm/../../../virt/kvm
From: Jan Kiszka
The check is supposed to catch page-unaligned sizes, not the inverse.
Signed-off-by: Jan Kiszka
---
That resolves the crash, but the guest still doesn't boot (it does when
removing -enable-kvm). Examining later.
arch/arm/include/asm/kvm_mmu.h | 2 +-
1 file chang
On 2015-02-07 21:26, Marc Zyngier wrote:
> On Sat, 7 Feb 2015 20:09:14 +
> Jan Kiszka wrote:
>
> Hi Jan,
>
>> Hi,
>>
>> using Ian Campbell's PSCI patches for U-Boot (ported to master, see
>> [1]), I managed to enable KVM on the Jetson TK1 board.
Hi,
using Ian Campbell's PSCI patches for U-Boot (ported to master, see
[1]), I managed to enable KVM on the Jetson TK1 board. Unfortunately,
I'm getting a crash on the host when starting QEMU:
[ 59.164674] kernel BUG at ../arch/arm/include/asm/kvm_mmu.h:189!
[ 59.173139] Internal error: Oops
On 2015-02-02 10:05, Paolo Bonzini wrote:
>
>
> On 02/02/2015 08:04, Jan Kiszka wrote:
>>>> +#if X86_FEATURE_XSAVEOPT < 10 * 32
>>>> +#undef X86_FEATURE_XSAVEOPT
>>>> +#endif
>>>> +#define X86_FEATURE_XSAVEOPT (10*32+0) /* XSAVEOP
On 2015-02-05 17:05, Paolo Bonzini wrote:
> This patch introduces a new module parameter for the KVM module; when it
> is present, KVM attempts a bit of polling on every HLT before scheduling
> itself out via kvm_vcpu_block.
Wouldn't it be better to tune this on a per-VM basis? Think of mixed
work
On 2015-01-08 11:32, Paolo Bonzini wrote:
> These are needed for KVM changes in 3.18.
>
> Recent kernels added a separate feature word for XSAVE features, and KVM's
> CPUID code is relying on the new definition. Except for cpu_has_xsaves,
> it's never accessing the feature itself: wrap cpu_has_xs
Hi Alex,
starting to play with Intel IGD pass-through in KVM, I managed to
trigger this with linux git head:
[ 232.317043] BUG: unable to handle kernel NULL pointer dereference at
0037
[ 232.325249] IP: [] dmar_insert_dev_info+0x86/0x220
[ 232.331905] PGD 0
[ 232.334007] Oops: 0
Hi Alex,
before getting dirty fingers in vain: what is the current status of
handing an IGD GPU to a KVM guest, specifically Windows? I found some
related QEMU patches from last year on the list, but it seems they
didn't progress. Are there open issues without known solutions or is it
"just" about
On 2015-01-28 16:36, Alex Williamson wrote:
> On Wed, 2015-01-28 at 16:02 +0100, Jan Kiszka wrote:
>> Hi Alex,
>>
>> before getting dirty fingers in vain: what is the current status of
>> handing an IGD GPU to a KVM guest, specifically Windows? I found some
>> re
On 2014-12-24 04:14, Wincy Van wrote:
> This patch fixes the bug discussed in
> https://www.mail-archive.com/kvm@vger.kernel.org/msg109813.html
>
> This patch uses a new field named irr_delivered to record the
> delivery status of edge-triggered interrupts, and clears the
> delivered interrupts in
On 2014-12-04 03:24, Jike Song wrote:
> Hi all,
>
> We are pleased to announce the first release of KVMGT project. KVMGT is
> the implementation of Intel GVT-g technology, a full GPU virtualization
> solution. Under Intel GVT-g, a virtual GPU instance is maintained for
> each VM, with part of per
On 2014-12-08 04:49, Wincy Van wrote:
+static bool vmx_msr_switch_area_verify(u32 count, u64 addr, int
maxphyaddr)
+{
+if (count == 0)
+return true;
+if ((addr & 0xf) != 0)
>>
>> Bits 11:0 have to be zero, in fact (page alignment required).
>
>
>
X_EPT_PAGE_WALK_4_BIT |
>VMX_EPTP_WB_BIT | VMX_EPT_2MB_PAGE_BIT |
>VMX_EPT_INVEPT_BIT;
>
Reviewed-by: Jan Kiszka
Jan
signature.asc
Description: OpenPGP digital signature
On 2014-12-07 10:46, Bandan Das wrote:
> [Ccing a few others who might be interested]
>
> Hi Eugene,
>
> Did you look at the other patch that was posted for this functionality
> by Wincy Van ?
>
> https://lkml.org/lkml/2014/11/21/749
It's good to see more momentum here, but, yes, we should defi
On 2014-11-27 14:30, Phil White wrote:
> This introduces a list of entries which associate a function pointer of
> kvm_hc_type to a hypercall number and allows the ability to register and
> unregister entries. In addition, it also allows the ability to retrieve a
> function pointer of kvm_hc_type
On 2014-11-25 18:38, Paolo Bonzini wrote:
>
>
> On 25/11/2014 18:21, Marcelo Tosatti wrote:
>> +
>> +if (r == HRTIMER_RESTART) {
>> +do {
>> +ret = hrtimer_start_expires(data, HRTIMER_MODE_ABS);
>> +if (ret == -ETIME)
>> +
On 2014-11-24 11:12, Paolo Bonzini wrote:
> On 24/11/2014 05:36, nick wrote:
>> Greetings Again Gleb and others,
>> I am assuming in the code I am pasting below the fix me is obsolete now and
>> I can remove it. :)
>> Cheers Nick
>> TP_printk("%s (0x%x)",
>> __print_symbolic(__en
On 2014-11-22 05:24, Wincy Van wrote:
> Some hypervisors need MSR auto load/restore feature.
>
> We read MSRs from vm-entry MSR load area which specified by L1,
> and load them via kvm_set_msr in the nested entry.
> When nested exit occurs, we get MSRs via kvm_get_msr, writting
> them to L1`s MSR
On 2014-11-17 10:03, Samuel Thibault wrote:
> Gleb Natapov, le Mon 17 Nov 2014 10:58:45 +0200, a écrit :
>> Do you know how gnumach timekeeping works? Does it have a timer that fires
>> each 1ms?
>> Which clock device is it using?
>
> It uses the PIT every 10ms, in square mode
> (PIT_C0|PIT_SQUAR
On 2014-11-16 23:18, Samuel Thibault wrote:
> Hello,
>
> Jan Kiszka, le Wed 12 Nov 2014 00:42:52 +0100, a écrit :
>> On 2014-11-11 19:55, Samuel Thibault wrote:
>>> jenkins.debian.net is running inside a KVM VM, and it runs nested
>>> KVM guests for its installati
On 2014-11-11 19:55, Samuel Thibault wrote:
> Hello,
>
> jenkins.debian.net is running inside a KVM VM, and it runs nested
> KVM guests for its installation attempts. This goes fine with Linux
> kernels, but it is extremely slow with gnumach kernels. I have
> reproduced the issue with my laptop
On 2014-10-22 22:34, Benjamin Herrenschmidt wrote:
> On Wed, 2014-10-22 at 16:17 +0200, Jan Kiszka wrote:
>> I thought about this again, and I'm not sure anymore if we can use
>> ACPI
>> to "black-list" the incompatible virtio devices. Reason: hotplug. To
&
On 2014-10-22 10:44, Michael S. Tsirkin wrote:
> On Wed, Oct 08, 2014 at 11:04:28AM +0200, Cornelia Huck wrote:
>> On Tue, 07 Oct 2014 18:24:22 -0700
>> Andy Lutomirski wrote:
>>
>>> On 10/07/2014 07:39 AM, Cornelia Huck wrote:
This patchset aims to get us some way to implement virtio-1 compl
Hi all,
we just started a test with Jailhouse in a VM on a decently recent Intel
box. It has APICv / posted interrupts support. And it breaks Jailhouse
activation (L1 breakage, host seems to be fine). Loading kvm-intel with
enable_apicv=0 resolves the issue. Henning started to debug from
Jailhouse
On 2014-10-09 13:53, Paolo Bonzini wrote:
> Patches are relative to next branch of kvm-kmod.git.
>
> Paolo
>
> Paolo Bonzini (3):
> FOLL_TRIED is not available before 3.18
> the MMU notifier clear_flush_young callback changed in 3.18
> redefine is_zero_pfn to not rely on zero_pfn
>
> exte
On 2014-10-08 21:07, Bandan Das wrote:
> Jan Kiszka writes:
>
>> In order to access the shadow VMCS, we need to load it. At this point,
>> vmx->loaded_vmcs->vmcs and the actually loaded one start to differ. If
>> we now get preempted by Linux, vmx_vcpu_put and, o
On 2014-10-08 17:44, Paolo Bonzini wrote:
> Il 08/10/2014 17:07, Jan Kiszka ha scritto:
>> As usual, this was a nasty race that involved some concurrent VCPUs and
>> proper host load, so hard to write unit tests...
>>
>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86
s12 to corrupt the vmcs12 state.
Fix the issue by disabling preemption during the copy operation.
copy_vmcs12_to_shadow is safe from this issue as it is executed by
vmx_vcpu_run when preemption is already disabled before vmentry.
Signed-off-by: Jan Kiszka
---
This fixes specifically Jailhouse in
On 2014-09-30 10:43, Paolo Bonzini wrote:
> Il 30/09/2014 09:54, Jan Kiszka ha scritto:
>>>> kvm_get_xtime_nsec could overflow. If we make kvm_get_boot_base_ns
>>>> compute the equivalent of 3.17's base_mono+offs_boot formula (instead of
>>>>
On 2014-10-08 12:34, Paolo Bonzini wrote:
> Il 08/10/2014 12:29, Jan Kiszka ha scritto:
>>>> But it would write to the vmcs02, not to the shadow VMCS; the shadow
>>>> VMCS is active during copy_shadow_to_vmcs12/copy_vmcs12_to_shadow, and
>>>> at no oth
On 2014-10-08 12:20, Paolo Bonzini wrote:
> Il 08/10/2014 11:51, Jan Kiszka ha scritto:
>>>> Could you point out where the other places L0 sets
>>>> CPU_BASED_VIRTUAL_INTR_PENDING before entering L2?
>> enable_irq_window(). I instrumented it, and it showed up ri
On 2014-10-08 11:25, Wanpeng Li wrote:
> Hi Jan,
> On Wed, Oct 08, 2014 at 10:29:45AM +0200, Jan Kiszka wrote:
>> Hi all,
>>
>> after migrating a Jailhouse VM to a newer host platform with shadow VMCS
>> support I found a bug. As you may know, Jailhouse doesn't
On 2014-10-08 10:47, Paolo Bonzini wrote:
> Il 08/10/2014 10:29, Jan Kiszka ha scritto:
>> Hi all,
>>
>> after migrating a Jailhouse VM to a newer host platform with shadow VMCS
>> support I found a bug. As you may know, Jailhouse doesn't intercept
>> i
Hi all,
after migrating a Jailhouse VM to a newer host platform with shadow VMCS
support I found a bug. As you may know, Jailhouse doesn't intercept
interrupts, thus also never requests an interrupt window. Nevertheless:
qemu-system-x86-5777 [001] 74970.625324: kvm_mmio: mmio write
On 2014-10-06 08:51, Paolo Bonzini wrote:
> Il 06/10/2014 06:45, Oscar Garcia ha scritto:
>>
>> I have a host with debian 7 (intel i7 - RAM 8GB), the guest OS is also
>> debian. I am running a program with some threads, every thread makes a
>> vmexit call. Also every thread runs in a isolated vcpu.
e ff ff 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 <48> f7 07 00 c0
> 00 00 55 48 89 e5 75 1e 8b 47 1c 85 c0 74 27 f0
>RIP [] put_page+0x5/0x50
>
> when not using the in-kernel irqchip ("-machine kernel_irqchip=off"
> with QEMU).
>
> Reported
On 2014-10-02 12:12, Paolo Bonzini wrote:
> Il 01/10/2014 09:40, Jan Kiszka ha scritto:
>> [50764.182615] Call Trace:
>> [50764.182633] [] vmx_vcpu_reset+0x20c/0x3b0 [kvm_intel]
>> [50764.182697] [] kvm_arch_vcpu_setup+0x2c/0x50 [kvm]
>> [50764.182734] [] kvm_vm_i
On 2014-09-30 12:39, Paolo Bonzini wrote:
> Il 30/09/2014 10:48, Jan Kiszka ha scritto:
>>>> +w('{')
>>>> +w('\treturn __kvm_mmu_notifier_clear_flush_young(mn, mm, hva,
>>>> hva+1);')
>> Ah, end=start+1, it&#
On 2014-09-30 10:43, Paolo Bonzini wrote:
> Il 30/09/2014 09:54, Jan Kiszka ha scritto:
>>>> kvm_get_xtime_nsec could overflow. If we make kvm_get_boot_base_ns
>>>> compute the equivalent of 3.17's base_mono+offs_boot formula (instead of
>>>>
On 2014-09-23 10:22, Paolo Bonzini wrote:
> kvm_get_xtime_nsec could overflow. If we make kvm_get_boot_base_ns
> compute the equivalent of 3.17's base_mono+offs_boot formula (instead of
> just offs_boot), we can avoid that and drop kvm_get_xtime_nsec altogether.
Applied, thanks.
Any suggestions
On 2014-09-24 04:09, Tang Chen wrote:
> Hi Paolo,
>
> I'm not sure if this patch is following your comment. Please review.
> And all the other comments are followed. If this patch is OK, I'll
> send v8 soon.
>
> Thanks.
>
> We are handling "L1 and L2 share one apic access page" situation when
On 2014-09-12 19:15, Jan Kiszka wrote:
> On 2014-09-12 14:29, Erik Rull wrote:
>>> On September 11, 2014 at 3:32 PM Jan Kiszka wrote:
>>>
>>>
>>> On 2014-09-11 15:25, Erik Rull wrote:
>>>>> On August 6, 2014 at 1:19 PM Erik Rull wrote:
>&
On 2014-09-12 14:29, Erik Rull wrote:
>> On September 11, 2014 at 3:32 PM Jan Kiszka wrote:
>>
>>
>> On 2014-09-11 15:25, Erik Rull wrote:
>>>> On August 6, 2014 at 1:19 PM Erik Rull wrote:
>>>>
>>>>
>>>> Hi all,
>&g
On 2014-09-11 15:25, Erik Rull wrote:
>> On August 6, 2014 at 1:19 PM Erik Rull wrote:
>>
>>
>> Hi all,
>>
>> I did already several tests and I'm not completely sure what's going wrong,
>> but
>> here my scenario:
>>
>> When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla
>> k
On 2014-09-11 11:08, Paolo Bonzini wrote:
> Il 11/09/2014 08:01, Jan Kiszka ha scritto:
>> That issue is limited to the dead ia64 architecture, no other builds
>> ioapic.c (besides x86, of course). Maybe finally remove KVM support for
>> that arch instead of bloating o
On 2014-09-10 18:53, Chris J Arges wrote:
> cppcheck found the following error:
> [ioapic.c:114]: (error) Array index -1 is out of bounds.
>
> If CONFIG_X86 is not defined, RTC_GSI == -1U which means that an out of bounds
That issue is limited to the dead ia64 architecture, no other builds
ioapic
On 2014-09-11 07:06, Zhang Haoyu wrote:
> Currently, we call ioapic_service() immediately when we find the irq is still
> active during eoi broadcast. But for real hardware, there's some dealy between
> the EOI writing and irq delivery (system bus latency?). So we need to emulate
> this behavior. O
On 2014-08-29 18:47, Paolo Bonzini wrote:
> Il 19/08/2014 11:04, Wanpeng Li ha scritto:
>> Section 11.11.2.3 of the SDM mentions "All other bits in the
>> IA32_MTRR_PHYSBASEn
>> and IA32_MTRR_PHYSMASKn registers are reserved; the processor generates a
>> general-protection exception(#GP) if soft
After its publication about 10 months ago, the Jailhouse partitioning
hypervisor for Linux [1] reached an important first milestone: all major
features required to use Jailhouse on Intel x86 CPUs are now available.
We are marking this point with a first release tag, v0.1.
This release particularly
On 2014-08-21 13:04, Paolo Bonzini wrote:
> Il 21/08/2014 10:48, Valentine Sinitsyn ha scritto:
>> So I'm returning to my original question: is this an intended behavior
>> of KVM that APIC access on nested page tables level are not trapped, or
>> is this a bug?
>
> I think it's just a bug. Nobod
On 2014-07-28 23:17, Nakajima, Jun wrote:
> On Mon, Jul 28, 2014 at 1:27 PM, Paolo Bonzini wrote:
>> Il 28/07/2014 20:31, Jan Kiszka ha scritto:
>>> The hypervisor has full control of and insight into the guest vCPU
>>> state. Only protecting some portions of gues
On 2014-07-28 19:17, Joel Schopp wrote:
>
> On 07/25/2014 03:11 PM, Shiva V wrote:
>> Hello,
>> I am exploring on finding a way to ensure runtime integrity of
>>
>> a executable in untrusted hypervisors.
>>
>> In particular, this is my requirements:
>>
>> 1. I have a 2 virtual machines. (A, B).
On 2014-07-23 21:42, Tang Chen wrote:
> This patch only handle "L1 and L2 vm share one apic access page" situation.
>
> When L1 vm is running, if the shared apic access page is migrated,
> mmu_notifier will
> request all vcpus to exit to L0, and reload apic access page physical address
> for
> a
On 2014-07-19 03:21, Chen Gang wrote:
> If kvm_arch_remove_sw_breakpoint() in CPU_FOREACH() always be fail, it
> will let 'cpu' NULL. And the next kvm_arch_remove_sw_breakpoint() in
> QTAILQ_FOREACH_SAFE() will get NULL parameter for 'cpu'.
>
> And kvm_arch_remove_sw_breakpoint() can assumes 'cpu'
On 2014-07-15 14:40, Gleb Natapov wrote:
>>
>> ..
>> 7922 if (!vmx->nested.apic_access_page)
>> 7923 exec_control &=
>> 7924 ~SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
>> 7925 else
>> 7926
On 2014-07-14 16:58, Gleb Natapov wrote:
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index ffbe557..7080eda 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5929,6 +5929,18 @@ static void vcpu_scan_ioapic(struct kvm_vcpu *vcpu)
kvm_apic_update_t
On 2014-07-08 06:17, Alok Kataria wrote:
> Thanks Jan and Paolo for looking at the change, I have added a comment
> in svm_get_segment. Joerg, please consider this for the next merge.
>
> --
>
> From: Jim Mattson
>
> We have noticed that qemu-kvm hangs early in the BIOS when runnning nested
> u
On 2014-07-08 07:50, Paolo Bonzini wrote:
> Il 08/07/2014 06:30, Bandan Das ha scritto:
>>
>> With commit b6b8a1451fc40412c57d1 that introduced
>> vmx_check_nested_events, checks for injectable interrupts happen
>> at different points in time for L1 and L2 that could potentially
>> cause a race. Th
On 2014-07-07 12:38, Alok Kataria wrote:
> From: Jim Mattson
>
> We have noticed that qemu-kvm hangs early in the BIOS when runnning nested
> under some versions of VMware ESXi.
>
> The problem we believe is because KVM assumes that the platform preserves
> the 'G' but for any segment register.
On 2014-07-06 17:41, Gleb Natapov wrote:
> On Sun, Jul 06, 2014 at 05:24:27PM +0200, Jan Kiszka wrote:
>> On 2014-07-06 17:12, Gleb Natapov wrote:
>>> On Sat, Jul 05, 2014 at 09:47:54AM +0200, Jan Kiszka wrote:
>>>> From: Jan Kiszka
>>>>
>>>
On 2014-07-06 17:12, Gleb Natapov wrote:
> On Sat, Jul 05, 2014 at 09:47:54AM +0200, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> We are able to use x2APIC mode in the absence of interrupt remapping on
>> certain hypervisors. So it if fine to disable IRQ_REMAP without
From: Jan Kiszka
We are able to use x2APIC mode in the absence of interrupt remapping on
certain hypervisors. So it if fine to disable IRQ_REMAP without having
to give up x2APIC support.
Signed-off-by: Jan Kiszka
---
arch/x86/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
This is required in order to use the stack in inline assembly (like
pushf; pop reg) without clashing with the compiler's stack assignment.
Signed-off-by: Jan Kiszka
---
Seen with old gcc 4.5.1.
config/config-x86_64.mak | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/c
On 2014-07-04 12:52, Jan Kiszka wrote:
> On 2014-07-04 11:38, Paolo Bonzini wrote:
>> Il 04/07/2014 11:33, Jan Kiszka ha scritto:
>>>
>>> The compiler is not aware of the fact that push/pop exists in this
>>> function and, thus, places the vmcs parameter on
On 2014-07-04 11:38, Paolo Bonzini wrote:
> Il 04/07/2014 11:33, Jan Kiszka ha scritto:
>>
>> The compiler is not aware of the fact that push/pop exists in this
>> function and, thus, places the vmcs parameter on the stack without
>> reserving the space. So the pus
On 2014-07-04 07:43, Jan Kiszka wrote:
> All tests up to
> 307621765a are running fine here, but since a0e30e712d not much is
> completing successfully anymore:
>
> enabling apic
> paging enabled
> cr0 = 80010011
> cr3 = 7fff000
> cr4 = 20
> PASS: test vmxon with
On 2014-07-04 08:17, Wanpeng Li wrote:
> On Thu, Jul 03, 2014 at 01:15:26AM -0400, Bandan Das wrote:
>> Jan Kiszka writes:
>>
>>> On 2014-07-02 08:54, Wanpeng Li wrote:
>>>> This patch fix bug https://bugzilla.kernel.org/show_bug.cgi?id=72381
>>>>
On 2014-07-04 08:08, Wanpeng Li wrote:
> On Fri, Jul 04, 2014 at 07:43:14AM +0200, Jan Kiszka wrote:
>> On 2014-07-04 04:52, Wanpeng Li wrote:
>>> On Thu, Jul 03, 2014 at 01:27:05PM -0400, Bandan Das wrote:
>>> [...]
>>>> # modprobe kvm_intel ept=0 nested=1
On 2014-07-04 05:27, Hu Yaohui wrote:
> Hi All,
> Is direct device assignment in nested VM supported in the latest KVM
> mainline now?
Le Tan is currently working on emulated device assignment (VT-d
emulation in QEMU). This is the necessary first step and could later be
extended to enable assignme
On 2014-07-04 04:52, Wanpeng Li wrote:
> On Thu, Jul 03, 2014 at 01:27:05PM -0400, Bandan Das wrote:
> [...]
>> # modprobe kvm_intel ept=0 nested=1 enable_shadow_vmcs=0
>>
>> The Host CPU - Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
>> qemu cmd to run L1 -
>> # qemu-system-x86_64 -drive
>> file=leve
On 2014-07-03 07:29, Bandan Das wrote:
> Wanpeng Li writes:
>
>> Hi Bandan,
>> On Wed, Jul 02, 2014 at 12:27:59PM -0400, Bandan Das wrote:
>>> Wanpeng Li writes:
>>>
This patch fix bug https://bugzilla.kernel.org/show_bug.cgi?id=72381
>>> I can also reproduce this easily with Linux as L1 b
Hi Jörg,
a question about how to interpret the SVM spec popped up because of a
problems with running KVM on top of VMware: We currently read the G bit
of all segments except CS back from the VMCB (svm_get_segment). VMware
does not seem to support this while real hardware is practically fine.
So I
On 2014-07-02 11:13, Hu, Robert wrote:
>
>> -Original Message-
>> From: Jan Kiszka [mailto:jan.kis...@siemens.com]
>> Sent: Wednesday, July 2, 2014 5:03 PM
>> To: Hu, Robert; Wanpeng Li; Paolo Bonzini; Gleb Natapov
>> Cc: kvm@vger.kernel.org; linux-ker.
On 2014-07-02 09:20, Hu, Robert wrote:
>> -Original Message-
>> From: Wanpeng Li [mailto:wanpeng...@linux.intel.com]
>> Sent: Wednesday, July 2, 2014 2:54 PM
>> To: Paolo Bonzini; Jan Kiszka; Gleb Natapov
>> Cc: Hu, Robert; kvm@vger.kernel.org; linux-ker.
On 2014-07-02 08:54, Wanpeng Li wrote:
> This patch fix bug https://bugzilla.kernel.org/show_bug.cgi?id=72381
>
> If we didn't inject a still-pending event to L1 since nested_run_pending,
> KVM_REQ_EVENT should be requested after the vmexit in order to inject the
> event to L1. However, current
On 2014-07-01 17:23, Joerg Roedel wrote:
> On Mon, Jun 30, 2014 at 10:54:17AM +0200, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> First, kvm_read_guest returns 0 on success. And then we need to take the
>> access size into account when testing the bitmap: intercept if a
On 2014-06-30 17:08, Paolo Bonzini wrote:
> Il 30/06/2014 10:54, Jan Kiszka ha scritto:
>> +SVM_IOIO_SIZE_SHIFT;
>> gpa = svm->nested.vmcb_iopm + (port / 8);
>> -bit = port % 8;
>> -val = 0;
>> +start_bit = port % 8;
>> +
On 2014-06-30 17:01, Paolo Bonzini wrote:
> Il 29/06/2014 17:12, Jan Kiszka ha scritto:
>> From: Jan Kiszka
>>
>> We import the CPL via SS.DPL since ae9fedc793. However, we fail to
>> export it this way so far. This caused spurious guest crashes, e.g. of
>> Lin
From: Jan Kiszka
Obtaining the port number from DX is bogus as a) there are immediate
port accesses and b) user space may have changed the register content
while processing the PIO access. Forward the correct value from the
instruction emulator instead.
Signed-off-by: Jan Kiszka
---
Valentine
On 2014-06-30 11:07, Jan Kiszka wrote:
> I'm seeing one more issue now: on emulation of "in (%dx),%eax", we leave
> to user space several times and check interception also several times
Correction: we only leave once for user space.
> after returning. We use dx to calcu
From: Jan Kiszka
The access size of an in/ins is reported in dst_bytes, and that of
out/outs in src_bytes.
Signed-off-by: Jan Kiszka
---
I'm seeing one more issue now: on emulation of "in (%dx),%eax", we leave
to user space several times and check interception also seve
From: Jan Kiszka
First, kvm_read_guest returns 0 on success. And then we need to take the
access size into account when testing the bitmap: intercept if any of
bits corresponding to the access is set.
Signed-off-by: Jan Kiszka
---
This does not yet solve all IOIO issues, there are emulation
From: Jan Kiszka
CLTS only changes TS which is not monitored by selected CR0
interception. So skip any attempt to translate WRITE_CR0 to
CR0_SEL_WRITE for this instruction.
Signed-off-by: Jan Kiszka
---
arch/x86/kvm/svm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a
From: Jan Kiszka
We import the CPL via SS.DPL since ae9fedc793. However, we fail to
export it this way so far. This caused spurious guest crashes, e.g. of
Linux when accessing the vmport from guest user space which triggered
register saving/restoring to/from host user space.
Signed-off-by: Jan
On 2014-06-29 16:32, Jan Kiszka wrote:
> On 2014-06-29 16:27, Gleb Natapov wrote:
>> On Sun, Jun 29, 2014 at 04:01:04PM +0200, Borislav Petkov wrote:
>>> On Sun, Jun 29, 2014 at 04:42:47PM +0300, Gleb Natapov wrote:
>>>> Please do so and let us know.
>>>
On 2014-06-29 16:27, Gleb Natapov wrote:
> On Sun, Jun 29, 2014 at 04:01:04PM +0200, Borislav Petkov wrote:
>> On Sun, Jun 29, 2014 at 04:42:47PM +0300, Gleb Natapov wrote:
>>> Please do so and let us know.
>>
>> Yep, just did. Reverting ae9fedc793 fixes the issue.
>>
>>> reinj:1 means that previou
On 2014-06-29 13:51, Borislav Petkov wrote:
> On Sun, Jun 29, 2014 at 12:59:30PM +0200, Jan Kiszka wrote:
>> Will see what I can do regarding bisecting. That host is a bit slow
>> (netbook), so it may take a while. Boris will probably beat me in
>> this.
>
> Nah
On 2014-06-29 12:53, Gleb Natapov wrote:
> On Sun, Jun 29, 2014 at 12:31:50PM +0200, Jan Kiszka wrote:
>> On 2014-06-29 12:24, Gleb Natapov wrote:
>>> On Sun, Jun 29, 2014 at 11:56:03AM +0200, Jan Kiszka wrote:
>>>> On 2014-06-29 08:46, Gleb Natapov wrote:
>>&g
On 2014-06-29 12:24, Gleb Natapov wrote:
> On Sun, Jun 29, 2014 at 11:56:03AM +0200, Jan Kiszka wrote:
>> On 2014-06-29 08:46, Gleb Natapov wrote:
>>> On Sat, Jun 28, 2014 at 01:44:31PM +0200, Borislav Petkov wrote:
>>>> qemu-system-x86-20240 [006] ...1 9406.4
On 2014-06-29 08:46, Gleb Natapov wrote:
> On Sat, Jun 28, 2014 at 01:44:31PM +0200, Borislav Petkov wrote:
>> qemu-system-x86-20240 [006] ...1 9406.484134: kvm_page_fault: address
>> 7fffb62ba318 error_code 2
>> qemu-system-x86-20240 [006] ...1 9406.484136: kvm_inj_exception: #PF (0x2)a
>>
>>
On 2014-06-18 13:36, Valentine Sinitsyn wrote:
> Hi all,
>
> I'm using a KVM/Qemu nested SVM setup to debug another hypervisor
> (Jailhouse) I contribute to. IOW, the scheme is: AMD64 Linux host
> running [paravirtualized] AMD64 Linux guest (the same kernel as the
> host) running Jailhouse.
>
> J
Check for required-0 or required-1 bits as well as known field value
restrictions. Also check the consistency between VMX_*_CTLS and
VMX_TRUE_*_CTLS and between CR0/4_FIXED0 and CR0/4_FIXED1.
Signed-off-by: Jan Kiszka
---
Changes in v3:
- integrated suggestions of Paolo
x86/vmx.c | 74
On 2014-06-17 09:41, Paolo Bonzini wrote:
> Il 17/06/2014 09:04, Jan Kiszka ha scritto:
>>
>> -#define FIELD_EXIT_QUAL0
>> -#define FIELD_INSN_INFO1
>> +#define FIELD_EXIT_QUAL(1 << 1)
>> +#define FIELD_INSN_INFO(1 << 2
101 - 200 of 4875 matches
Mail list logo
