On Tue, Mar 24, 2015 at 12:22:25PM +1100, David Gibson wrote:
>On Tue, Mar 24, 2015 at 09:47:54AM +1100, Gavin Shan wrote:
>> On Mon, Mar 23, 2015 at 10:14:59AM -0600, Alex Williamson wrote:
>> >On Mon, 2015-03-23 at 16:20 +1100, Gavin Shan wrote:
>> >> On Mon, Mar 23, 2015 at 04:10:20PM +1100, Dav
On Tue, Mar 24, 2015 at 09:47:54AM +1100, Gavin Shan wrote:
> On Mon, Mar 23, 2015 at 10:14:59AM -0600, Alex Williamson wrote:
> >On Mon, 2015-03-23 at 16:20 +1100, Gavin Shan wrote:
> >> On Mon, Mar 23, 2015 at 04:10:20PM +1100, David Gibson wrote:
> >> >On Mon, Mar 23, 2015 at 04:03:59PM +1100, G
As thats more indicative of the variables usage.
Suggested by Andy Lutomirski.
Signed-off-by: Marcelo Tosatti
diff --git a/arch/x86/include/asm/pvclock.h b/arch/x86/include/asm/pvclock.h
index 25b1cc0..1c1b474 100644
--- a/arch/x86/include/asm/pvclock.h
+++ b/arch/x86/include/asm/pvclock.h
@@
On Thu, Mar 19, 2015 at 09:52:41PM +0100, Radim Krčmář wrote:
> An overhead from function call is not appropriate for its size and
> frequency of execution.
>
> Suggested-by: Paolo Bonzini
> Signed-off-by: Radim Krčmář
> ---
> I'm not very fond of that smp_rmb(): there is no real synchronizati
On Wed, Mar 18, 2015 at 12:43:58PM +0100, Christian Borntraeger wrote:
> Paolo, Marcelo,
>
> here is the followup pull request. As Marcelo has not yet pushed out
> queue or next to git.kernel.org, this request is based on the previous
> s390 pull request and should merge without conflicts.
>
> Fo
On Mon, Mar 23, 2015 at 4:21 PM, Marcelo Tosatti wrote:
>
> The following point:
>
> 2. per-CPU pvclock time info is updated if the
>underlying CPU changes.
>
> Is not true anymore since "KVM: x86: update pvclock area conditionally,
> on cpu migration".
>
> Add task migration notificat
On Wed, Mar 18, 2015 at 07:38:22PM +0100, Radim Krčmář wrote:
> kvm_ioapic_update_eoi() wasn't called if directed EOI was enabled.
> We need to do that for irq notifiers. (Like with edge interrupts.)
>
> Fix it by skipping EOI broadcast only.
>
> Bug: https://bugzilla.kernel.org/show_bug.cgi?id=
The following point:
2. per-CPU pvclock time info is updated if the
underlying CPU changes.
Is not true anymore since "KVM: x86: update pvclock area conditionally,
on cpu migration".
Add task migration notification back.
Problem noticed by Andy Lutomirski.
Signed-off-by: Marcelo To
On Mon, Mar 23, 2015 at 10:14:59AM -0600, Alex Williamson wrote:
>On Mon, 2015-03-23 at 16:20 +1100, Gavin Shan wrote:
>> On Mon, Mar 23, 2015 at 04:10:20PM +1100, David Gibson wrote:
>> >On Mon, Mar 23, 2015 at 04:03:59PM +1100, Gavin Shan wrote:
>> >> On Mon, Mar 23, 2015 at 02:43:03PM +1100, Dav
On 03/23/2015 03:13 PM, Radim Krčmář wrote:
> 2015-03-20 11:50-0600, James Sullivan:
>> On 03/20/2015 09:22 AM, James Sullivan wrote:
>>> On 03/20/2015 09:15 AM, Radim Krčmář wrote:
2015-03-19 16:51-0600, James Sullivan:
> I played around with native_compose_msi_msg and discovered the foll
On Mon, Mar 23, 2015 at 5:58 PM, Andre Przywara wrote:
> This series converts the VGIC MMIO handling routines to the generic
> kvm_io_bus framework. The framework is needed for the ioeventfd
> functionality, some people on the list wanted to see the VGIC
> converted over to use it, too.
> Beside f
On Mon, Mar 23, 2015 at 5:58 PM, Andre Przywara wrote:
>
> Currently we have struct kvm_exit_mmio for encapsulating MMIO abort
> data to be passed on from syndrome decoding all the way down to the
> VGIC register handlers. Now as we switch the MMIO handling to be
> routed through the KVM MMIO bus,
2015-03-20 11:50-0600, James Sullivan:
> On 03/20/2015 09:22 AM, James Sullivan wrote:
> > On 03/20/2015 09:15 AM, Radim Krčmář wrote:
> >> 2015-03-19 16:51-0600, James Sullivan:
> >>> I played around with native_compose_msi_msg and discovered the following:
> >>>
> >>> * dm=0, rh=0 => Physical Des
From: Jan Kiszka
If the guest CPU is supposed to support rdtscp and the host has rdtscp
enabled in the secondary execution controls, we can also expose this
feature to L1. Just extend nested_vmx_exit_handled to properly route
EXIT_REASON_RDTSCP.
Signed-off-by: Jan Kiszka
---
Changes in v3:
-
Jan Kiszka writes:
> On 2015-03-23 18:01, Bandan Das wrote:
>> Jan Kiszka writes:
>> ...
>>> --- a/arch/x86/kvm/vmx.c
>>> +++ b/arch/x86/kvm/vmx.c
>>> @@ -2467,6 +2467,7 @@ static void nested_vmx_setup_ctls_msrs(struct
>>> vcpu_vmx *vmx)
>>> vmx->nested.nested_vmx_secondary_ctls_low = 0;
>>
On 2015-03-23 18:01, Bandan Das wrote:
> Jan Kiszka writes:
> ...
>> --- a/arch/x86/kvm/vmx.c
>> +++ b/arch/x86/kvm/vmx.c
>> @@ -2467,6 +2467,7 @@ static void nested_vmx_setup_ctls_msrs(struct vcpu_vmx
>> *vmx)
>> vmx->nested.nested_vmx_secondary_ctls_low = 0;
>> vmx->nested.nested_vmx_
On 3/23/15, Stefan Hajnoczi wrote:
> I have CCed the libvirt mailing list, since KVM is a component here but
> your question seems to be mainly about libvirt, virt-manager,
> virt-install, etc.
Apologies for posting to the wrong list, I assumed it would be KVM
related as the guest could run but c
As there is logic to deal with the difference between edge and level
triggered interrupts in the kernel we must ensure it knows the
configuration of the IRQs before we restore the pending state.
Signed-off-by: Alex Bennée
Acked-by: Christoffer Dall
diff --git a/hw/intc/arm_gic_kvm.c b/hw/intc/a
From: Peter Maydell
The AArch64 SPSR_EL1 register is architecturally mandated to
be mapped to the AArch32 SPSR_svc register. This means its
state should live in QEMU's env->banked_spsr[1] field.
Correct the various places in the code that incorrectly
put it in banked_spsr[0].
Signed-off-by: Pete
I was getting very confused about the duplication of state so wanted to
make it explicit.
Signed-off-by: Alex Bennée
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 083211c..6dc1799 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -155,6 +155,11 @@ typedef struct CPUARMState {
The current code was negatively indexing the cpu state array and not
synchronizing banked spsr register state with the current mode's spsr
state, causing occasional failures with migration.
Some munging is done to take care of the aarch64 mapping and also to
ensure the most current value of the sp
Hi,
Following some review comments (and a patch) from Peter I've re-spun
this series:
v5
- Added Peter's SPSR_EL1 state fix for architectural mapping
- As a result SPSR save/restore no longer does munge
- FP register save/restore re-done to deal float128 mapping
- Some minor [ spaces ] ad
For migration to work we need to sync all of the register state. This is
especially noticeable when GCC starts using FP registers as spill
registers even with integer programs.
Signed-off-by: Alex Bennée
---
v4:
- fixed merge conflicts
- rm superfluous reg.id++
v5:
- use interim float128
This adds the saving and restore of the current Multi-Processing state
of the machine. While the KVM_GET/SET_MP_STATE API exposes a number of
potential states for x86 we only use two for ARM. Either the process is
running or not. We then save this state into the cpu_powered TCG state
to avoid chang
Jan Kiszka writes:
...
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -2467,6 +2467,7 @@ static void nested_vmx_setup_ctls_msrs(struct vcpu_vmx
> *vmx)
> vmx->nested.nested_vmx_secondary_ctls_low = 0;
> vmx->nested.nested_vmx_secondary_ctls_high &=
> SECONDAR
From: Mahesh Salgaonkar
commit id 2ba9f0d changed CONFIG_KVM_BOOK3S_64_HV to tristate to allow
HV/PR bits to be built as modules. But the MCE code still depends on
CONFIG_KVM_BOOK3S_64_HV which is wrong. When user selects
CONFIG_KVM_BOOK3S_64_HV=m to build HV/PR bits as a separate module the
rele
From: Mahesh Salgaonkar
For the machine check interrupt that happens while we are in the guest,
kvm layer attempts the recovery, and then delivers the machine check interrupt
directly to the guest if recovery fails. On successful recovery we go back to
normal functioning of the guest. But there c
hello All,
I know the issue is related to libvirt,but i dont know
where to ask.
i have centos 6.6 running KVM as compute node in openstack icehouse
when i try to attach volume to instance it shows
2596: error : virStorageFileGetMetadataRecurse:952 : Failed to open
file '/dev/mapper
On Mon, 2015-03-23 at 16:20 +1100, Gavin Shan wrote:
> On Mon, Mar 23, 2015 at 04:10:20PM +1100, David Gibson wrote:
> >On Mon, Mar 23, 2015 at 04:03:59PM +1100, Gavin Shan wrote:
> >> On Mon, Mar 23, 2015 at 02:43:03PM +1100, David Gibson wrote:
> >> >On Mon, Mar 23, 2015 at 12:56:36PM +1100, Gavi
Using the framework provided by the recent vgic.c changes, we
register a kvm_io_bus device on mapping the virtual GICv3 resources.
The distributor mapping is pretty straight forward, but the
redistributors need some more love, since they need to be tagged with
the respective redistributor (read: VC
Currently we have struct kvm_exit_mmio for encapsulating MMIO abort
data to be passed on from syndrome decoding all the way down to the
VGIC register handlers. Now as we switch the MMIO handling to be
routed through the KVM MMIO bus, it does not make sense anymore to
use that structure already from
With all of the virtual GIC emulation code now being registered with
the kvm_io_bus, we can remove all of the old MMIO handling code and
its dispatching functionality.
Signed-off-by: Andre Przywara
---
include/kvm/arm_vgic.h |2 --
virt/kvm/arm/vgic-v2-emul.c | 19
virt/k
The vgic_find_range() function in vgic.c takes a struct kvm_exit_mmio
argument, but actually only used the length field in there. Since we
need to get rid of that structure in that part of the code anyway,
let's rework the function (and it's callers) to pass the length
argument to the function dire
Using the framework provided by the recent vgic.c changes we register
a kvm_io_bus device when initializing the virtual GICv2.
Signed-off-by: Andre Przywara
---
include/kvm/arm_vgic.h |1 +
virt/kvm/arm/vgic-v2-emul.c | 13 +
virt/kvm/arm/vgic.c | 17
From: Nikolay Nikolaev
This is needed in e.g. ARM vGIC emulation, where the MMIO handling
depends on the VCPU that does the access.
Signed-off-by: Nikolay Nikolaev
Signed-off-by: Andre Przywara
Acked-by: Paolo Bonzini
Acked-by: Christoffer Dall
---
arch/powerpc/kvm/mpic.c| 10 ++--
This series converts the VGIC MMIO handling routines to the generic
kvm_io_bus framework. The framework is needed for the ioeventfd
functionality, some people on the list wanted to see the VGIC
converted over to use it, too.
Beside from now moving to a generic framework instead of relying on
an ARM
virt/kvm was never really a good include directory for anything else
than locally included headers.
With the move of iodev.h there is no need anymore to add this
directory the compiler's include path, so remove it from the x86 kvm
Makefile.
Signed-off-by: Andre Przywara
---
arch/x86/kvm/Makefile
The name "kvm_mmio_range" is a bit bold, given that it only covers
the VGIC's MMIO ranges. To avoid confusion with kvm_io_range, rename
it to vgic_io_range.
Signed-off-by: Andre Przywara
Acked-by: Christoffer Dall
---
virt/kvm/arm/vgic-v2-emul.c |6 +++---
virt/kvm/arm/vgic-v3-emul.c |8
Currently we use a lot of VGIC specific code to do the MMIO
dispatching.
Use the previous reworks to add kvm_io_bus style MMIO handlers.
Those are not yet called by the MMIO abort handler, also the actual
VGIC emulator function do not make use of it yet, but will be enabled
with the following patc
virt/kvm was never really a good include directory for anything else
than locally included headers.
With the move of iodev.h there is no need anymore to add this
directory the compiler's include path, so remove it from the arm and
arm64 kvm Makefile.
Signed-off-by: Andre Przywara
Acked-by: Christ
In kvm_destroy_vm() we call kvm_io_bus_destroy() pretty early,
especially before calling kvm_arch_destroy_vm(). To avoid
unregistering devices from the already destroyed bus, let's mark
the bus with NULL to let other users know it has been destroyed
already.
This avoids a crash on a VM shutdown wit
iodev.h contains definitions for the kvm_io_bus framework. This is
needed both by the generic KVM code in virt/kvm as well as by
architecture specific code under arch/. Putting the header file in
virt/kvm and using local includes in the architecture part seems at
least dodgy to me, so let's move th
From: Jan Kiszka
If the guest CPU is supposed to support rdtscp and the host has rdtscp
enabled in the secondary execution controls, we can also expose this
feature to L1. Just extend nested_vmx_exit_handled to properly route
EXIT_REASON_RDTSCP.
Signed-off-by: Jan Kiszka
---
Changes in v2 (thi
From: Jan Kiszka
If the guest CPU is supposed to support rdtscp and the host has rdtscp
enabled in the secondary execution controls, we can also expose this
feature to L1. Just extend nested_vmx_exit_handled to properly route
EXIT_REASON_RDTSCP.
Signed-off-by: Jan Kiszka
---
arch/x86/include/u
On Wed, Mar 11, 2015 at 02:44:38PM +, James Hogan wrote:
Acked-by: Ralf Baechle
Feel free to merge this through the KVM tree along with the remainder of
the series.
Ralf
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
On Sat, Mar 21, 2015 at 01:50:46AM +0800, Emmanuel Noobadmin wrote:
> Running
> 3.18.9-200.fc21.x86_64
> qemu 2:2.1.3-3.fc21
> libvirt 1.2.9.2-1.fc21
> System is a Thinkpad X250 with Intel i7-5600u Broadwell GT2
>
> I'm trying to replace the Win7 installation on my laptop with Fedora
> 21 and virt
On Fri, Mar 20, 2015 at 12:34:59PM +0100, Francesc Guasch wrote:
> On Fri, Mar 20, 2015 at 10:03:20AM +, Stefan Hajnoczi wrote:
>
> Hi Stefan, thank you very much for answering me.
>
> > On Wed, Mar 18, 2015 at 04:53:28PM +0100, Francesc Guasch wrote:
> > > I have three Ubuntu Server 14.04 tr
On Mon, 2015-03-09 at 07:13 +, Rusty Russell wrote:
> > virtio_mmio: generation support
> > virtio_mmio: fix endian-ness for mmio these two are waiting for ack by
> > Pawel
> >
> > These two fix bugs in virtio 1.0 code for mmio.
> > Host code for that was AFAIK not posted, so I can't t
On 23.03.15 04:03, Michael Ellerman wrote:
> On Mon, 2015-03-23 at 14:00 +1100, Paul Mackerras wrote:
>> On Fri, Mar 20, 2015 at 08:07:53PM +0800, kbuild test robot wrote:
>>> tree: git://github.com/agraf/linux-2.6.git kvm-ppc-queue
>>> head: 9b1daf3cfba1801768aa41b1b6ad0b653844241f
>>> commi
On 23.03.15 08:50, Bharata B Rao wrote:
> On Sat, Mar 21, 2015 at 8:28 PM, Alexander Graf wrote:
>>
>>
>> On 20.03.15 16:51, Bharata B Rao wrote:
>>> On Fri, Mar 20, 2015 at 12:34:18PM +0100, Alexander Graf wrote:
On 20.03.15 12:26, Paul Mackerras wrote:
> On Fri, Mar 20, 2015
On Sat, Mar 21, 2015 at 8:28 PM, Alexander Graf wrote:
>
>
> On 20.03.15 16:51, Bharata B Rao wrote:
>> On Fri, Mar 20, 2015 at 12:34:18PM +0100, Alexander Graf wrote:
>>>
>>>
>>> On 20.03.15 12:26, Paul Mackerras wrote:
On Fri, Mar 20, 2015 at 12:01:32PM +0100, Alexander Graf wrote:
>
>>
On 20.03.2015 21:55, jacob jacob wrote:
> On Thu, Mar 19, 2015 at 10:18 AM, Stefan Assmann wrote:
>> On 19.03.2015 15:04, jacob jacob wrote:
>>> Hi Stefan,
>>> have you been able to get PCI passthrough working without any issues
>>> after the upgrade?
>>
>> My XL710 fails to transfer regular TCP t
52 matches
Mail list logo
