On 26/06/2015 02:26, Steve Rutherford wrote:
Implemented a basic version of this, and ran into some potential
issues with this strategy. Supporting PIC masking/unmasking by the
CPU/APIC means that either:
A) PIC interrupts need to be bufferable in the kernel (with some way
of comparing
On 25/06/2015 12:25, Denis V. Lunev wrote:
Paolo, Gleb,
we are very sensitive on the first patch. Could you
suggest which tree we should be based on?
For now I think that we should use
https://git.kernel.org/cgit/virt/kvm/kvm.git/
but the branch here could also matters.
You can
On 25/06/2015 18:12, Andrew Jones wrote:
spinlock torture tests made it clear that checking mmu_enabled()
every time we call spin_lock is a bad idea. As most tests will
want the MMU enabled the entire time, then just hard code
mmu_enabled() to true. Tests that want to play with the MMU can
On 24/06/2015 07:42, Wu, Feng wrote:
Do you mean we don't use bitfields at all, or the following format is
acceptable, in which, we use bitfileds as less as possible?
union {
struct
{
u16 on : 1, /* bit 256 - Outstanding Notification */
sn
On 23/06/2015 00:08, John Nielsen wrote:
I’m resurrecting an old thread since I haven’t heard anything in a
while. Has anyone looked in to the KVM+apicv bug documented above as
well as here:
https://bugs.launchpad.net/qemu/+bug/1329956 ?
If appropriate, where should I go to file a KVM bug
On 24/06/2015 17:57, Bandan Das wrote:
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
On 24/06/2015 18:33, Linus Torvalds wrote:
On Tue, Jun 23, 2015 at 9:49 AM, Paolo Bonzini pbonz...@redhat.com wrote:
There are some x86 conflicts, one with the rc8 pull request and
the rest with Ingo's FPU rework.
Hmm. I'm dropping the fx_init(..init_state) changes from you pull
request
On 24/06/2015 19:07, John Nielsen wrote:
Unfortunately I no longer have the test environment I used a few days
ago to reproduce this issue so I can’t verify the software versions
that were in use. It’s possible I was mistaken about the kernel
version (I thought it was 4.0.4). Perhaps it
On 11/06/2015 12:51, Feng Wu wrote:
+ union {
+ struct {
+ /* bit 256 - Outstanding Notification */
+ u64 on : 1,
+ /* bit 257 - Suppress Notification */
+ sn
On 22/06/2015 13:20, Christian Borntraeger wrote:
From: Jens Freimann jf...@linux.vnet.ibm.com
commit 6d3da24141 (KVM: s390: deliver floating interrupts in order
of priority) introduced a regression for the reset handling.
We don't clear the bitmap of pending floating interrupts
and
On 12/06/2015 16:51, Alex Williamson wrote:
The code below can't get to this function without
__KVM_HAVE_ARCH_KVM_VFIO_POST, but this seems like it should return an
error if not implemented.
kvm_arch_vfio_update_pi_irte() is called by kvm_vfio_control_pi(), if we
remove the
: Fix update RCX/RDI/RSI on REP-string
KVM: x86: Fix zero iterations REP-string
Nicholas Krause (1):
kvm: x86: Make functions that have no external callers static
Paolo Bonzini (38):
KVM: booke: use __kvm_guest_exit
KVM: x86: tweak types of fields in kvm_lapic_irq
KVM
On 11/06/2015 12:51, Feng Wu wrote:
- vcpu-arch.mp_state = KVM_MP_STATE_HALTED;
+ /* Handle posted-interrupt when vCPU is to be halted */
+ if (!kvm_x86_ops-pi_pre_block ||
+ (kvm_x86_ops-pi_pre_block
This condition is unnecessary.
Paolo
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 m...@ellerman.id.au
---
powerpc/spapr.h | 25 -
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 m...@ellerman.id.au
---
powerpc/spapr.h | 25 -
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;
hv-hv_crash_ctl =
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 patchset is used
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.
Hm, not sure whether it is.
It
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, sorry for the delay. Your
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 heard anything in
On 23/06/2015 12:31, Andre Przywara wrote:
Because it's not part of the kernel API, never was, still isn't.
Technically it may not - if I get this correctly it is more a platform
API defined by the architecture, like ACPI or PSCI on ARM.
But if I get this correctly Linux re-uses those
On 23/06/2015 12:31, Andre Przywara wrote:
Because it's not part of the kernel API, never was, still isn't.
Technically it may not - if I get this correctly it is more a platform
API defined by the architecture, like ACPI or PSCI on ARM.
But if I get this correctly Linux re-uses those
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
on_crashrestart/on_crash
Thus it looks like without libvirt help the guest will stuck
in
-by: Andrey Smetanin asmeta...@virtuozzo.com
Signed-off-by: Denis V. Lunev d...@openvz.org
CC: Paolo Bonzini pbonz...@redhat.com
CC: Gleb Natapov g...@kernel.org
---
arch/x86/kvm/hyperv.c | 17 +
arch/x86/kvm/hyperv.h | 2 +-
arch/x86/kvm/x86.c| 3 ++-
3 files changed, 12
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_panicked
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);
+}
+
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,
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.
It should
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;
list_add_tail(cur-node, tmp-node);
If so, can you
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 value
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
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 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
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 we detect
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 asmeta...@virtuozzo.com
Windows 2012 guests can notify hypervisor about occurred guest crash
(Windows bugcheck(BSOD
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
takes a reference to the memory region and address_space_unmap
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
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 =
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?
Because
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 to
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 to
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
mmap(MAP_NORESERVE), which _does_ have the effect of making
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
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 pbonz...@redhat.com wrote:
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
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
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 10:05, Michael S. Tsirkin wrote:
No, only destruction
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 in range
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,
whatever. We cannot audit all address_space_map uses
On 19/06/2015 18:45, Michael S. Tsirkin wrote:
user guest QEMU
start I/O
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 uses RCU
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 decision upto users instead of making them live
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 vhost
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.
Those
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 will also
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:
On 16/06/2015 13:33, Kevin Mulvey wrote:
fix brace spacing
Signed-off-by: Kevin Mulvey kmul...@linux.com
---
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
---
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
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 pbonz...@redhat.com
Cc: Radim Krcmar rkrc...@redhat.com
Cc: Marcelo Tosatti mtosa...@redhat.com
Cc
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 role word. The same trick is used
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 this list:
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 here?
Because the
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 Intel's
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
to
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 pbonz...@redhat.com
Cc: Radim Krcmar rkrc
the extra check is
unnecessary.
Or more simply, KVM (host-side) requires the TSC to exist.
Acked-by: Paolo Bonzini pbonz...@redhat.com
(Off-topic, but the whole KVM clock host implementation is gross.
IMO it should be rewritten.)
Signed-off-by: Andy Lutomirski l...@kernel.org
---
arch/x86
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...
Same
Smetanin asmeta...@virtuozzo.com
Signed-off-by: Denis V. Lunev d...@openvz.org
CC: Gleb Natapov g...@kernel.org
CC: Paolo Bonzini pbonz...@redhat.com
---
arch/x86/include/uapi/asm/hyperv.h | 10 +
arch/x86/kvm/Makefile | 2 +-
arch/x86/kvm/mshv.c| 84
...@openvz.org
CC: Gleb Natapov g...@kernel.org
CC: Paolo Bonzini pbonz...@redhat.com
---
include/sysemu/sysemu.h| 2 ++
kvm-all.c | 8
linux-headers/asm-x86/hyperv.h | 2 ++
linux-headers/linux/kvm.h | 11 +++
target-i386/cpu-qom.h
On 15/06/2015 10:55, Xiao Guangrong wrote:
It gets the range for the specified variable MTRR
Signed-off-by: Xiao Guangrong guangrong.x...@linux.intel.com
---
arch/x86/kvm/mtrr.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/mtrr.c
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:30, Michael S. Tsirkin wrote:
Meanwhile old tools
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 guangrong.x...@linux.intel.com
---
arch/x86/include/asm/kvm_host.h | 3 ++
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 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 there will be likely one tap interface, and I
suspect
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 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
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,
to allow because of emulated APIC */
} else if (function == 0x8001 reg == R_EDX) {
/* On Intel, kvm returns cpuid according to the Intel spec,
* so add missing bits according to the AMD spec:
Acked-by: Paolo Bonzini pbonz...@redhat.com
Paolo
--
To unsubscribe from
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 new
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;
+
+ while ((seg =
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 unsubscribe
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,
+ unsigned long len)
+{
| [...]
+}
(There is no need to pass vcpu
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 update
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);
Even better, let's pass memslots to all
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)' or
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 the
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. If this
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 guessing
by default.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
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
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 be done
This was noticed by Radim while reviewing the implementation of
system management mode.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
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
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)
mode.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
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
mode.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
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
Malicious (or egregiously buggy) userspace can trigger it, but it
should never happen in normal operation.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
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
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 and WB are
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
IOMMU (!noncoherent_dma) and host does the emulation based on the
knowledge
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 not
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 suggested
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 makes a
801 - 900 of 4532 matches
Mail list logo
