On 23/06/2015 12:08, Denis V. Lunev wrote:
> the behavior becomes controlled by libvirt, which has
> appropriate event configuration, specified here
> https://libvirt.org/formatdomain.html
> namely
> restart
>
> Thus it looks like without libvirt help the guest will stuck
> in RUN_STATE_GUES
On 22/06/2015 19:46, Andreas Färber wrote:
> On the other hand, I wonder if current_cpu is available in
> qemu_system_guest_panicked. If so, you could add the field to the
> generic CPUState struct and migrate it as a subsection of
> vmstate_cpu_common.
>>> >>
On 23/06/2015 11:47, Denis V. Lunev wrote:
>>
>> The current implementation is potentially more flexible but makes the
>> MSR handling a little more awkward since the host_initiated bool needs
>> to be passed around (patch 09). I guess either approach seems ok to
>> me.
>>
>> Also, if this patchs
On 23/06/2015 01:55, Peter Hornyack wrote:
>> > -static int kvm_hv_msr_set_crash_ctl(struct kvm_vcpu *vcpu, u64 data)
>> > +static int kvm_hv_msr_set_crash_ctl(struct kvm_vcpu *vcpu, u64 data, bool
>> > host)
>> > {
>> > struct kvm_arch_hyperv *hv = &vcpu->kvm->arch.hyperv;
>> >
>> >
On 19/06/2015 09:21, Michael Ellerman wrote:
> Now that we don't have the kernel header on hand, just define the
> minimum set of hcall opcodes and return values we need in order to
> build.
>
> Signed-off-by: Michael Ellerman
> ---
> powerpc/spapr.h | 25 -
> 1 file ch
On 23/06/2015 00:08, John Nielsen wrote:
Thank you. This both narrows the problem considerably and provides
an acceptable workaround. It would still be nice to see it fixed, of
course. Keep me CC'ed as I'm not on the KVM list.
>>>
>>> I’m resurrecting an old thread since I haven’t
On 23/06/2015 04:29, Xiao Guangrong wrote:
>>>
>>>
>>> If so, can you look at kvm/queue and see if it is okay for you (so that
>>> we can get the series in 4.2)?
>>
>> Ping?
>>
>> If I don't get testing results before Wednesday, I'll drop this series
>> from the 4.2 pull request.
>
> Paolo, sorr
On 22/06/2015 18:33, Andreas Färber wrote:
>> > On the other hand, I wonder if current_cpu is available in
>> > qemu_system_guest_panicked. If so, you could add the field to the
>> > generic CPUState struct and migrate it as a subsection of
>> > vmstate_cpu_common.
> Hm, not sure whether it is.
On 22/06/2015 18:23, Andreas Färber wrote:
>> > @@ -679,6 +679,7 @@ static const VMStateDescription
>> > vmstate_msr_hyperv_crash = {
>> > VMSTATE_UINT64(env.msr_hv_crash_ctl, X86CPU),
>> > VMSTATE_UINT64_ARRAY(env.msr_hv_crash_prm,
>> > X86CPU, HV
Another one...
On 22/06/2015 18:05, Denis V. Lunev wrote:
> +case KVM_SYSTEM_EVENT_CRASH:
> +if (run->system_event.flags & KVM_SYSTEM_EVENT_FL_HV_CRASH) {
> +kvm_arch_handle_hv_crash(cpu);
> +}
> +qemu_system_guest_pan
On 22/06/2015 18:05, Denis V. Lunev wrote:
> +void qemu_system_guest_panicked(void)
> +{
> +qapi_event_send_guest_panicked(GUEST_PANIC_ACTION_PAUSE, &error_abort);
> +vm_stop(RUN_STATE_GUEST_PANICKED);
> +}
> +
Please call this in pvpanic.c and target-s390x/kvm.c (replacing the
guest_pan
>
> Signed-off-by: Andrey Smetanin
> Signed-off-by: Denis V. Lunev
> CC: Paolo Bonzini
> CC: Gleb Natapov
> ---
> arch/x86/kvm/hyperv.c | 17 +
> arch/x86/kvm/hyperv.h | 2 +-
> arch/x86/kvm/x86.c| 3 ++-
> 3 files changed, 12 insertions(+), 10 de
On 22/06/2015 15:28, Hu Yaohui wrote:
>
> */2504 pseudo_gfn = base_addr >> PAGE_SHIFT;
> 2505 sp = kvm_mmu_get_page(vcpu, pseudo_gfn, iterator.addr,
> 2506 iterator.level - 1,
> 2507 1, ACC_ALL, iterator.sptep);/*
> 2508
On 19/06/2015 20:57, Hu Yaohui wrote:
> One more thing, for the standard guest VM which uses EPT, What's the
> usage of "gfn" field in the "struct kvm_mmu_page"? Since it uses EPT,
> a single shadow page should has no relation with any of the guest
> physical page, right?
The gfn is the same va
On 17/06/2015 18:11, Paolo Bonzini wrote:
> Also, this loop looks weird. Is this what you wanted?
>
> list_for_each_entry(tmp, &mtrr_state->head, node)
> if (cur->base >= tmp->base)
> break;
> li
On 22/06/2015 09:10, Igor Mammedov wrote:
> So far HVA is unusable even if we will make this assumption and let guest
> crash.
> virt_net doesn't work with it anyway,
> translation of GPA to HVA for descriptors works as expected (correctly)
> but vhost+HVA hack backed virtio still can't send/rec
On 20/06/2015 02:41, Steve Rutherford wrote:
> Pinging this thread.
>
> Should I go with skipping the round trip, and combining
> KVM_REQUEST_PIC_INJECTION with the KVM_INTERRUPT (a VCPU IOCTL)?
> [It's currently a VM IOCTL, which seems reasonable, given that the
> PIC is a per VM device. When s
On 19/06/2015 18:45, Michael S. Tsirkin wrote:
> > user guest QEMU
> >
> >
> > start I/O
> > '
On 19/06/2015 18:33, Michael S. Tsirkin wrote:
> On Fri, Jun 19, 2015 at 06:26:27PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 19/06/2015 18:20, Michael S. Tsirkin wrote:
>>>> We could, but I/O is just an example. It can be I/O, a network ring,
>>>> wha
On 19/06/2015 18:20, Michael S. Tsirkin wrote:
> > We could, but I/O is just an example. It can be I/O, a network ring,
> > whatever. We cannot audit all address_space_map uses.
> >
>
> No need to audit them all: defer device_add using an hva range until
> address_space_unmap drops using hvas
On 19/06/2015 14:44, Hu Yaohui wrote:
> Hi Paolo,
> Thanks a lot!
>
> On Fri, Jun 19, 2015 at 2:27 AM, Paolo Bonzini wrote:
>>
>>
>> On 19/06/2015 03:52, Hu Yaohui wrote:
>>> Hi All,
>>> In kernel 3.14.2, the kvm uses shadow EPT(EPT02) to implem
On 19/06/2015 15:34, Michael S. Tsirkin wrote:
> On Fri, Jun 19, 2015 at 12:44:26PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 19/06/2015 12:14, Michael S. Tsirkin wrote:
>>> On Fri, Jun 19, 2015 at 10:52:47AM +0200, Paolo Bonzini wrote:
>>>>
>>>&
On 19/06/2015 14:53, Marc Zyngier wrote:
> git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
> tags/kvm-arm-for-4.2
>
> for you to fetch changes up to c62e631d4a8e41493c6341d8259e996ed5fc11e3:
>
> KVM: arm/arm64: vgic: Remove useless arm-gic.h #include (2015-06-18
> 15:50:31
While the code looks great, the splitting of patches 1 and 2
left something to be desired. I've redone the split altogether
and I'll place it soon in kvm/queue because I needed to do it myself
to figure out some suggestions; and after 4 hours it would have been
pointless for you to do the work aga
On 12/06/2015 07:34, Wei Huang wrote:
> -static void trigger_pmi(struct irq_work *irq_work)
> +static void kvm_pmi_trigger_fn(struct irq_work *irq_work)
> {
> - struct kvm_pmu *pmu = container_of(irq_work, struct kvm_pmu,
> - irq_work);
> - struct kvm_vcpu *vcpu = con
On 12/06/2015 07:34, Wei Huang wrote:
> This patch defines a new function pointer struct (kvm_pmu_ops) to
> support vPMU for both Intel and AMD. The functions pointers defined in
> this new struct will be linked with Intel and AMD functions later. In the
> meanwhile the struct that maps from even
On 19/06/2015 12:14, Michael S. Tsirkin wrote:
> On Fri, Jun 19, 2015 at 10:52:47AM +0200, Paolo Bonzini wrote:
>>
>>
>> On 19/06/2015 10:05, Michael S. Tsirkin wrote:
>>>> No, only destruction of the memory region frees it. address_space_map
>>>&g
On 19/06/2015 12:28, Andrey Smetanin wrote:
> On Wed, 2015-06-17 at 14:44 +0200, Paolo Bonzini wrote:
>>
>> On 11/06/2015 15:18, Denis V. Lunev wrote:
>>> From: Andrey Smetanin
>>>
>>> Windows 2012 guests can notify hypervisor about occurred guest cra
On 18/06/2015 17:50, Andre Przywara wrote:
> Currently we set CC unconditionally to ${CROSS_COMPILE}gcc, the same
> for LD.
> Allow people to override the compiler name by specifying it explicitly
> on the command line or via the environment.
> Beside calling a certain compiler binary this allows
On 19/06/2015 10:05, Michael S. Tsirkin wrote:
> > No, only destruction of the memory region frees it. address_space_map
> > takes a reference to the memory region and address_space_unmap releases it.
> >
> > Paolo
>
> Confused. So can we call mmap(MAP_NORESERVE) in address_space_unmap
> after
On 19/06/2015 09:56, Michael S. Tsirkin wrote:
> On Thu, Jun 18, 2015 at 06:02:46PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 18/06/2015 16:47, Michael S. Tsirkin wrote:
>>>> However, with Igor's patches a memory_region_del_subregion will cause a
>>&
On 19/06/2015 03:52, Hu Yaohui wrote:
> Hi All,
> In kernel 3.14.2, the kvm uses shadow EPT(EPT02) to implement the
> nested EPT. The shadow EPT(EPT02) is a shadow of guest EPT (EPT12). If
> the L1 guest writes to the guest EPT(EPT12). How can the shadow
> EPT(EPT02) be modified according?
Becau
On 18/06/2015 16:47, Michael S. Tsirkin wrote:
>> However, with Igor's patches a memory_region_del_subregion will cause a
>> mmap(MAP_NORESERVE), which _does_ have the effect of making the hva go away.
>>
>> I guess one way to do it would be to alias the same page in two places,
>> one for use by
On 18/06/2015 15:19, Michael S. Tsirkin wrote:
> On Thu, Jun 18, 2015 at 01:50:32PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 18/06/2015 13:41, Michael S. Tsirkin wrote:
>>> On Thu, Jun 18, 2015 at 01:39:12PM +0200, Igor Mammedov wrote:
>>>> Lets leave
On 18/06/2015 13:41, Michael S. Tsirkin wrote:
> On Thu, Jun 18, 2015 at 01:39:12PM +0200, Igor Mammedov wrote:
>> Lets leave decision upto users instead of making them live with
>> crashing guests.
>
> Come on, let's fix it in userspace.
It's not trivial to fix it in userspace. Since QEMU use
On 18/06/2015 11:50, Michael S. Tsirkin wrote:
> > But lets assume that there are tools that do this so
> > how about instead of hardcoding limit make it a module parameter
> > with default set to 64. That would allow users to set higher limit
> > if they need it and nor regress old tools. it wil
On 18/06/2015 07:02, Xiao Guangrong wrote:
> However, role->level is more hotter than role->smm so that it's also a good
> candidate for this kind of trick.
Right, we could give the first 8 bits to role->level, so it can be
accessed with a single memory load and extracted with a single AND.
Thos
On 17/06/2015 19:02, kbuild test robot wrote:
> tree: git://git.kernel.org/pub/scm/virt/kvm/kvm.git queue
> head: 3b1a15b8db95eff1bcd9303057c9415f650c6331
> commit: 3b1a15b8db95eff1bcd9303057c9415f650c6331 [94/94] KVM: MTRR: do not
> map huge page for non-consistent range
> config: i386-rand
On 17/06/2015 18:41, Michael S. Tsirkin wrote:
> On Wed, Jun 17, 2015 at 06:38:25PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 17/06/2015 18:34, Michael S. Tsirkin wrote:
>>> On Wed, Jun 17, 2015 at 06:31:32PM +0200, Paolo Bonzini wrote:
>>>>
>>>&
On 17/06/2015 18:34, Michael S. Tsirkin wrote:
> On Wed, Jun 17, 2015 at 06:31:32PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 17/06/2015 18:30, Michael S. Tsirkin wrote:
>>> Meanwhile old tools are vulnerable to OOM attacks.
>>
>> For each vhost device the
On 17/06/2015 18:30, Michael S. Tsirkin wrote:
> Meanwhile old tools are vulnerable to OOM attacks.
For each vhost device there will be likely one tap interface, and I
suspect that it takes way, way more than 16KB of memory.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm
On 15/06/2015 10:55, Xiao Guangrong wrote:
> + /* add it to the list if it's valid. */
> + if (var_mtrr_range_is_valid(&mtrr_state->var_ranges[index])) {
> + list_for_each_entry(tmp, &mtrr_state->head, node)
> + if (cur->base < tmp->base)
> +
On 15/06/2015 10:55, Xiao Guangrong wrote:
> It gets the range for the specified variable MTRR
>
> Signed-off-by: Xiao Guangrong
> ---
> arch/x86/kvm/mtrr.c | 19 +--
> 1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
On 15/06/2015 10:55, Xiao Guangrong wrote:
> Sort all valid variable MTRRs based on its base address, it will help us to
> check a range to see if it's fully contained in variable MTRRs
>
> Signed-off-by: Xiao Guangrong
> ---
> arch/x86/include/asm/kvm_host.h | 3 ++
> arch/x86/kvm/mtrr.c
mp by QEMU/LIBVIRT.
>
> The idea is to provide functionality equal to pvpanic device without
> QEMU guest agent for Windows.
>
> The idea is borrowed from Linux HyperV bus driver and validated against
> Windows 2k12.
>
> Signed-off-by: Andrey Smetanin
> Signed-off-by: De
On 17/06/2015 13:11, Borislav Petkov wrote:
> peterz reminded me that I'm lazy actually and don't reply to each patch :)
>
> So, I like it, looks good, nice cleanup. It boots on my guest here - I
> haven't done any baremetal testing though. Let's give people some more
> time to look at it...
Sa
that function, so the extra check is
> unnecessary.
Or more simply, KVM (host-side) requires the TSC to exist.
Acked-by: Paolo Bonzini
> (Off-topic, but the whole KVM clock host implementation is gross.
> IMO it should be rewritten.)
>
> Signed-off-by: Andy Lutomirski
>
On 17/06/2015 09:47, Paolo Bonzini wrote:
>
>
> On 17/06/2015 02:36, Andy Lutomirski wrote:
>> __pvclock_read_cycles had an unnecessary barrier. Get rid of that
>> barrier and clean up the code by just using rdtsc_ordered().
>>
>> Cc: Paolo Bonzini
>> C
On 17/06/2015 15:13, Michael S. Tsirkin wrote:
> > > Considering userspace can be malicious, I guess yes.
> > I don't think it's a valid concern in this case,
> > setting limit back from 509 to 64 will not help here in any way,
> > userspace still can create as many vhost instances as it needs
>
2k12.
>
> Signed-off-by: Andrey Smetanin
> Signed-off-by: Denis V. Lunev
> CC: Gleb Natapov
> CC: Paolo Bonzini
> ---
> arch/x86/include/uapi/asm/hyperv.h | 10 +
> arch/x86/kvm/Makefile | 2 +-
> arch/x86/kvm/mshv.c| 84
> ++
On 11/06/2015 08:05, Bandan Das wrote:
>
> If hardware doesn't support DecodeAssist - a feature that provides
> more information about the intercept in the VMCB, KVM decodes the
> instruction and then updates the next_rip vmcb control field.
> However, NRIP support itself depends on cpuid Fn8000
On 16/06/2015 13:33, Kevin Mulvey wrote:
> fix brace spacing
>
> Signed-off-by: Kevin Mulvey
> ---
> virt/kvm/async_pf.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/virt/kvm/async_pf.h b/virt/kvm/async_pf.h
> index e7ef6447..ec4cfa2 100644
> --- a/virt/kvm/asy
On 17/06/2015 08:34, Michael S. Tsirkin wrote:
>>> > >
>>> > > Also - 509?
>> > userspace memory slots in terms of KVM, I made it match
>> > KVM's allotment of memory slots for userspace side.
> Maybe KVM has its reasons for this #.
Nice power of two (512) - number of reserved slots required by
On 09/06/2015 06:01, Xiao Guangrong wrote:
>
>
> On 05/28/2015 01:05 AM, Paolo Bonzini wrote:
>> This is now very simple to do. The only interesting part is a simple
>> trick to find the right memslot in gfn_to_rmap, retrieving the address
>> space from the spte ro
On 09/06/2015 05:28, Xiao Guangrong wrote:
>>
>> -rmapp = gfn_to_rmap(kvm, sp->gfn, PT_PAGE_TABLE_LEVEL);
>> +slots = kvm_memslots(kvm);
>> +slot = __gfn_to_memslot(slots, sp->gfn);
>> +rmapp = __gfn_to_rmap(sp->gfn, PT_PAGE_TABLE_LEVEL, slot);
>>
>
> Why @sp is not available her
On 09/06/2015 04:16, Wanpeng Li wrote:
>>
>> So in the end the patched vcpu_scan_ioapic becomes
>>
>> if (kvm_apic_hw_enabled(vcpu->arch.apic))
>
> s/kvm_apic_hw_enabled(vcpu->arch.apic)/!kvm_apic_hw_enabled(vcpu->arch.apic)
Right, thanks for the correction.
Paolo
--
To unsubscribe from th
On 17/06/2015 02:36, Andy Lutomirski wrote:
> __pvclock_read_cycles had an unnecessary barrier. Get rid of that
> barrier and clean up the code by just using rdtsc_ordered().
>
> Cc: Paolo Bonzini
> Cc: Radim Krcmar
> Cc: Marcelo Tosatti
> Cc: kvm@vger.kernel.org
;< 2)
> +
> /* CPUID[0x8007].EDX flags: */
> #define CPUID_APM_INVTSC (1U << 8)
>
> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> index ca2da84..d7bd205 100644
> --- a/target-i386/kvm.c
> +++ b/target-i386/kvm.c
> @@ -233,6 +233,8 @
On 08/06/2015 12:33, Wanpeng Li wrote:
>> +if (kvm_check_request(KVM_REQ_SCAN_IOAPIC, vcpu)) {
>> +if (irqchip_split(vcpu->kvm)) {
>> +memset(vcpu->arch.eoi_exit_bitmaps, 0, 32);
>> +kvm_scan_ioapic_routes(
>> +vcpu, vcpu->ar
On 06/06/2015 01:50, kbuild test robot wrote:
> tree: git://git.kernel.org/pub/scm/virt/kvm/kvm.git queue
> head: 6aa5e7eb06cff8d317328a0c4696b5f635ba6be3
> commit: 6aa5e7eb06cff8d317328a0c4696b5f635ba6be3 [76/76] kvm: irqchip: Break
> up high order allocations of kvm_irq_routing_table
> rep
On 05/06/2015 20:57, Radim Krčmář wrote:
> lapic.timer_mode was not properly initialized after migration, which
> broke few useful things, like login, by making every sleep eternal.
>
> Fix this by calling apic_update_lvtt in kvm_apic_post_state_restore.
>
> There are other slowpaths that updat
On 05/06/2015 17:13, Radim Krčmář wrote:
> 2015-06-05 14:46+0200, Paolo Bonzini:
>> On 05/06/2015 14:10, Radim Krčmář wrote:
>>> + ret = __kvm_write_guest_page(__gfn_to_memslot(slots, gfn), gfn,
>>> + data, offset, seg);
>>
&g
On 05/06/2015 14:10, Radim Krčmář wrote:
> + ret = __kvm_write_guest_page(__gfn_to_memslot(slots, gfn), gfn,
> + data, offset, seg);
Even better, let's pass memslots to all the __ functions.
Paolo
--
To unsubscribe from this list: send the line "unsubscri
On 05/06/2015 14:10, Radim Krčmář wrote:
> 2015-06-05 12:26+0200, Paolo Bonzini:
>> On 29/05/2015 21:23, Radim Krčmář wrote:
>>>>> +int kvm_vcpu_write_guest(struct kvm_vcpu *vcpu, gpa_t gpa, const void
>>>>> *data,
>
On 05/06/2015 12:50, Joerg Roedel wrote:
> > Great, I'll apply the patch.
>
> Gentle ping. I don't see the patch in the queue or next branches of the
> KVM tree yet. Do you plan to apply it for v4.2?
Fell through the cracks, sorry. I will apply it today.
Paolo
--
To unsubscribe from this list
On 29/05/2015 21:23, Radim Krčmář wrote:
>> > +int kvm_vcpu_write_guest(struct kvm_vcpu *vcpu, gpa_t gpa, const void
>> > *data,
>> > + unsigned long len)
>> > +{
>> > + gfn_t gfn = gpa >> PAGE_SHIFT;
>> > + int seg;
>> > + int offset = offset_in_page(gpa);
>> > + int ret;
> From the perspective of avoiding impacting other architectures, this is a
> good idea, but the naming seems strange in the x86 case. Having
> irqchip_in_kernel be "true" when the ioapic/pic are in userspace seems
> strange. Admittedly, the irqchip isn't a "real" concept on x86, so
> inventing a
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 variety of hardware these days than th
On 03/06/2015 21:02, Radim Krčmář wrote:
> > + if (r < 0)
> > + return;
>
> And if we fail to write it, is there other option than throwing an error
> to userspace? (Unset HF_SMM_MASK and pretend that nothing happened
> doesn't find much support in docs.)
Just do nothing, I guess.
On 04/06/2015 14:26, Radim Krčmář wrote:
> A list of minor stuff I noticed (you'll probably agree with [12/13]):
Good eyes. :) I'll fix at least these:
> [06/13] get_smstate can't be a valid C function, CAPS would be clearer
> [06/13] mangled whitespace in trace_kvm_enter_smm
> [08/13] '(u16)'
non-root mode.
Signed-off-by: Paolo Bonzini
---
Documentation/virtual/kvm/api.txt | 2 +-
arch/x86/include/uapi/asm/kvm.h | 2 +-
arch/x86/kvm/lapic.c | 13 -
arch/x86/kvm/lapic.h | 5 +
arch/x86/kvm/x86.c| 11 ++-
5 files chan
non-root mode.
Signed-off-by: Paolo Bonzini
---
Documentation/virtual/kvm/api.txt | 2 +-
arch/x86/include/uapi/asm/kvm.h | 2 +-
arch/x86/kvm/lapic.c | 13 -
arch/x86/kvm/lapic.h | 5 +
arch/x86/kvm/x86.c| 11 ++-
5 files chan
This was noticed by Radim while reviewing the implementation of
system management mode.
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/x86.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 79dde1656db6..bd6bcd54cd44 100644
--- a/arch/x86/kvm
On 04/06/2015 10:23, Xiao Guangrong wrote:
>>
>> So, why do you need to always use IPAT=0? Can patch 15 keep the current
>> logic for RAM, like this:
>>
>> if (is_mmio || kvm_arch_has_noncoherent_dma(vcpu->kvm))
>> ret = kvm_mtrr_get_guest_memory_type(vcpu, gfn) <<
>> V
On 04/06/2015 10:26, Xiao Guangrong wrote:
>>
>> CR0.CD is always 0 in both host and guest, i guess it's why we cleared
>> CR0.CD and CR0.NW in vmx_set_cr0().
>
> It reminds me that we should check guest CR0.CD before check guest MTRR
> and disable guest PAT if guest CR0.CD = 1.
I think it can
Malicious (or egregiously buggy) userspace can trigger it, but it
should never happen in normal operation.
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/lapic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/lapic.h b/arch/x86/kvm/lapic.h
index 71b150cae5f9
nt by default.
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/Kconfig | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
index 413a7bf9efbb..a0f06a5947c5 100644
--- a/arch/x86/kvm/Kconfig
+++ b/arch/x86/kvm/Kconfig
@@ -88,13 +
On 03/06/2015 21:02, Radim Krčmář wrote:
>> +r = kvm_write_guest(vcpu->kvm, vcpu->arch.smbase + 0xfe00, buf,
>> sizeof(buf));
>
> The state is saved in SMRAM, but we are accessing it using the non-SMM
> address space ... how did it pass testing?
> (Restore is using SMM address space, so I'm
On 02/06/2015 10:14, Christian Borntraeger wrote:
> git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git
> tags/kvm-s390-next-20150602
Pulled, thanks.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
Mor
On 03/06/2015 02:13, Steve Rutherford wrote:
> Hi All,
>
> I just sent out a new version of the patches that enable a split
> irqchip. I've tested them against Google's VMM, and the updated
> patches boot Windows and pass the KVM unit tests. It's mostly the
> same as before, with the tweaks sugg
On 03/06/2015 01:51, Steve Rutherford wrote:
> In order to enable userspace PIC support, the userspace PIC needs to
> be able to inject local interrupt requests.
>
> This adds the ioctl KVM_REQUEST_PIC_INJECTION and kvm exit
> KVM_EXIT_GET_EXTINT.
>
> The vm ioctl KVM_REQUEST_PIC_INJECTION make
On 03/06/2015 01:51, Steve Rutherford wrote:
> +static inline void kvm_arch_irq_routing_update(struct kvm *kvm)
> +{
> +}
Please add the static inline to all arches instead of putting it in
#ifndef __KVM_HAVE_IOAPIC. It's not related to the existence of an ioapic.
>
> +void kvm_arch_irq_routi
On 03/06/2015 01:51, Steve Rutherford wrote:
> Adds KVM_EXIT_IOAPIC_EOI which allows the kernel to EOI
> level-triggered IOAPIC interrupts.
>
> Uses a per VCPU exit bitmap to decide whether or not the IOAPIC needs
> to be informed (which is identical to the EOI_EXIT_BITMAP field used
> by modern
On 03/06/2015 01:51, Steve Rutherford wrote:
> First patch in a series which enables the relocation of the
> PIC/IOAPIC to userspace.
>
> Adds capability KVM_CAP_SPLIT_IRQCHIP;
>
> KVM_CAP_SPLIT_IRQCHIP enables the construction of LAPICs without the
> rest of the irqchip.
The documentation is
On 03/06/2015 04:12, Xiao Guangrong wrote:
>>
>> Perhaps just use type = MIN(type, curr_type), which also happens to get
>> WT vs. WB right? You can also add a
>>
>> BUILD_BUG_ON(MTRR_TYPE_WRTHROUGH > MTRR_TYPE_WRBACK);
>>
>> to ensure that the WT vs. WB precedence is correct.
>
> Only WT a
On 03/06/2015 04:56, Xiao Guangrong wrote:
>
>
> On 06/01/2015 05:36 PM, Paolo Bonzini wrote:
>>
>>
>> On 30/05/2015 12:59, Xiao Guangrong wrote:
>>> Currently guest MTRR is completely prohibited if cache snoop is
>>> supported on
>>> IOMM
On 01/06/2015 11:33, Paolo Bonzini wrote:
>> +looker->mem_type = looker->mtrr_state->fixed_ranges[index];
>> > + looker->start = fixed_mtrr_range_end_addr(seg, index);
>> > + return true;
> in mtrr_lookup_fixed_start is the same as this:
>
>
On 01/06/2015 13:42, Christian Borntraeger wrote:
> Am 01.06.2015 um 13:34 schrieb Paolo Bonzini:
>>
>>
>> On 01/06/2015 09:47, Christian Borntraeger wrote:
>>>
>>> 1: "disable", "guest", "disable again and save", "res
On 01/06/2015 09:47, Christian Borntraeger wrote:
>
> 1: "disable", "guest", "disable again and save", "restore to disable",
> "enable"
> and now it is
> 2: "disable", "guest", "enable"
> and with your patch it is
> 3: "disable", "guest", "enable", "disable, "enable"
>
> I assume that 3 and 1
On 01/06/2015 11:36, Paolo Bonzini wrote:
> Does this have a performance impact on shadow? Perhaps we could cache
> in struct kvm_arch_memory_slot whether the memslot is covered by MTRRs?
Nevermind, patch 15 answers my question.
Paolo
--
To unsubscribe from this list: send th
On 30/05/2015 12:59, Xiao Guangrong wrote:
> Currently guest MTRR is completely prohibited if cache snoop is supported on
> IOMMU (!noncoherent_dma) and host does the emulation based on the knowledge
> from host side, however, host side is not the good point to know
> what the purpose of guest is
On 30/05/2015 12:59, Xiao Guangrong wrote:
> +struct mtrr_looker {
> + /* input fields. */
> + struct kvm_mtrr *mtrr_state;
> + u64 start;
> + u64 end;
s/looker/iter/ or s/looker/lookup/
> +static void mtrr_lookup_start(struct mtrr_looker *looker)
> +{
> + looker->mem_type =
On 30/05/2015 12:59, Xiao Guangrong wrote:
> Sort all valid variable MTRRs based on its base address, it will help us to
> check a range to see if it's fully contained in variable MTRRs
>
> Signed-off-by: Xiao Guangrong
> ---
> arch/x86/include/asm/kvm_host.h | 3 +++
> arch/x86/kvm/mtrr.c
On 30/05/2015 12:59, Xiao Guangrong wrote:
> This table summarizes the information of fixed MTRRs and introduce some APIs
> to abstract its operation which helps us to clean up the code and will be
> used in later patches
>
> Signed-off-by: Xiao Guangrong
> ---
> arch/x86/kvm/mtrr.c | 191
> +
On 30/05/2015 12:59, Xiao Guangrong wrote:
> - kvm_mtrr_get_guest_memory_type() only checks one page in MTRRs so that
>it's unnecessary to check to see if the range is partially covered in
>MTRR
>
> - optimize the check of overlap memory type and add some comments to explain
>the p
On 30/05/2015 12:59, Xiao Guangrong wrote:
> Use union definition to avoid the decode/code workload and drop all the
> hard code
>
> Signed-off-by: Xiao Guangrong
> ---
> arch/x86/include/asm/kvm_host.h | 12 ++--
> arch/x86/kvm/mtrr.c | 19 ---
> 2 files ch
On 29/05/2015 21:03, Radim Krčmář wrote:
> I found a corner case that doesn't fit any specific patch:
>
> We allow INIT while in SMM. This brings some security complications as
> we also don't reset hflags (another long standing bug?), but we don't
> really need to because INIT in SMM is agains
On 27/05/2015 19:05, Paolo Bonzini wrote:
> This patch includes changes to the external API for SMM support.
> All the changes are predicated by the availability of a new
> capability, KVM_CAP_X86_SMM, which is added at the end of the
> patch series.
>
> Signed-off-by: Paolo
On 28/05/2015 03:47, Marcelo Tosatti wrote:
> Initialize kvmclock base, on kvmclock system MSR write time,
> so that the guest sees kvmclock counting from zero.
>
> This matches baremetal behaviour when kvmclock in guest
> sets sched clock stable.
>
> Signed-off-by: Marcelo Tosatti
>
> ---
>
On 28/05/2015 03:46, Marcelo Tosatti wrote:
> + flags = PVCLOCK_COUNTS_FROM_ZERO;
If the KVM_FEATURE_CLOCKSOURCE_STABLE_BIT bit is not set, we cannot
trust flags at all. So let's just do...
> if (kvm_para_has_feature(KVM_FEATURE_CLOCKSOURCE_STABLE_BIT))
> - pvclock_set_fl
801 - 900 of 4462 matches
Mail list logo
