> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Tuesday, June 23, 2015 11:50 PM
> To: Wu, Feng; kvm@vger.kernel.org; linux-ker...@vger.kernel.org
> Cc: mtosa...@redhat.com; alex.william...@redhat.com;
> eric.au...@linaro.org
> Subject: Re: [v4 01/16] KVM: E
Hi Dave,
On Tue, Jun 23, 2015 at 12:00:19PM -0700, Dave Hansen wrote:
> Down in userfaultfd_wake_function(), it looks like you intended for a
> len=0 to mean "wake all". But the validate_range() that we do from
> userspace has a !len check in it, which keeps us from passing a len=0 in
> from user
On 05/14/2015 10:31 AM, Andrea Arcangeli wrote:
> +static int userfaultfd_wake_function(wait_queue_t *wq, unsigned mode,
> + int wake_flags, void *key)
> +{
> + struct userfaultfd_wake_range *range = key;
> + int ret;
> + struct userfaultfd_wait_queue *u
Linus,
The following changes since commit c447e76b4cabb49ddae8e49c5758f031f35d55fb:
kvm/fpu: Enable eager restore kvm FPU for MPX (2015-05-20 12:30:26 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus
for you to fetch changes up to
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
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
> > r
On 11/06/2015 12:51, Feng Wu wrote:
> + union {
> + struct {
> + /* bit 256 - Outstanding Notification */
> + u64 on : 1,
> + /* bit 257 - Suppress Notification */
> +
Currently we use ld to convert the static guest/init binary back
into an object file, which we can embed as a binary blob into our
lkvm binary. This works fine as long as compiler and linker use the
same ELF target format, which seems to be not true for most of the
MIPS toolchains.
Use a different
The dependencies and targets for the guest userland binary are
currently not correct, some are redundant.
Fix them by splitting up guest/guest_init.o creation into its two
steps and describe the dependencies properly.
On the way use automatic variables in some rules.
Signed-off-by: Andre Przywara
Hi,
this mini series aims at solving long standing issues with compiling
and linking the guest/init binary for MIPS.
It seems that many MIPS toolchains use different default ELF targets
for the compiler and the linker, rendering the approach of linking
the guest/init executable into the lkvm binar
On 22/06/2015 13:20, Christian Borntraeger wrote:
> From: Jens Freimann
>
> 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 interrupt parameters.
On 23 June 2015 at 15:03, Suzuki K. Poulose wrote:
> On 23/06/15 13:39, Christoffer Dall wrote:
>> On Mon, Jun 22, 2015 at 09:44:48AM +0100, Peter Maydell wrote:
>> I'm guessing the intention is to avoid having to add code in the kernel
>> to support KVM on a new CPU where nothing else needs to be
On 23/06/15 13:39, Christoffer Dall wrote:
On Mon, Jun 22, 2015 at 09:44:48AM +0100, Peter Maydell wrote:
On 17 June 2015 at 10:00, Suzuki K. Poulose wrote:
From: "Suzuki K. Poulose"
This patch adds a generic ARM v8 KVM target cpu type for use
by the new CPUs which eventualy ends up using th
Andre,
On 06/23/2015 11:03 AM, Andre Przywara wrote:
> Hi Eric,
>
> I went back reading the code and looked at how the x86 APIC works more
> closely to understand the GSI routing better.
> See below for more ...
>
> On 22/06/15 10:21, Eric Auger wrote:
>> On 06/22/2015 10:40 AM, Andre Przywara wr
On Mon, Jun 22, 2015 at 09:44:48AM +0100, Peter Maydell wrote:
> On 17 June 2015 at 10:00, Suzuki K. Poulose wrote:
> > From: "Suzuki K. Poulose"
> >
> > This patch adds a generic ARM v8 KVM target cpu type for use
> > by the new CPUs which eventualy ends up using the common sys_reg
> > table. Fo
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
Hi,
On 23/06/15 11:05, Michael Ellerman wrote:
> On Tue, 2015-06-23 at 11:33 +0200, Paolo Bonzini wrote:
>> On 19/06/2015 09:21, Michael Ellerman wrote:
>>> diff --git a/powerpc/spapr.h b/powerpc/spapr.h
>>> index 0537f881c0e4..7a377d093ef4 100644
>>> --- a/powerpc/spapr.h
>>> +++ b/powerpc/spapr.
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 23/06/15 12:51, Paolo Bonzini wrote:
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.
On Tue, 2015-06-23 at 11:33 +0200, Paolo Bonzini wrote:
> On 19/06/2015 09:21, Michael Ellerman wrote:
> > diff --git a/powerpc/spapr.h b/powerpc/spapr.h
> > index 0537f881c0e4..7a377d093ef4 100644
> > --- a/powerpc/spapr.h
> > +++ b/powerpc/spapr.h
> > @@ -16,17 +16,32 @@
> >
> > #include
> >
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 23/06/15 02:52, Peter Hornyack wrote:
On Mon, Jun 22, 2015 at 9:05 AM, Denis V. Lunev wrote:
From: Andrey Smetanin
Added hyper-v crash msr's(HV_X64_MSR_CRASH*) data and control
geters and setters.
Signed-off-by: Andrey Smetanin
Signed-off-by: Denis V. Lunev
CC: Paolo Bonzini
CC: Gleb N
Hi Favel,
On 06/23/2015 10:50 AM, Pavel Fedin wrote:
> Hello!
>
>> I was talking about what
>> is done without this "gsi direct mapping" feature. In that case the low
>> GSI numbers are used by irqchip routing entries. So kvm_irqchip_get_virq
>> returns a gsi beyond the irqchip routed gsi's.
>
>
Salut Andre,
On 06/23/2015 11:03 AM, Andre Przywara wrote:
> Hi Eric,
>
> I went back reading the code and looked at how the x86 APIC works more
> closely to understand the GSI routing better.
> See below for more ...
>
> On 22/06/15 10:21, Eric Auger wrote:
>> On 06/22/2015 10:40 AM, Andre Przyw
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
Hi Eric,
I went back reading the code and looked at how the x86 APIC works more
closely to understand the GSI routing better.
See below for more ...
On 22/06/15 10:21, Eric Auger wrote:
> On 06/22/2015 10:40 AM, Andre Przywara wrote:
>> Hi Eric,
>>
>> I briefly looked over the series, the patches
Hello!
> I was talking about what
> is done without this "gsi direct mapping" feature. In that case the low
> GSI numbers are used by irqchip routing entries. So kvm_irqchip_get_virq
> returns a gsi beyond the irqchip routed gsi's.
But aren't these low numbers just routed by the qemu too? I don
On 06/23/2015 04:00 PM, Paolo Bonzini wrote:
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 r
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
Hi Pavel,
On 06/23/2015 09:38 AM, Pavel Fedin wrote:
> Hello!
>
>> What is done currently at qemu level for other archs - if I understand
>> it correctly - is there is static GSI routing for standard IRQ.
>
> Yes, this is correct. GSI number = SPI number for ARM. Also something
> similar for
Hello!
> What is done currently at qemu level for other archs - if I understand
> it correctly - is there is static GSI routing for standard IRQ.
Yes, this is correct. GSI number = SPI number for ARM. Also something similar
for MIPS (haven't
study that).
> For MSI
> irqfd setup they use spa
Hi André,
On 06/22/2015 06:32 PM, Andre Przywara wrote:
> Hi Eric,
>
> On 18/06/15 18:40, Eric Auger wrote:
>> On ARM, the MSI msg (address and data) comes along with
>> out-of-band device ID information. The device ID encodes the device
>> that composes the MSI msg. Let's create a new routing ent
35 matches
Mail list logo
