Re: [PATCH v2] KVM: arm/arm64: BUG FIX: Do not inject spurious interrupts

On Fri, Sep 25, 2015 at 05:00:29PM +0300, Pavel Fedin wrote: > Commit 71760950bf3dc796e5e53ea3300dec724a09f593 > ("arm/arm64: KVM: add a common vgic_queue_irq_to_lr fn") introduced > vgic_queue_irq_to_lr() function with additional vgic_dist_irq_is_pending() > check before setting LR_STATE_PENDING

Re: [PATCH v4 10/15] KVM: arm: implement world switch for debug registers

On Tue, Sep 29, 2015 at 01:32:35PM +0800, Zhichao Huang wrote: > > > On 2015/9/2 22:53, Christoffer Dall wrote: > >> +/* Reads cp14 registers from hardware. > >> + * Writes cp14 registers in-order to the CP14 struct pointed to by r10 > >> + * > >> + * Assumes vcpu pointer in vcpu reg > >> + * >

Re: [PATCH v4 15/15] KVM: arm: enable trapping of all debug registers

On Tue, Sep 29, 2015 at 01:41:45PM +0800, Zhichao Huang wrote: > > > On 2015/9/3 0:08, Christoffer Dall wrote: > > On Mon, Aug 10, 2015 at 09:26:07PM +0800, Zhichao Huang wrote: > >> Enable trapping of the debug registers unconditionally, allowing guests to > >> use the debug infrastructure. >

Re: [PATCH] iommu/s390: add iommu api for s390 pci devices

Hi Gerald, thanks for your patch. It looks pretty good and addresses my previous review comments. I have a few questions, first one is how this operates with DMA-API on s390. Is there a seperate DMA-API implementation besides the IOMMU-API one for PCI devices? My other question is inline: On

Inconsistent guest OS disk size compared to volume.img size

I have looked all over the internet but I can not even find a reference to this issue. I have installed the following on Linux Mint 17.1 QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.19), Fabrice Bellard On that, I have created a Ubuntu 14.04.3 LTS guest and created a storage volume

Re: [PATCH v4 07/11] KVM: arm/arm64: vgic: Allow HW interrupts to be queued to a guest

On Wed, Sep 23, 2015 at 06:55:04PM +0100, Andre Przywara wrote: > Salut Marc, > > I know that this patch is already merged, but > > On 07/08/15 16:45, Marc Zyngier wrote: > > diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c > > index 51c9900..9d009d2 100644 > ... > > @@ -1364,6

Re: [PATCH] x86: Use entire page for the per-cpu GDT only if paravirt-enabled

* Denys Vlasenko wrote: > On 09/28/2015 09:58 AM, Ingo Molnar wrote: > > > > * Denys Vlasenko wrote: > > > >> On 09/26/2015 09:50 PM, H. Peter Anvin wrote: > >>> NAK. We really should map the GDT read-only on all 64 bit systems, > >>> since we can't

Re: [PATCH] KVM: nVMX: expose VPID capability to L1

On 29/09/2015 03:15, Wanpeng Li wrote: >>> >> Hi Wanpeng, the comment above is about invept, but the same applies >> applies to invvpid. We can set only VMX_VPID_EXTENT_GLOBAL_CONTEXT_BIT. > > Agreed. I see the patch has already in kvm/queue, if I need to send out > another patch or you can

[PATCH][v2] KVM: PPC: e6500: allow odd powers of 2K TLB1 sizes

Book-E MMUv2 present in e6500 cores supports powers of 2K page sizes while older MMUv1 cores support only powers of 4K page sizes, or in other words the LSB of TSIZE on MMUv1 is always 0. On MMUv2 allow power of 2K pages by not stripping the LSB of the TSIZE field. This gives better HW TLB1 usage

[PATCH][v2] KVM: PPC: e6500: allow odd powers of 2K TLB1 sizes

Book-E MMUv2 present in e6500 cores supports powers of 2K page sizes while older MMUv1 cores support only powers of 4K page sizes, or in other words the LSB of TSIZE on MMUv1 is always 0. On MMUv2 allow power of 2K pages by not stripping the LSB of the TSIZE field. This gives better HW TLB1 usage

[Bug 104271] Boot crashes on Lenovo W520 with KVM and Discrete Graphic enabled in BIOS

https://bugzilla.kernel.org/show_bug.cgi?id=104271 Hans Streibel changed: What|Removed |Added CC|

[PATCH v2] KVM: nVMX: expose VPID capability to L1

Expose VPID capability to L1. Signed-off-by: Wanpeng Li --- v1 -> v2: * set only VMX_VPID_EXTENT_GLOBAL_CONTEXT_BIT arch/x86/kvm/vmx.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c

qemu 2.4 machine + kernel 4.2 + kvm : freeze & cpu 100% at start on some hardware (maybe KVM_CAP_X86_SMM related)

Hi, I'm currently implementing qemu 2.4 for proxmox hypervisors, and a lot of users have reported qemu freeze with cpu at 100% when starting. Connecting with vnc display : "qemu guest has not initialized the display yet" Similar bug report here :

Re: [PATCH v2] KVM: nVMX: expose VPID capability to L1

On 29/09/2015 04:55, Wanpeng Li wrote: > Expose VPID capability to L1. > > Signed-off-by: Wanpeng Li > --- > v1 -> v2: > * set only VMX_VPID_EXTENT_GLOBAL_CONTEXT_BIT Thanks. I've checked more thoroughly your implementation against the SDM now, and there are a few

Re: [PATCH v2] KVM: nVMX: expose VPID capability to L1

On 9/29/15 6:39 PM, Paolo Bonzini wrote: On 29/09/2015 04:55, Wanpeng Li wrote: Expose VPID capability to L1. Signed-off-by: Wanpeng Li --- v1 -> v2: * set only VMX_VPID_EXTENT_GLOBAL_CONTEXT_BIT Thanks. I've checked more thoroughly your implementation against the

Re: [PATCH v2 7/8] arm/arm64: KVM: Rework the arch timer to use level-triggered semantics

On Wed, Sep 23, 2015 at 06:44:21PM +0100, Andre Przywara wrote: > Hi Christoffer, > > > diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c > > index 9ed8d53..f4ea950 100644 > > --- a/virt/kvm/arm/vgic.c > > +++ b/virt/kvm/arm/vgic.c > > @@ -1422,34 +1422,43 @@ static bool

[PATCH v3 0/8] Rework architected timer and forwarded IRQs handling

The architected timer integration with the VGIC had some shortcomings in that certain guest operations weren't fully supported. This series tries to address these problems in providing level-triggered semantics for the arch timer and VGIC integration and seeks to clarify the behavior when

[PATCH v3 7/8] arm/arm64: KVM: Rework the arch timer to use level-triggered semantics

The arch timer currently uses edge-triggered semantics in the sense that the line is never sampled by the vgic and lowering the line from the timer to the vgic doesn't have any effect on the pending state of virtual interrupts in the vgic. This means that we do not support a guest with the

[PATCH v3 2/8] arm/arm64: KVM: arch_timer: Only schedule soft timer on vcpu_block

We currently schedule a soft timer every time we exit the guest if the timer did not expire while running the guest. This is really not necessary, because the only work we do in the timer work function is to kick the vcpu. Kicking the vcpu does two things: (1) If the vpcu thread is on a

[PATCH v3 5/8] arm/arm64: KVM: Use appropriate define in VGIC reset code

We currently initialize the SGIs to be enabled in the VGIC code, but we use the VGIC_NR_PPIS define for this purpose, instead of the the more natural VGIC_NR_SGIS. Change this slightly confusing use of the defines. Note: This should have no functional change, as both names are defined to the

[PATCH v3 6/8] arm/arm64: KVM: Add forwarded physical interrupts documentation

Forwarded physical interrupts on arm/arm64 is a tricky concept and the way we deal with them is not apparently easy to understand by reading various specs. Therefore, add a proper documentation file explaining the flow and rationale of the behavior of the vgic. Some of this text was contributed

[PATCH v3 8/8] arm/arm64: KVM: Support edge-triggered forwarded interrupts

We mark edge-triggered interrupts with the HW bit set as queued to prevent the VGIC code from injecting LRs with both the Active and Pending bits set at the same time while also setting the HW bit, because the hardware does not support this. However, this means that we must also clear the queued

[PATCH v3 3/8] arm/arm64: KVM: vgic: Factor out level irq processing on guest exit

Currently vgic_process_maintenance() processes dealing with a completed level-triggered interrupt directly, but we are soon going to reuse this logic for level-triggered mapped interrupts with the HW bit set, so move this logic into a separate static function. Probably the most scary part of this

[PATCH v3 1/8] KVM: Add kvm_arch_vcpu_{un}blocking callbacks

Some times it is useful for architecture implementations of KVM to know when the VCPU thread is about to block or when it comes back from blocking (arm/arm64 needs to know this to properly implement timers, for example). Therefore provide a generic architecture callback function in line with what

[PATCH v3 4/8] arm/arm64: KVM: Implement GICD_ICFGR as RO for PPIs

The GICD_ICFGR allows the bits for the SGIs and PPIs to be read only. We currently simulate this behavior by writing a hardcoded value to the register for the SGIs and PPIs on every write of these bits to the register (ignoring what the guest actually wrote), and by writing the same value as the

[PATCH kvmtool] kvmtool: expose the TSC Deadline Timer feature to the guest

From: Arjan van de Ven with the TSC deadline timer feature, we don't need to calibrate the apic timers anymore, which saves more than 100 milliseconds of boot time. Signed-off-by: Arjan van de Ven Signed-off-by: Dimitri John Ledkov

[PATCH kvmtool] Skip a few messages by default: command line args; flat binary; earlyprintk.

The partial command line args & earlyprintk=serial are still enabled in the debug mode. Warning that a flat binary kernel image is attemped to be loaded is completely dropped. These are not that informative, once one is past intial debugging, and only polute the console. Signed-off-by: Dimitri

Re: [PATCH 3/3] kvm-all: notice KVM of vcpu's TSC rate after migration

On Tue, Sep 29, 2015 at 03:02:07PM -0300, Eduardo Habkost wrote: > On Tue, Sep 29, 2015 at 11:43:34AM +0800, Haozhong Zhang wrote: > > On Mon, Sep 28, 2015 at 01:37:34PM -0300, Eduardo Habkost wrote: > > > On Mon, Sep 28, 2015 at 01:38:31PM +0800, Haozhong Zhang wrote: > [...] > > > > static void

Re: [Qemu-devel] [PATCH 1/3] target-i386: add a subsection of vcpu's TSC rate in vmstate_x86_cpu

On Tue, Sep 29, 2015 at 08:00:13PM +0100, Dr. David Alan Gilbert wrote: > * Haozhong Zhang (haozhong.zh...@intel.com) wrote: > > The newly added subsection 'vmstate_tsc_khz' in this patch results in > > vcpu's TSC rate being saved on the source machine and loaded on the > > target machine during

Re: [PATCH] x86: Use entire page for the per-cpu GDT only if paravirt-enabled

No, it is a natural result of an implemention which treats setting the A bit as an abnormal flow (e.g. in microcode as opposed to hardware). On September 29, 2015 7:11:59 PM PDT, ebied...@xmission.com wrote: >"H. Peter Anvin" writes: > >> On 09/29/2015 06:20 PM, Eric W.

Re: [PATCH] x86: Use entire page for the per-cpu GDT only if paravirt-enabled

"H. Peter Anvin" writes: > On 09/29/2015 06:20 PM, Eric W. Biederman wrote: >> Linus Torvalds writes: >> >>> On Tue, Sep 29, 2015 at 1:35 PM, Andy Lutomirski >>> wrote: Does anyone know what happens if you stick a

Re: [PATCH] x86: Use entire page for the per-cpu GDT only if paravirt-enabled

On 09/29/2015 06:20 PM, Eric W. Biederman wrote: > Linus Torvalds writes: > >> On Tue, Sep 29, 2015 at 1:35 PM, Andy Lutomirski wrote: >>> >>> Does anyone know what happens if you stick a non-accessed segment in >>> the GDT, map the GDT RO,

Re: [PATCH] x86: Use entire page for the per-cpu GDT only if paravirt-enabled

Linus Torvalds writes: > On Tue, Sep 29, 2015 at 1:35 PM, Andy Lutomirski wrote: >> >> Does anyone know what happens if you stick a non-accessed segment in >> the GDT, map the GDT RO, and access it? > > You should get a #PF, as you guess, but

Re: [PATCH] x86: Use entire page for the per-cpu GDT only if paravirt-enabled

On Tue, Sep 29, 2015 at 1:35 PM, Andy Lutomirski wrote: > > Does anyone know what happens if you stick a non-accessed segment in > the GDT, map the GDT RO, and access it? You should get a #PF, as you guess, but go ahead and test it if you want to make sure. We do something

Re: [PATCH 3/3] kvm-all: notice KVM of vcpu's TSC rate after migration

On Tue, Sep 29, 2015 at 11:43:34AM +0800, Haozhong Zhang wrote: > On Mon, Sep 28, 2015 at 01:37:34PM -0300, Eduardo Habkost wrote: > > On Mon, Sep 28, 2015 at 01:38:31PM +0800, Haozhong Zhang wrote: [...] > > > static void do_kvm_cpu_synchronize_post_init(void *arg) > > > { > > > CPUState

Re: [PATCH] x86: Use entire page for the per-cpu GDT only if paravirt-enabled

On Tue, Sep 29, 2015 at 10:50 AM, Linus Torvalds wrote: > On Tue, Sep 29, 2015 at 1:35 PM, Andy Lutomirski wrote: >> >> Does anyone know what happens if you stick a non-accessed segment in >> the GDT, map the GDT RO, and access it? > > You

Re: [PATCH] x86: Use entire page for the per-cpu GDT only if paravirt-enabled

SGDT would be easy to use, and it is logical that it is faster since it reads an internal register. SIDT does too but unlike the GDT has a secondary limit (it can never be larger than 4096 bytes) and so all limits in the range 4095-65535 are exactly equivalent. Anything that causes a write to

Re: [PATCH] x86: Use entire page for the per-cpu GDT only if paravirt-enabled

On Sep 29, 2015 2:01 AM, "Ingo Molnar" wrote: > > > * Denys Vlasenko wrote: > > > On 09/28/2015 09:58 AM, Ingo Molnar wrote: > > > > > > * Denys Vlasenko wrote: > > > > > >> On 09/26/2015 09:50 PM, H. Peter Anvin wrote: > > >>> NAK.

Re: [PATCH] x86: Use entire page for the per-cpu GDT only if paravirt-enabled

On Tue, Sep 29, 2015 at 11:18 AM, H. Peter Anvin wrote: > SGDT would be easy to use, and it is logical that it is faster since it reads > an internal register. SIDT does too but unlike the GDT has a secondary limit > (it can never be larger than 4096 bytes) and so all limits in

Re: [PATCH] x86: Use entire page for the per-cpu GDT only if paravirt-enabled

Ugh. Didn't realize that. On September 29, 2015 11:22:04 AM PDT, Andy Lutomirski wrote: >On Tue, Sep 29, 2015 at 11:18 AM, H. Peter Anvin wrote: >> SGDT would be easy to use, and it is logical that it is faster since >it reads an internal register. SIDT

Re: [Qemu-devel] [PATCH 1/3] target-i386: add a subsection of vcpu's TSC rate in vmstate_x86_cpu

* Haozhong Zhang (haozhong.zh...@intel.com) wrote: > The newly added subsection 'vmstate_tsc_khz' in this patch results in > vcpu's TSC rate being saved on the source machine and loaded on the > target machine during the migration. > > Signed-off-by: Haozhong Zhang Hi,

Re: [PATCH] x86: Use entire page for the per-cpu GDT only if paravirt-enabled

On 09/29/2015 11:02 AM, Andy Lutomirski wrote: > On Tue, Sep 29, 2015 at 10:50 AM, Linus Torvalds > wrote: >> On Tue, Sep 29, 2015 at 1:35 PM, Andy Lutomirski wrote: >>> >>> Does anyone know what happens if you stick a non-accessed segment in