Re: [Qemu-devel] live migration vs device assignment (motivation)

y flag a "bad path" migration would be to emulate a Manually-operated Retention Latch being opened and closed on the device. It may even allow us to work with the desire to support a means for doing a pause/resume as that would be a hot-plug event where the latch was never actually opened.

Re: x86: Don't report guest userspace emulation error to userspace, why ?

> Paolo Bonzini writes: > > On 10/12/2015 18:58, Bandan Das wrote: > >>> > Allowing userspace to stop the guest with an emulation failure is a > >> This one I don't :) Userspace started the guest after all, there are other > >> ways for it to kill the guest if it wanted to. >

Re: x86: Don't report guest userspace emulation error to userspace, why ?

On 09/12/2015 23:18, Bandan Das wrote: > Commit a2b9e6c1a35afcc09: > > KVM: x86: Don't report guest userspace emulation error to userspace > > Commit fc3a9157d314 ("KVM: X86: Don't report L2 emulation failures to > user-space") disabled the reporting of L2 (nested guest)

Re: [PATCH 3/5] x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap

On 10/12/2015 00:12, Andy Lutomirski wrote: > Signed-off-by: Andy Lutomirski > --- > arch/x86/entry/vdso/vclock_gettime.c | 20 > arch/x86/entry/vdso/vdso-layout.lds.S | 3 ++- > arch/x86/entry/vdso/vdso2c.c | 3 +++ > arch/x86/entry/vdso/vma.c

Re: [PATCH 5/5] x86/vdso: Enable vdso pvclock access on all vdso variants

On 10/12/2015 00:12, Andy Lutomirski wrote: > Now that pvclock doesn't require access to the fixmap, all vdso > variants can use it. > > The kernel side isn't wired up for 32-bit kernels yet, but this > covers 32-bit and x32 userspace on 64-bit kernels. > > Signed-off-by: Andy Lutomirski

Re: live migration vs device assignment (motivation)

oo long. > > > >>But switching network interface will introduce service down time. > >> > >>I tested the service down time via putting VF and PV interface > >>into a bonded interface and ping the bonded interface during plug > >>and unplug VF. >

Re: [PATCH 4/5] x86/vdso: Remove pvclock fixmap machinery

On 10/12/2015 00:12, Andy Lutomirski wrote: > Signed-off-by: Andy Lutomirski > --- > arch/x86/entry/vdso/vclock_gettime.c | 1 - > arch/x86/entry/vdso/vma.c| 1 + > arch/x86/include/asm/fixmap.h| 5 - > arch/x86/include/asm/pvclock.h | 5 -

Re: [PATCH 2/5] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

On 10/12/2015 00:12, Andy Lutomirski wrote: > From: Andy Lutomirski > > The pvclock vdso code was too abstracted to understand easily and > excessively paranoid. Simplify it for a huge speedup. > > This opens the door for additional simplifications, as the vdso no >

Re: [PATCH v3 2/4] VSOCK: Introduce virtio-vsock.ko

d pkt */ > + struct work_struct tx_work; > + /* Work item to recv pkt */ > + struct work_struct rx_work; > + /* Mutex to protect send pkt*/ > + struct mutex tx_lock; > + /* Mutex to protect recv pkt*/ > + struct mutex rx_lock; Further down I got

Re: x86: Don't report guest userspace emulation error to userspace, why ?

Paolo Bonzini writes: >> Paolo Bonzini writes: >> > On 10/12/2015 18:58, Bandan Das wrote: >> >>> > Allowing userspace to stop the guest with an emulation failure is a >> >> This one I don't :) Userspace started the guest after all, there are other >>

Re: [Qemu-devel] live migration vs device assignment (motivation)

* Yang Zhang (yang.zhang...@gmail.com) wrote: > On 2015/12/10 18:18, Dr. David Alan Gilbert wrote: > >* Lan, Tianyu (tianyu@intel.com) wrote: > >>On 12/8/2015 12:50 AM, Michael S. Tsirkin wrote: > >>>I thought about what this is doing at the high level, and I do have some > >>>value in what

Re: [PATCH v6 10/21] KVM: ARM64: Add access handler for PMEVCNTRn and PMCCNTR register

Hi Marc, On 2015/12/9 0:30, Marc Zyngier wrote: > On 08/12/15 12:47, Shannon Zhao wrote: >> > From: Shannon Zhao >> > >> > Since the reset value of PMEVCNTRn or PMCCNTR is UNKNOWN, use >> > reset_unknown for its reset handler. Add access handler which emulates >> >

Re: [Qemu-devel] live migration vs device assignment (motivation)

* Lan, Tianyu (tianyu@intel.com) wrote: > On 12/8/2015 12:50 AM, Michael S. Tsirkin wrote: > >I thought about what this is doing at the high level, and I do have some > >value in what you are trying to do, but I also think we need to clarify > >the motivation a bit more. What you are saying

Re: [PATCH v6 10/21] KVM: ARM64: Add access handler for PMEVCNTRn and PMCCNTR register

Hi Shannon, On 10/12/15 11:36, Shannon Zhao wrote: > Hi Marc, > > On 2015/12/9 0:30, Marc Zyngier wrote: >> On 08/12/15 12:47, Shannon Zhao wrote: From: Shannon Zhao Since the reset value of PMEVCNTRn or PMCCNTR is UNKNOWN, use reset_unknown for its

Re: [PATCH v3 1/4] VSOCK: Introduce virtio-vsock-common.ko

default: > + err = -EINVAL; > + break; > + } > + > + virtio_transport_free_pkt(pkt); > + return err; > +} > + > +static int > +virtio_transport_send_response(struct vsock_sock *vsk, > +struct virt

Re: [PATCH] vgaarb: fix signal handling in vga_get()

Hi On Mon, Nov 30, 2015 at 3:17 AM, Kirill A. Shutemov wrote: > There are few defects in vga_get() related to signal hadning: > > - we shouldn't check for pending signals for TASK_UNINTERRUPTIBLE > case; > > - if we found pending signal we must remove ourself from

Re: [Qemu-devel] live migration vs device assignment (motivation)

On 2015/12/10 18:18, Dr. David Alan Gilbert wrote: * Lan, Tianyu (tianyu@intel.com) wrote: On 12/8/2015 12:50 AM, Michael S. Tsirkin wrote: I thought about what this is doing at the high level, and I do have some value in what you are trying to do, but I also think we need to clarify the

Re: freeze host when injecting NMIs in the guest, at least in 4.4-rc4+

On 10/12/2015 17:44, Borislav Petkov wrote: > Yap, > > this is clearly a qemu/kvm issue. Lemme remove ext4 folks from CC. So > here's what happens: > > I boot a kvm guest, connect to its monitor (qemu is started with > "-monitor pty") and on the monitor I issue a couple of times the "nmi" >

Re: x86: Don't report guest userspace emulation error to userspace, why ?

Paolo Bonzini writes: > On 09/12/2015 23:18, Bandan Das wrote: >> Commit a2b9e6c1a35afcc09: >> >> KVM: x86: Don't report guest userspace emulation error to userspace >> >> Commit fc3a9157d314 ("KVM: X86: Don't report L2 emulation failures to >> user-space")

Re: x86: Don't report guest userspace emulation error to userspace, why ?

On 10/12/2015 18:58, Bandan Das wrote: >> > Allowing userspace to stop the guest with an emulation failure is a > This one I don't :) Userspace started the guest after all, there are other > ways for it to kill the guest if it wanted to. I mean allowing guest userspace to stop the guest. Paolo

Re: [PATCH] kvm: x86: move tracepoints outside extended quiescent state

On Thu, Dec 10, 2015 at 06:38:57PM +0100, Paolo Bonzini wrote: > Invoking tracepoints within kvm_guest_enter/kvm_guest_exit causes a > lockdep splat. > > Cc: sta...@vger.kernel.org > Reported-by: Borislav Petkov > Signed-off-by: Paolo Bonzini > --- >

Re: [Qemu-devel] live migration vs device assignment (motivation)

On Thu, Dec 10, 2015 at 6:38 AM, Lan, Tianyu wrote: > > > On 12/10/2015 7:41 PM, Dr. David Alan Gilbert wrote: >>> >>> Ideally, it is able to leave guest driver unmodified but it requires the >>> >hypervisor or qemu to aware the device which means we may need a driver >>> >

Re: freeze host when injecting NMIs in the guest, at least in 4.4-rc4+

On 10/12/2015 17:53, Borislav Petkov wrote: > Just did, there it splats even when booting the guest, without even > injecting NMIs: > > [ 113.233992] === > [ 113.238192] [ INFO: suspicious RCU usage. ] > [ 113.242393] 4.4.0-rc4+ #1 Not tainted > [ 113.246056]

Re: [PATCH v3 07/22] arm64: KVM: Implement system register save/restore

Hi Marc, On 12/7/2015 2:53 AM, Marc Zyngier wrote: > Implement the system register save/restore as a direct translation of > the assembly code version. > > Signed-off-by: Marc Zyngier > Reviewed-by: Christoffer Dall > --- >

Re: [PATCH v3 1/4] VSOCK: Introduce virtio-vsock-common.ko

On Thu, Dec 10, 2015 at 10:17:07AM +, Alex Bennée wrote: > Stefan Hajnoczi writes: > > > From: Asias He > > > > This module contains the common code and header files for the following > > virtio-vsock and virtio-vhost kernel modules. > > General

Re: [PATCH v3 2/4] VSOCK: Introduce virtio-vsock.ko

t mutex tx_lock; > > + /* Mutex to protect recv pkt*/ > > + struct mutex rx_lock; > > Further down I got confused by what lock was what and exactly what was > being protected. If the receive and transmit paths touch separate things > it might be worth re-arranging th

Re: [Qemu-devel] live migration vs device assignment (motivation)

On 2015/12/10 19:41, Dr. David Alan Gilbert wrote: * Yang Zhang (yang.zhang...@gmail.com) wrote: On 2015/12/10 18:18, Dr. David Alan Gilbert wrote: * Lan, Tianyu (tianyu@intel.com) wrote: On 12/8/2015 12:50 AM, Michael S. Tsirkin wrote: I thought about what this is doing at the high

Re: [PATCH v6 10/21] KVM: ARM64: Add access handler for PMEVCNTRn and PMCCNTR register

On 2015/12/10 20:07, Marc Zyngier wrote: > Hi Shannon, > > On 10/12/15 11:36, Shannon Zhao wrote: >> > Hi Marc, >> > >> > On 2015/12/9 0:30, Marc Zyngier wrote: >>> >> On 08/12/15 12:47, Shannon Zhao wrote: > From: Shannon Zhao > > Since the

Re: freeze host when injecting NMIs in the guest, at least in 4.4-rc4+

On Thu, Dec 10, 2015 at 05:49:10PM +0100, Paolo Bonzini wrote: > Can you try it on Intel? Just did, there it splats even when booting the guest, without even injecting NMIs: [ 113.233992] === [ 113.238192] [ INFO: suspicious RCU usage. ] [ 113.242393] 4.4.0-rc4+ #1

Re: [Qemu-devel] live migration vs device assignment (motivation)

On 12/11/2015 12:11 AM, Michael S. Tsirkin wrote: On Thu, Dec 10, 2015 at 10:38:32PM +0800, Lan, Tianyu wrote: On 12/10/2015 7:41 PM, Dr. David Alan Gilbert wrote: Ideally, it is able to leave guest driver unmodified but it requires the hypervisor or qemu to aware the device which means

Re: [PATCH 2/5] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

* Paolo Bonzini wrote: > > > On 10/12/2015 00:12, Andy Lutomirski wrote: > > From: Andy Lutomirski > > > > The pvclock vdso code was too abstracted to understand easily and > > excessively paranoid. Simplify it for a huge speedup. > > > > This

Re: live migration vs device assignment (motivation)

example, have a way for driver to tell Linux it has to re-do probing for the device. Just glace the code of device core. device_reprobe() does what you said. /** * device_reprobe - remove driver for a device and probe for a new driver * @dev: the device to reprobe * * This function detaches

Re: [Qemu-devel] live migration vs device assignment (motivation)

On 12/10/2015 7:41 PM, Dr. David Alan Gilbert wrote: Ideally, it is able to leave guest driver unmodified but it requires the >hypervisor or qemu to aware the device which means we may need a driver in >hypervisor or qemu to handle the device on behalf of guest driver. Can you answer the

Re: [Qemu-devel] live migration vs device assignment (motivation)

On Thu, Dec 10, 2015 at 10:38:32PM +0800, Lan, Tianyu wrote: > > > On 12/10/2015 7:41 PM, Dr. David Alan Gilbert wrote: > >>Ideally, it is able to leave guest driver unmodified but it requires the > >>>hypervisor or qemu to aware the device which means we may need a driver in > >>>hypervisor or

Re: [Qemu-devel] live migration vs device assignment (motivation)

* Lan, Tianyu (tianyu@intel.com) wrote: > > > On 12/10/2015 7:41 PM, Dr. David Alan Gilbert wrote: > >>Ideally, it is able to leave guest driver unmodified but it requires the > >>>hypervisor or qemu to aware the device which means we may need a driver in > >>>hypervisor or qemu to handle

Re: freeze host when injecting NMIs in the guest, at least in 4.4-rc4+

Yap, this is clearly a qemu/kvm issue. Lemme remove ext4 folks from CC. So here's what happens: I boot a kvm guest, connect to its monitor (qemu is started with "-monitor pty") and on the monitor I issue a couple of times the "nmi" command. It doesn't explode immediately but it happens pretty

Re: [PATCH 1/1] KVM: PPC: Increase memslots to 320

On 09/12/15 04:28, Paul Mackerras wrote: > On Wed, Nov 04, 2015 at 10:03:48AM +0100, Thomas Huth wrote: >> Only using 32 memslots for KVM on powerpc is way too low, you can >> nowadays hit this limit quite fast by adding a couple of PCI devices >> and/or pluggable memory DIMMs to the guest. >> x86

Re: [PATCH v6 12/21] KVM: ARM64: Add reset and access handlers for PMCNTENSET and PMCNTENCLR register

On 2015/12/9 0:42, Marc Zyngier wrote: >> +void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u32 val, bool all_enable) >> > +{ >> > + int i; >> > + struct kvm_pmu *pmu = >arch.pmu; >> > + struct kvm_pmc *pmc; >> > + >> > + if (!all_enable) >> > + return; > You have the vcpu. Can

Re: [PATCH v6 14/21] KVM: ARM64: Add reset and access handlers for PMOVSSET and PMOVSCLR register

On 2015/12/9 0:59, Marc Zyngier wrote: >> > + } >> > + >> > + /* If all overflow bits are cleared, kick the vcpu to clear interrupt >> > + * pending status. >> > + */ >> > + if (val == 0) >> > + kvm_vcpu_kick(vcpu); > Do we really need to do so? This will be dropped on the next

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On Sat, Dec 05, 2015 at 12:32:00AM +0800, Lan, Tianyu wrote: > Hi Michael & Alexander: > Thanks a lot for your comments and suggestions. It's nice that it's appreciated, but you then go on and ignore all that I have written here: https://www.mail-archive.com/kvm@vger.kernel.org/msg123826.html >

Re: [PATCH v6 07/21] KVM: ARM64: PMU: Add perf event map and introduce perf event creating function

On Wed, 9 Dec 2015 15:38:09 +0800 Shannon Zhao wrote: > > > On 2015/12/8 23:43, Marc Zyngier wrote: > > On 08/12/15 12:47, Shannon Zhao wrote: > >> From: Shannon Zhao > >> +/** > >> + * kvm_pmu_get_counter_value - get PMU counter value > >> +

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On 12/8/2015 1:12 AM, Alexander Duyck wrote: On Mon, Dec 7, 2015 at 7:40 AM, Lan, Tianyu wrote: On 12/5/2015 1:07 AM, Alexander Duyck wrote: We still need to support Windows guest for migration and this is why our patches keep all changes in the driver since it's

RE: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-interrupts

Hi Radim, > -Original Message- > From: Radim Krčmář [mailto:rkrc...@redhat.com] > Sent: Tuesday, November 17, 2015 3:03 AM > To: Wu, Feng <feng...@intel.com> > Cc: pbonz...@redhat.com; kvm@vger.kernel.org; linux-ker...@vger.kernel.org > Subject: Re: [PATCH] KVM:

Re: [PATCH v6 12/21] KVM: ARM64: Add reset and access handlers for PMCNTENSET and PMCNTENCLR register

On Wed, 9 Dec 2015 16:35:58 +0800 Shannon Zhao wrote: > > > On 2015/12/9 0:42, Marc Zyngier wrote: > >> +void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u32 val, bool > >> all_enable) > >> > +{ > >> > +int i; > >> > +struct kvm_pmu *pmu =

Re: [PATCH 1/1] KVM: PPC: Increase memslots to 320

On 09/12/15 04:28, Paul Mackerras wrote: > On Wed, Nov 04, 2015 at 10:03:48AM +0100, Thomas Huth wrote: >> Only using 32 memslots for KVM on powerpc is way too low, you can >> nowadays hit this limit quite fast by adding a couple of PCI devices >> and/or pluggable memory DIMMs to the guest. >> x86

Re: [PATCH v6 15/21] KVM: ARM64: Add reset and access handlers for PMUSERENR register

On 2015/12/9 1:03, Marc Zyngier wrote: > On 08/12/15 12:47, Shannon Zhao wrote: >> > From: Shannon Zhao >> > >> > The reset value of PMUSERENR_EL0 is UNKNOWN, use reset_unknown. >> > >> > Signed-off-by: Shannon Zhao >> > --- >> >

Re: [PATCH v6 15/21] KVM: ARM64: Add reset and access handlers for PMUSERENR register

On Wed, 9 Dec 2015 17:18:02 +0800 Shannon Zhao wrote: > > > On 2015/12/9 1:03, Marc Zyngier wrote: > > On 08/12/15 12:47, Shannon Zhao wrote: > >> > From: Shannon Zhao > >> > > >> > The reset value of PMUSERENR_EL0 is UNKNOWN, use

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On 12/9/2015 6:37 PM, Michael S. Tsirkin wrote: On Sat, Dec 05, 2015 at 12:32:00AM +0800, Lan, Tianyu wrote: Hi Michael & Alexander: Thanks a lot for your comments and suggestions. It's nice that it's appreciated, but you then go on and ignore all that I have written here:

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On 12/9/2015 7:28 PM, Michael S. Tsirkin wrote: I remember reading that it's possible to implement a bus driver on windows if required. But basically I don't see how windows can be relevant to discussing guest driver patches. That discussion probably belongs on the qemu maling list, not on

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On Wed, Dec 09, 2015 at 07:19:15PM +0800, Lan, Tianyu wrote: > On 12/9/2015 6:37 PM, Michael S. Tsirkin wrote: > >On Sat, Dec 05, 2015 at 12:32:00AM +0800, Lan, Tianyu wrote: > >>Hi Michael & Alexander: > >>Thanks a lot for your comments and suggestions. > > > >It's nice that it's appreciated, but

Re: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-interrupts

2015-12-09 08:19+, Wu, Feng: >> -Original Message- >> From: Radim Krčmář [mailto:rkrc...@redhat.com] >> Sent: Tuesday, November 17, 2015 3:03 AM >> To: Wu, Feng <feng...@intel.com> >> Cc: pbonz...@redhat.com; kvm@vger.kernel.org; linux-ker...@vger.ke

Re: [PATCH kvm-unit-tests] x86: always inline functions called after set_exception_return

On 07/12/2015 21:36, David Matlack wrote: > set_exception_return forces exceptions handlers to return to a specific > address instead of returning to the instruction address pushed by the > CPU at the time of the exception. The unit tests apic.c and vmx.c use > this functionality to recover from

Re: live migration vs device assignment (motivation)

On 12/8/2015 12:50 AM, Michael S. Tsirkin wrote: I thought about what this is doing at the high level, and I do have some value in what you are trying to do, but I also think we need to clarify the motivation a bit more. What you are saying is not really what the patches are doing. And with

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On Wed, Dec 9, 2015 at 1:28 AM, Lan, Tianyu wrote: > > > On 12/8/2015 1:12 AM, Alexander Duyck wrote: >> >> On Mon, Dec 7, 2015 at 7:40 AM, Lan, Tianyu wrote: >>> >>> On 12/5/2015 1:07 AM, Alexander Duyck wrote: > > > > We still need to

Re: live migration vs device assignment (motivation)

On Wed, Dec 9, 2015 at 8:26 AM, Lan, Tianyu wrote: > For other kind of devices, it's hard to work. > We are also adding migration support for QAT(QuickAssist Technology) device. > > QAT device user case introduction. > Server, networking, big data, and storage applications

Re: [PATCH v3 0/4] Add virtio transport for AF_VSOCK

On Wed, Dec 09, 2015 at 08:03:49PM +0800, Stefan Hajnoczi wrote: > Note: the virtio-vsock device specification is currently under review but not > yet finalized. Please review this code but don't merge until I send an update > when the spec is finalized. Thanks! Yes, this should have RFC in the

Re: kvmclock doesn't work, help?

On Wed, Dec 9, 2015 at 1:16 PM, Paolo Bonzini wrote: > > > On 09/12/2015 22:10, Andy Lutomirski wrote: >> Can we please stop making kvmclock more complex? It's a beast right >> now, and not in a good way. It's far too tangled with the vclock >> machinery on both the host

Re: kvmclock doesn't work, help?

x too since he chimed in the original thread. At least it > should be made conditional on the existence of a VM at suspend time (and > the master clock stuff should be made per VM, as I suggested at > https://www.mail-archive.com/kvm@vger.kernel.org/msg102316.html). > > It would indeed be great if the master clock could be dr

Re: kvmclock doesn't work, help?

On 09/12/2015 23:27, Andy Lutomirski wrote: > On Wed, Dec 9, 2015 at 2:12 PM, Paolo Bonzini wrote: >> On 09/12/2015 22:49, Andy Lutomirski wrote: >>> On Wed, Dec 9, 2015 at 1:16 PM, Paolo Bonzini wrote: On 09/12/2015 22:10, Andy

Re: kvmclock doesn't work, help?

On 09/12/2015 22:10, Andy Lutomirski wrote: > Can we please stop making kvmclock more complex? It's a beast right > now, and not in a good way. It's far too tangled with the vclock > machinery on both the host and guest sides, the pvclock stuff is not > well thought out (even in principle in

Re: kvmclock doesn't work, help?

On Wed, Dec 9, 2015 at 2:27 PM, Andy Lutomirski wrote: > On Wed, Dec 9, 2015 at 2:12 PM, Paolo Bonzini wrote: >> >> >> On 09/12/2015 22:49, Andy Lutomirski wrote: >>> On Wed, Dec 9, 2015 at 1:16 PM, Paolo Bonzini wrote:

Re: kvmclock doesn't work, help?

On 09/12/2015 22:49, Andy Lutomirski wrote: > On Wed, Dec 9, 2015 at 1:16 PM, Paolo Bonzini wrote: >> >> >> On 09/12/2015 22:10, Andy Lutomirski wrote: >>> Can we please stop making kvmclock more complex? It's a beast right >>> now, and not in a good way. It's far too

Re: live migration vs device assignment (motivation)

ded interface during plug > and unplug VF. > 1) About 100ms when add VF > 2) About 30ms when del VF OK and what's the source of the downtime? I'm guessing that's just arp being repopulated. So simply save and re-populate it. There would be a much cleaner solution. Or maybe there's a timer

[PATCH 1/5] x86/kvm: On KVM re-enable (e.g. after suspend), update clocks

This gets rid of the "did TSC go backwards" logic and just updates all clocks. It should work better (no more disabling of fast timing) and more reliably (all of the clocks are actually updated). Signed-off-by: Andy Lutomirski --- arch/x86/kvm/x86.c | 75

RE: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-interrupts

> -Original Message- > From: Radim Krčmář [mailto:rkrc...@redhat.com] > Sent: Wednesday, December 9, 2015 10:54 PM > To: Wu, Feng <feng...@intel.com> > Cc: pbonz...@redhat.com; kvm@vger.kernel.org; linux-ker...@vger.kernel.org > Subject: Re: [PATCH] KVM: x86: Add

Re: [PATCH] KVM: PPC: Increase memslots to 512

On Wed, Dec 09, 2015 at 11:34:07AM +0100, Thomas Huth wrote: > Only using 32 memslots for KVM on powerpc is way too low, you can > nowadays hit this limit quite fast by adding a couple of PCI devices > and/or pluggable memory DIMMs to the guest. > > x86 already increased the KVM_USER_MEM_SLOTS to

Re: [PATCH] KVM: PPC: Fix emulation of H_SET_DABR/X on POWER8

On Fri, Nov 20, 2015 at 09:11:45AM +0100, Thomas Huth wrote: > In the old DABR register, the BT (Breakpoint Translation) bit > is bit number 61. In the new DAWRX register, the WT (Watchpoint > Translation) bit is bit number 59. So to move the DABR-BT bit > into the position of the DAWRX-WT bit, it

Re: [PATCH] kvm: remove unused variable 'vcpu_book3s'

On Tue, Dec 01, 2015 at 08:42:10PM -0300, Geyslan G. Bem wrote: > The vcpu_book3s struct is assigned but never used. So remove it. > > Signed-off-by: Geyslan G. Bem Thanks, applied to my kvm-ppc-next branch. Paul. -- To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH] KVM: PPC: Increase memslots to 512

On Wed, Dec 09, 2015 at 11:34:07AM +0100, Thomas Huth wrote: > Only using 32 memslots for KVM on powerpc is way too low, you can > nowadays hit this limit quite fast by adding a couple of PCI devices > and/or pluggable memory DIMMs to the guest. > > x86 already increased the KVM_USER_MEM_SLOTS to

Re: [PATCH] KVM: PPC: Fix emulation of H_SET_DABR/X on POWER8

On Fri, Nov 20, 2015 at 09:11:45AM +0100, Thomas Huth wrote: > In the old DABR register, the BT (Breakpoint Translation) bit > is bit number 61. In the new DAWRX register, the WT (Watchpoint > Translation) bit is bit number 59. So to move the DABR-BT bit > into the position of the DAWRX-WT bit, it

Re: [PATCH] kvm: remove unused variable 'vcpu_book3s'

On Tue, Dec 01, 2015 at 08:42:10PM -0300, Geyslan G. Bem wrote: > The vcpu_book3s struct is assigned but never used. So remove it. > > Signed-off-by: Geyslan G. Bem Thanks, applied to my kvm-ppc-next branch. Paul. -- To unsubscribe from this list: send the line "unsubscribe

Re: live migration vs device assignment (motivation)

On 12/10/2015 1:14 AM, Alexander Duyck wrote: On Wed, Dec 9, 2015 at 8:26 AM, Lan, Tianyu wrote: For other kind of devices, it's hard to work. We are also adding migration support for QAT(QuickAssist Technology) device. QAT device user case introduction. Server,

Re: [PATCH v9 0/5] implement vNVDIMM

New version, new week, and unfortunate new ping... :( On 12/02/2015 03:20 PM, Xiao Guangrong wrote: This patchset can be found at: https://github.com/xiaogr/qemu.git nvdimm-v9 It is based on pci branch on Michael's tree and the top commit is: commit 0c73277af7 (vhost-user-test: fix

Re: live migration vs device assignment (motivation)

guessing that's just arp being repopulated. So simply save and re-populate it. There would be a much cleaner solution. Or maybe there's a timer there that just delays hotplug for no reason. Fix it, everyone will benefit. It also requires guest to do switch configuration. That's just wrong. if you

Re: [PATCH] vgaarb: fix signal handling in vga_get()

On Mon, Nov 30, 2015 at 04:17:31AM +0200, Kirill A. Shutemov wrote: > There are few defects in vga_get() related to signal hadning: > > - we shouldn't check for pending signals for TASK_UNINTERRUPTIBLE > case; > > - if we found pending signal we must remove ourself from wait queue >

Re: [PATCH v3 05/22] arm64: KVM: Implement vgic-v3 save/restore

On Mon, 7 Dec 2015 18:14:36 -0800 Mario Smarduch wrote: > > > On 12/7/2015 10:20 AM, Marc Zyngier wrote: > > On 07/12/15 18:05, Mario Smarduch wrote: > >> > >> > >> On 12/7/2015 9:37 AM, Marc Zyngier wrote: > [...] > >>> > >> > >> I was thinking something like

Re: [PATCH kernel 5/9] KVM: PPC: Account TCE-containing pages in locked_vm

On Tue, Sep 15, 2015 at 08:49:35PM +1000, Alexey Kardashevskiy wrote: > At the moment pages used for TCE tables (in addition to pages addressed > by TCEs) are not counted in locked_vm counter so a malicious userspace > tool can call ioctl(KVM_CREATE_SPAPR_TCE) as many times as RLIMIT_NOFILE and >

Re: [PATCH kernel 7/9] KVM: PPC: Move reusable bits of H_PUT_TCE handler to helpers

On Tue, Sep 15, 2015 at 08:49:37PM +1000, Alexey Kardashevskiy wrote: > Upcoming multi-tce support (H_PUT_TCE_INDIRECT/H_STUFF_TCE hypercalls) > will validate TCE (not to have unexpected bits) and IO address > (to be within the DMA window boundaries). > > This introduces helpers to validate TCE

Re: [PATCH kernel 7/9] KVM: PPC: Move reusable bits of H_PUT_TCE handler to helpers

On Tue, Sep 15, 2015 at 08:49:37PM +1000, Alexey Kardashevskiy wrote: > Upcoming multi-tce support (H_PUT_TCE_INDIRECT/H_STUFF_TCE hypercalls) > will validate TCE (not to have unexpected bits) and IO address > (to be within the DMA window boundaries). > > This introduces helpers to validate TCE

Re: [PATCH kernel 6/9] KVM: PPC: Replace SPAPR_TCE_SHIFT with IOMMU_PAGE_SHIFT_4K

On Tue, Sep 15, 2015 at 08:49:36PM +1000, Alexey Kardashevskiy wrote: > SPAPR_TCE_SHIFT is used in few places only and since IOMMU_PAGE_SHIFT_4K > can be easily used instead, remove SPAPR_TCE_SHIFT. > > Signed-off-by: Alexey Kardashevskiy Reviewed-by: David Gibson

Re: [PATCH kernel 5/9] KVM: PPC: Account TCE-containing pages in locked_vm

On Tue, Sep 15, 2015 at 08:49:35PM +1000, Alexey Kardashevskiy wrote: > At the moment pages used for TCE tables (in addition to pages addressed > by TCEs) are not counted in locked_vm counter so a malicious userspace > tool can call ioctl(KVM_CREATE_SPAPR_TCE) as many times as RLIMIT_NOFILE and >

Re: [PATCH kernel 6/9] KVM: PPC: Replace SPAPR_TCE_SHIFT with IOMMU_PAGE_SHIFT_4K

On Tue, Sep 15, 2015 at 08:49:36PM +1000, Alexey Kardashevskiy wrote: > SPAPR_TCE_SHIFT is used in few places only and since IOMMU_PAGE_SHIFT_4K > can be easily used instead, remove SPAPR_TCE_SHIFT. > > Signed-off-by: Alexey Kardashevskiy Reviewed-by: David Gibson

Re: [PATCH kernel 8/9] KVM: Fix KVM_SMI chapter number

On Tue, Sep 15, 2015 at 08:49:38PM +1000, Alexey Kardashevskiy wrote: > The KVM_SMI capability is following the KVM_S390_SET_IRQ_STATE capability > which is "4.95", this changes the number of the KVM_SMI chapter to 4.96. > > Signed-off-by: Alexey Kardashevskiy Reviewed-by:

Re: [PATCH v5 03/21] KVM: ARM64: Add offset defines for PMU registers

;>>> >>> #define MDSCR_EL122 /* Monitor Debug System Control >>>> >>> Register */ >>>> >>> #define MDCCINT_EL1 23 /* Monitor Debug Comms Channel >>>> >>> Interrupt Enable Reg */ >

Re: [PATCH kernel 9/9] KVM: PPC: Add support for multiple-TCE hcalls

On Tue, Sep 15, 2015 at 08:49:39PM +1000, Alexey Kardashevskiy wrote: > This adds real and virtual mode handlers for the H_PUT_TCE_INDIRECT and > H_STUFF_TCE hypercalls for user space emulated devices such as IBMVIO > devices or emulated PCI. These calls allow adding multiple entries > (up to

Re: [PATCH kernel 9/9] KVM: PPC: Add support for multiple-TCE hcalls

On Tue, Sep 15, 2015 at 08:49:39PM +1000, Alexey Kardashevskiy wrote: > This adds real and virtual mode handlers for the H_PUT_TCE_INDIRECT and > H_STUFF_TCE hypercalls for user space emulated devices such as IBMVIO > devices or emulated PCI. These calls allow adding multiple entries > (up to

Re: [PATCH v5 03/21] KVM: ARM64: Add offset defines for PMU registers

gt;>> #define MDCCINT_EL1 23 /* Monitor Debug Comms Channel >>>>>>>> Interrupt Enable Reg */ >>>>>>>> >>>>>> >>>>>> Coming back to this patch, it gives a clear view of where you have state >>>&

Re: [PATCH v3 06/22] arm64: KVM: Implement timer save/restore

On 08/12/15 02:18, Mario Smarduch wrote: > > > On 12/7/2015 2:53 AM, Marc Zyngier wrote: >> Implement the timer save restore as a direct translation of >> the assembly code version. >> >> Signed-off-by: Marc Zyngier >> --- >> arch/arm64/kvm/hyp/Makefile | 1 + >>

Re: [PATCH v9 3/6] target-arm: kvm - support for single step

Peter Maydell writes: > On 12 November 2015 at 16:20, Alex Bennée wrote: >> This adds support for single-step. There isn't much to do on the QEMU >> side as after we set-up the request for single step via the debug ioctl >> it is all handled

Re: [PATCH v9 6/6] tests/guest-debug: introduce basic gdbstub tests

Peter Maydell writes: > On 12 November 2015 at 16:20, Alex Bennée wrote: >> From: Alex Bennée >> >> The aim of these tests is to combine with an appropriate kernel >> image (with symbol-file vmlinux) and check it behaves as it

Re: [PATCH v6 02/21] KVM: ARM64: Define PMU data structure for each vcpu

On 08/12/15 13:53, Will Deacon wrote: > On Tue, Dec 08, 2015 at 01:37:14PM +, Marc Zyngier wrote: >> On 08/12/15 12:47, Shannon Zhao wrote: >>> From: Shannon Zhao >>> >>> Here we plan to support virtual PMU for guest by full software >>> emulation, so define some

Re: [PATCH v6 06/21] KVM: ARM64: Add reset and access handlers for PMCEID0 and PMCEID1 register

On 08/12/15 12:47, Shannon Zhao wrote: > From: Shannon Zhao > > Add reset handler which gets host value of PMCEID0 or PMCEID1. Since > write action to PMCEID0 or PMCEID1 is ignored, add a new case for this. > > Signed-off-by: Shannon Zhao > ---

Re: [PATCH v4 0/4] KVM: arm64: BUG FIX: Correctly handle zero register transfers

On Tue, Dec 08, 2015 at 09:57:21AM +0300, Pavel Fedin wrote: > Hello! > > > I messed up the "load into xzr" test royally in the last attached patch. > > It was quite wrong. > > Yes, because "mov %0, xzr" is not trapped. > > > I have now tested > > > > asm volatile( > > "str %3,

Re: [PATCH v6 02/21] KVM: ARM64: Define PMU data structure for each vcpu

On 08/12/15 12:47, Shannon Zhao wrote: > From: Shannon Zhao > > Here we plan to support virtual PMU for guest by full software > emulation, so define some basic structs and functions preparing for > futher steps. Define struct kvm_pmc for performance monitor counter and

Re: [PATCH v6 02/21] KVM: ARM64: Define PMU data structure for each vcpu

On Tue, Dec 08, 2015 at 01:37:14PM +, Marc Zyngier wrote: > On 08/12/15 12:47, Shannon Zhao wrote: > > From: Shannon Zhao > > > > Here we plan to support virtual PMU for guest by full software > > emulation, so define some basic structs and functions preparing for >

Re: [PATCH v6 02/21] KVM: ARM64: Define PMU data structure for each vcpu

On 2015/12/8 22:10, Marc Zyngier wrote: On 08/12/15 13:53, Will Deacon wrote: On Tue, Dec 08, 2015 at 01:37:14PM +, Marc Zyngier wrote: On 08/12/15 12:47, Shannon Zhao wrote: From: Shannon Zhao Here we plan to support virtual PMU for guest by full software

Re: [PATCH v6 10/21] KVM: ARM64: Add access handler for PMEVCNTRn and PMCCNTR register

On 08/12/15 12:47, Shannon Zhao wrote: > From: Shannon Zhao > > Since the reset value of PMEVCNTRn or PMCCNTR is UNKNOWN, use > reset_unknown for its reset handler. Add access handler which emulates > writing and reading PMEVCNTRn or PMCCNTR register. When reading >

Re: [PATCH v6 07/21] KVM: ARM64: PMU: Add perf event map and introduce perf event creating function

On 08/12/15 12:47, Shannon Zhao wrote: > From: Shannon Zhao > > When we use tools like perf on host, perf passes the event type and the > id of this event type category to kernel, then kernel will map them to > hardware event number and write this number to PMU

Re: [PATCH v6 08/21] KVM: ARM64: Add access handler for PMEVTYPERn and PMCCFILTR register

On 08/12/15 12:47, Shannon Zhao wrote: > From: Shannon Zhao > > Add access handler which emulates writing and reading PMEVTYPERn or > PMCCFILTR register. When writing to PMEVTYPERn or PMCCFILTR, call > kvm_pmu_set_counter_event_type to create a perf_event for the

Re: [PATCH v6 12/21] KVM: ARM64: Add reset and access handlers for PMCNTENSET and PMCNTENCLR register

On 08/12/15 12:47, Shannon Zhao wrote: > From: Shannon Zhao > > Since the reset value of PMCNTENSET and PMCNTENCLR is UNKNOWN, use > reset_unknown for its reset handler. Add a new case to emulate writing > PMCNTENSET or PMCNTENCLR register. > > When writing to

<    1   2   3   4   5   6   7   8   9   10   >