[PATCH v5 1/3] powerpc/eeh: Move PE state constants around
There are two equivalent sets of PE state constants, defined in
arch/powerpc/include/asm/eeh.h and include/uapi/linux/vfio.h.
Though the names are different, their corresponding values are
exactly same. The former is used by EEH core and the latter is
used by userspace.
The patch moves those constants from arch/powerpc/include/asm/eeh.h
to arch/powerpc/include/uapi/asm/eeh.h, which are expected to be
used by userspace from now on. We can't delete those constants in
vfio.h as it's uncertain that those constants have been or will be
used by userspace.
Suggested-by: David Gibson
Signed-off-by: Gavin Shan
---
arch/powerpc/include/asm/eeh.h | 7 ++-
arch/powerpc/include/uapi/asm/eeh.h | 30 ++
2 files changed, 32 insertions(+), 5 deletions(-)
create mode 100644 arch/powerpc/include/uapi/asm/eeh.h
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index d777c0c..08c4042 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -27,6 +27,8 @@
#include
#include
+#include
+
struct pci_dev;
struct pci_bus;
@@ -184,11 +186,6 @@ enum {
#define EEH_STATE_DMA_ACTIVE (1 << 4)/* Active DMA */
#define EEH_STATE_MMIO_ENABLED (1 << 5)/* MMIO enabled */
#define EEH_STATE_DMA_ENABLED (1 << 6)/* DMA enabled */
-#define EEH_PE_STATE_NORMAL0 /* Normal state */
-#define EEH_PE_STATE_RESET 1 /* PE reset asserted*/
-#define EEH_PE_STATE_STOPPED_IO_DMA2 /* Frozen PE*/
-#define EEH_PE_STATE_STOPPED_DMA 4 /* Stopped DMA, Enabled IO */
-#define EEH_PE_STATE_UNAVAIL 5 /* Unavailable */
#define EEH_RESET_DEACTIVATE 0 /* Deactivate the PE reset */
#define EEH_RESET_HOT 1 /* Hot reset*/
#define EEH_RESET_FUNDAMENTAL 3 /* Fundamental reset*/
diff --git a/arch/powerpc/include/uapi/asm/eeh.h
b/arch/powerpc/include/uapi/asm/eeh.h
new file mode 100644
index 000..8bb34b0
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/eeh.h
@@ -0,0 +1,30 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * Copyright IBM Corp. 2015
+ *
+ * Authors: Gavin Shan
+ */
+
+#ifndef _ASM_POWERPC_EEH_H
+#define _ASM_POWERPC_EEH_H
+
+/* PE states */
+#define EEH_PE_STATE_NORMAL0 /* Normal state */
+#define EEH_PE_STATE_RESET 1 /* PE reset asserted*/
+#define EEH_PE_STATE_STOPPED_IO_DMA2 /* Frozen PE*/
+#define EEH_PE_STATE_STOPPED_DMA 4 /* Stopped DMA only */
+#define EEH_PE_STATE_UNAVAIL 5 /* Unavailable */
+
+#endif /* _ASM_POWERPC_EEH_H */
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 0/3] EEH Error Injection Support for VFIO Devices
The series of patches are extention to EEH support for VFIO PCI devices,
which allows to inject EEH errors to VFIO PCI devices from userspace
for testing purpose.
Changelog
=
v4 -> v5:
* Adjusted commit log for PATCH[1]
* Dropped the last patch which deletes VFIO_EEH_PE_STATE_* from
uapi/linux/vfio.h because we're uncertain if there're any one
used or will use them in future as pointed by Alex.W.
v3 -> v4:
* Move constants for EEH PE states defined in uapi/linux/vfio.h
to uapi/asm/eeh.h.
v2 -> v3:
* Use offsetofend(), instead of sizeof(struct vfio_eeh_pe_op)
to calculate argument buffer size.
v1 -> v2:
* Use EEH_ERR_FUNC_{MIN,MAX} to validate PCI error function.
* Put additional arguments for error injection to union in
struct vfio_eeh_pe_op.
Gavin Shan (3):
powerpc/eeh: Move PE state constants around
powerpc/eeh: Introduce eeh_pe_inject_err()
drivers/vfio: Support EEH error injection
Documentation/vfio.txt | 12
arch/powerpc/include/asm/eeh.h | 9 +++---
arch/powerpc/include/uapi/asm/eeh.h | 56 +
arch/powerpc/kernel/eeh.c | 35 +++
drivers/vfio/vfio_spapr_eeh.c | 10 +++
include/uapi/linux/vfio.h | 14 +-
6 files changed, 130 insertions(+), 6 deletions(-)
create mode 100644 arch/powerpc/include/uapi/asm/eeh.h
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/3] powerpc/eeh: Introduce eeh_pe_inject_err()
The patch defines PCI error types and functions in uapi/asm/eeh.h
and exports function eeh_pe_inject_err(), which will be called by
VFIO driver to inject the specified PCI error to the indicated
PE for testing purpose.
Signed-off-by: Gavin Shan
Reviewed-by: David Gibson
---
arch/powerpc/include/asm/eeh.h | 2 ++
arch/powerpc/include/uapi/asm/eeh.h | 26 ++
arch/powerpc/kernel/eeh.c | 35 +++
3 files changed, 63 insertions(+)
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index 08c4042..cd6003b 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -291,6 +291,8 @@ int eeh_pe_set_option(struct eeh_pe *pe, int option);
int eeh_pe_get_state(struct eeh_pe *pe);
int eeh_pe_reset(struct eeh_pe *pe, int option);
int eeh_pe_configure(struct eeh_pe *pe);
+int eeh_pe_inject_err(struct eeh_pe *pe, int type, int func,
+ unsigned long addr, unsigned long mask);
/**
* EEH_POSSIBLE_ERROR() -- test for possible MMIO failure.
diff --git a/arch/powerpc/include/uapi/asm/eeh.h
b/arch/powerpc/include/uapi/asm/eeh.h
index 8bb34b0..291b7d1 100644
--- a/arch/powerpc/include/uapi/asm/eeh.h
+++ b/arch/powerpc/include/uapi/asm/eeh.h
@@ -27,4 +27,30 @@
#define EEH_PE_STATE_STOPPED_DMA 4 /* Stopped DMA only */
#define EEH_PE_STATE_UNAVAIL 5 /* Unavailable */
+/* EEH error types and functions */
+#define EEH_ERR_TYPE_320 /* 32-bits error
*/
+#define EEH_ERR_TYPE_641 /* 64-bits error
*/
+#define EEH_ERR_FUNC_MIN 0
+#define EEH_ERR_FUNC_LD_MEM_ADDR 0 /* Memory load */
+#define EEH_ERR_FUNC_LD_MEM_DATA 1
+#define EEH_ERR_FUNC_LD_IO_ADDR2 /* IO load */
+#define EEH_ERR_FUNC_LD_IO_DATA3
+#define EEH_ERR_FUNC_LD_CFG_ADDR 4 /* Config load */
+#define EEH_ERR_FUNC_LD_CFG_DATA 5
+#define EEH_ERR_FUNC_ST_MEM_ADDR 6 /* Memory store */
+#define EEH_ERR_FUNC_ST_MEM_DATA 7
+#define EEH_ERR_FUNC_ST_IO_ADDR8 /* IO store */
+#define EEH_ERR_FUNC_ST_IO_DATA9
+#define EEH_ERR_FUNC_ST_CFG_ADDR 10 /* Config store */
+#define EEH_ERR_FUNC_ST_CFG_DATA 11
+#define EEH_ERR_FUNC_DMA_RD_ADDR 12 /* DMA read */
+#define EEH_ERR_FUNC_DMA_RD_DATA 13
+#define EEH_ERR_FUNC_DMA_RD_MASTER 14
+#define EEH_ERR_FUNC_DMA_RD_TARGET 15
+#define EEH_ERR_FUNC_DMA_WR_ADDR 16 /* DMA write*/
+#define EEH_ERR_FUNC_DMA_WR_DATA 17
+#define EEH_ERR_FUNC_DMA_WR_MASTER 18
+#define EEH_ERR_FUNC_DMA_WR_TARGET 19
+#define EEH_ERR_FUNC_MAX 19
+
#endif /* _ASM_POWERPC_EEH_H */
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 76253eb..daa68a1 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -1636,6 +1636,41 @@ int eeh_pe_configure(struct eeh_pe *pe)
}
EXPORT_SYMBOL_GPL(eeh_pe_configure);
+/**
+ * eeh_pe_inject_err - Injecting the specified PCI error to the indicated PE
+ * @pe: the indicated PE
+ * @type: error type
+ * @function: error function
+ * @addr: address
+ * @mask: address mask
+ *
+ * The routine is called to inject the specified PCI error, which
+ * is determined by @type and @function, to the indicated PE for
+ * testing purpose.
+ */
+int eeh_pe_inject_err(struct eeh_pe *pe, int type, int func,
+ unsigned long addr, unsigned long mask)
+{
+ /* Invalid PE ? */
+ if (!pe)
+ return -ENODEV;
+
+ /* Unsupported operation ? */
+ if (!eeh_ops || !eeh_ops->err_inject)
+ return -ENOENT;
+
+ /* Check on PCI error type */
+ if (type != EEH_ERR_TYPE_32 && type != EEH_ERR_TYPE_64)
+ return -EINVAL;
+
+ /* Check on PCI error function */
+ if (func < EEH_ERR_FUNC_MIN || func > EEH_ERR_FUNC_MAX)
+ return -EINVAL;
+
+ return eeh_ops->err_inject(pe, type, func, addr, mask);
+}
+EXPORT_SYMBOL_GPL(eeh_pe_inject_err);
+
static int proc_eeh_show(struct seq_file *m, void *v)
{
if (!eeh_enabled()) {
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 3/3] drivers/vfio: Support EEH error injection
The patch adds one more EEH sub-command (VFIO_EEH_PE_INJECT_ERR)
to inject the specified EEH error, which is represented by
(struct vfio_eeh_pe_err), to the indicated PE for testing purpose.
Signed-off-by: Gavin Shan
Reviewed-by: David Gibson
---
Documentation/vfio.txt| 12
drivers/vfio/vfio_spapr_eeh.c | 10 ++
include/uapi/linux/vfio.h | 14 +-
3 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt
index 96978ec..4c746a7 100644
--- a/Documentation/vfio.txt
+++ b/Documentation/vfio.txt
@@ -385,6 +385,18 @@ The code flow from the example above should be slightly
changed:
+ /* Inject EEH error, which is expected to be caused by 32-bits
+* config load.
+*/
+ pe_op.op = VFIO_EEH_PE_INJECT_ERR;
+ pe_op.err.type = EEH_ERR_TYPE_32;
+ pe_op.err.func = EEH_ERR_FUNC_LD_CFG_ADDR;
+ pe_op.err.addr = 0ul;
+ pe_op.err.mask = 0ul;
+ ioctl(container, VFIO_EEH_PE_OP, &pe_op);
+
+
+
/* When 0xFF's returned from reading PCI config space or IO BARs
* of the PCI device. Check the PE's state to see if that has been
* frozen.
diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
index 5fa42db..38edeb4 100644
--- a/drivers/vfio/vfio_spapr_eeh.c
+++ b/drivers/vfio/vfio_spapr_eeh.c
@@ -85,6 +85,16 @@ long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
case VFIO_EEH_PE_CONFIGURE:
ret = eeh_pe_configure(pe);
break;
+ case VFIO_EEH_PE_INJECT_ERR:
+ minsz = offsetofend(struct vfio_eeh_pe_op, err.mask);
+ if (op.argsz < minsz)
+ return -EINVAL;
+ if (copy_from_user(&op, (void __user *)arg, minsz))
+ return -EFAULT;
+
+ ret = eeh_pe_inject_err(pe, op.err.type, op.err.func,
+ op.err.addr, op.err.mask);
+ break;
default:
ret = -EINVAL;
}
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 82889c3..d81c17f 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -468,12 +468,23 @@ struct vfio_iommu_spapr_tce_info {
* - unfreeze IO/DMA for frozen PE;
* - read PE state;
* - reset PE;
- * - configure PE.
+ * - configure PE;
+ * - inject EEH error.
*/
+struct vfio_eeh_pe_err {
+ __u32 type;
+ __u32 func;
+ __u64 addr;
+ __u64 mask;
+};
+
struct vfio_eeh_pe_op {
__u32 argsz;
__u32 flags;
__u32 op;
+ union {
+ struct vfio_eeh_pe_err err;
+ };
};
#define VFIO_EEH_PE_DISABLE0 /* Disable EEH functionality */
@@ -490,6 +501,7 @@ struct vfio_eeh_pe_op {
#define VFIO_EEH_PE_RESET_HOT 6 /* Assert hot reset */
#define VFIO_EEH_PE_RESET_FUNDAMENTAL 7 /* Assert fundamental reset */
#define VFIO_EEH_PE_CONFIGURE 8 /* PE configuration */
+#define VFIO_EEH_PE_INJECT_ERR 9 /* Inject EEH error */
#define VFIO_EEH_PE_OP _IO(VFIO_TYPE, VFIO_BASE + 21)
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/4] drivers/vfio: Remove duplicated PE states
On Wed, Mar 25, 2015 at 07:55:41PM -0600, Alex Williamson wrote:
>On Thu, 2015-03-26 at 11:59 +1100, Gavin Shan wrote:
>> On Wed, Mar 25, 2015 at 06:46:28PM -0600, Alex Williamson wrote:
>> >On Thu, 2015-03-26 at 10:20 +1100, Gavin Shan wrote:
>> >> The set of constants for PE states defined in uapi/linux/vfio.h is
>> >> duplicated to uapi/asm/eeh.h. The patch removes the set from the
>> >> former.
>> >>
>> >> Signed-off-by: Gavin Shan
>> >> ---
>> >> include/uapi/linux/vfio.h | 5 -
>> >> 1 file changed, 5 deletions(-)
>> >>
>> >> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
>> >> index d81c17f..3fd1e86 100644
>> >> --- a/include/uapi/linux/vfio.h
>> >> +++ b/include/uapi/linux/vfio.h
>> >> @@ -492,11 +492,6 @@ struct vfio_eeh_pe_op {
>> >> #define VFIO_EEH_PE_UNFREEZE_IO 2 /* Enable IO for frozen
>> >> PE */
>> >> #define VFIO_EEH_PE_UNFREEZE_DMA 3 /* Enable DMA for frozen PE */
>> >> #define VFIO_EEH_PE_GET_STATE4 /* PE state retrieval
>> >> */
>> >> -#define VFIO_EEH_PE_STATE_NORMAL0 /* PE in functional
>> >> state*/
>> >> -#define VFIO_EEH_PE_STATE_RESET 1 /* PE reset in progress */
>> >> -#define VFIO_EEH_PE_STATE_STOPPED 2 /* Stopped DMA and IO
>> >> */
>> >> -#define VFIO_EEH_PE_STATE_STOPPED_DMA 4 /* Stopped DMA only
>> >> */
>> >> -#define VFIO_EEH_PE_STATE_UNAVAIL 5 /* State unavailable
>> >> */
>> >> #define VFIO_EEH_PE_RESET_DEACTIVATE 5 /* Deassert PE reset
>> >> */
>> >> #define VFIO_EEH_PE_RESET_HOT6 /* Assert hot reset
>> >> */
>> >> #define VFIO_EEH_PE_RESET_FUNDAMENTAL7 /* Assert fundamental
>> >> reset */
>> >
>> >How do you know that nobody depends on these defines? I thought the
>> >suggestion was to use the EEH_* defines for error injection, not to
>> >remove existing VFIO_EEH_* defines. You could certainly redefine these
>> >in terms of EEH_* defines instead. Thanks,
>> >
>>
>> QEMU should be the first user to utilize the EEH capability exposed by
>> the host kernel, and I believe QEMU doesn't use those constants yet.
>> So it's right time to move those constants to uapi/asm/eeh.h. Once some
>> one starts to use them, it's impossible to do so.
>
>There are soon to be four kernel versions out there with these defines,
>you can't be sure that nobody has already or won't in the future do
>VFIO/EEH development on those kernels. The defines need to stay IMHO.
>Thanks,
>
Right, it's the point to keep them. I'll simply drop PATCH[4/4] and
amend the commit log of PATCH[1/4] in next revision, which will be
sent out soon.
Thanks,
Gavin
>Alex
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] E5-2620v2 - emulation stop error
Hi Andrey, Andrey Korolyov writes: > On Mon, Mar 16, 2015 at 10:17 PM, Andrey Korolyov wrote: >> For now, it looks like bug have a mixed Murphy-Heisenberg nature, as >> it appearance is very rare (compared to the number of actual launches) >> and most probably bounded to the physical characteristics of my >> production nodes. As soon as I reach any reproducible path for a >> regular workstation environment, I`ll let everyone know. Also I am >> starting to think that issue can belong to the particular motherboard >> firmware revision, despite fact that the CPU microcode is the same >> everywhere. I will take the risk and say this - "could it be a processor bug ?" :) > > Hello everyone, I`ve managed to reproduce this issue > *deterministically* with latest seabios with smp fix and 3.18.3. The > error occuring just *once* per vm until hypervisor reboots, at least > in my setup, this is definitely crazy... > > - launch two VMs (Centos 7 in my case), > - wait a little while they are booting, > - attach serial console (I am using virsh list for this exact purpose), > - issue acpi reboot or reset, does not matter, > - VM always hangs at boot, most times with sgabios initialization > string printed out [1], but sometimes it hangs a bit later [2], > - no matter how many times I try to relaunch the QEMU afterwards, the > issue does not appear on VM which experienced problem once; > - trace and sample args can be seen in [3] and [4] respectively. My system is a Dell R720 dual socket which has 2620v2s. I tried your setup but couldn't reproduce (my qemu cmdline isn't exactly the same as yours), although, if you could simplify your command line a bit, I can try again. Bandan > 1) > Google, Inc. > Serial Graphics Adapter 06/11/14 > SGABIOS $Id: sgabios.S 8 2010-04-22 00:03:40Z nlaredo $ > (pbuilder@zorak) Wed Jun 11 05:57:34 UTC 2014 > Term: 211x62 > 4 0 > > 2) > Google, Inc. > Serial Graphics Adapter 06/11/14 > SGABIOS $Id: sgabios.S 8 2010-04-22 00:03:40Z nlaredo $ > (pbuilder@zorak) Wed Jun 11 05:57:34 UTC 2014 > Term: 211x62 > 4 0 > [...empty screen...] > SeaBIOS (version 1.8.1-20150325_230423-testnode) > Machine UUID 3c78721f-7317-4f85-bcbe-f5ad46d293a1 > > > iPXE (http://ipxe.org) 00:02.0 C100 PCI2.10 PnP PMM+3FF95BA0+3FEF5BA0 C10 > > 3) > > KVM internal error. Suberror: 2 > extra data[0]: 80ef > extra data[1]: 8b0d > EAX= EBX= ECX= EDX= > ESI= EDI= EBP= ESP=6d2c > EIP=d331 EFL=00010202 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 > ES = 9300 > CS =f000 000f 9b00 > SS = 9300 > DS = 9300 > FS = 9300 > GS = 9300 > LDT= 8200 > TR = 8b00 > GDT= 000f6cb0 0037 > IDT= 03ff > CR0=0010 CR2= CR3= CR4= > DR0= DR1= DR2= > DR3= > DR6=0ff0 DR7=0400 > EFER= > Code=66 c3 cd 02 cb cd 10 cb cd 13 cb cd 15 cb cd 16 cb cd 18 cb > 19 cb cd 1c cb cd 4a cb fa fc 66 ba 47 d3 0f 00 e9 ad fe f3 90 f0 0f > ba 2d d4 fe fb 3f > > 4) > /usr/bin/qemu-system-x86_64 -name centos71 -S -machine > pc-i440fx-2.1,accel=kvm,usb=off -cpu SandyBridge,+kvm_pv_eoi -bios > /usr/share/seabios/bios.bin -m 1024 -realtime mlock=off -smp > 12,sockets=1,cores=12,threads=12 -uuid > 3c78721f-7317-4f85-bcbe-f5ad46d293a1 -nographic -no-user-config > -nodefaults -device sga -chardev > socket,id=charmonitor,path=/var/lib/libvirt/qemu/centos71.monitor,server,nowait > -mon chardev=charmonitor,id=monitor,mode=control -rtc > base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard > -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global > PIIX4_PM.disable_s4=1 -boot strict=on -device > nec-usb-xhci,id=usb,bus=pci.0,addr=0x3 -device > virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive > file=rbd:dev-rack2/centos7-1.raw:id=qemukvm:key=XX:auth_supported=cephx\;none:mon_host=10.6.0.1\:6789\;10.6.0.3\:6789\;10.6.0.4\:6789,if=none,id=drive-virtio-disk0,format=raw,cache=writeback,aio=native > -device > virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 > -chardev pty,id=charserial0 -device > isa-serial,chardev=charserial0,id=serial0 -chardev > socket,id=charchannel0,path=/var/lib/libvirt/qemu/centos71.sock,server,nowait > -device > virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.1 > -msg timestamp=on -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/4] drivers/vfio: Remove duplicated PE states
On Thu, Mar 26, 2015 at 11:59:03AM +1100, Gavin Shan wrote:
> On Wed, Mar 25, 2015 at 06:46:28PM -0600, Alex Williamson wrote:
> >On Thu, 2015-03-26 at 10:20 +1100, Gavin Shan wrote:
> >> The set of constants for PE states defined in uapi/linux/vfio.h is
> >> duplicated to uapi/asm/eeh.h. The patch removes the set from the
> >> former.
> >>
> >> Signed-off-by: Gavin Shan
> >> ---
> >> include/uapi/linux/vfio.h | 5 -
> >> 1 file changed, 5 deletions(-)
> >>
> >> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> >> index d81c17f..3fd1e86 100644
> >> --- a/include/uapi/linux/vfio.h
> >> +++ b/include/uapi/linux/vfio.h
> >> @@ -492,11 +492,6 @@ struct vfio_eeh_pe_op {
> >> #define VFIO_EEH_PE_UNFREEZE_IO 2 /* Enable IO for frozen
> >> PE */
> >> #define VFIO_EEH_PE_UNFREEZE_DMA 3 /* Enable DMA for frozen PE */
> >> #define VFIO_EEH_PE_GET_STATE 4 /* PE state retrieval
> >> */
> >> -#define VFIO_EEH_PE_STATE_NORMAL 0 /* PE in functional state*/
> >> -#define VFIO_EEH_PE_STATE_RESET 1 /* PE reset in progress */
> >> -#define VFIO_EEH_PE_STATE_STOPPED2 /* Stopped DMA and IO
> >> */
> >> -#define VFIO_EEH_PE_STATE_STOPPED_DMA4 /* Stopped DMA only
> >> */
> >> -#define VFIO_EEH_PE_STATE_UNAVAIL5 /* State unavailable
> >> */
> >> #define VFIO_EEH_PE_RESET_DEACTIVATE 5 /* Deassert PE reset
> >> */
> >> #define VFIO_EEH_PE_RESET_HOT 6 /* Assert hot reset
> >> */
> >> #define VFIO_EEH_PE_RESET_FUNDAMENTAL 7 /* Assert fundamental
> >> reset */
> >
> >How do you know that nobody depends on these defines? I thought the
> >suggestion was to use the EEH_* defines for error injection, not to
> >remove existing VFIO_EEH_* defines. You could certainly redefine these
> >in terms of EEH_* defines instead. Thanks,
> >
>
> QEMU should be the first user to utilize the EEH capability exposed by
> the host kernel, and I believe QEMU doesn't use those constants yet.
> So it's right time to move those constants to uapi/asm/eeh.h. Once some
> one starts to use them, it's impossible to do so.
That's a good point, actually. This seems like a reasonable risk
under the cirucmstances to me.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
pgpyYJhW4uddq.pgp
Description: PGP signature
Re: [PATCH v4 4/4] drivers/vfio: Remove duplicated PE states
On Thu, 2015-03-26 at 11:59 +1100, Gavin Shan wrote:
> On Wed, Mar 25, 2015 at 06:46:28PM -0600, Alex Williamson wrote:
> >On Thu, 2015-03-26 at 10:20 +1100, Gavin Shan wrote:
> >> The set of constants for PE states defined in uapi/linux/vfio.h is
> >> duplicated to uapi/asm/eeh.h. The patch removes the set from the
> >> former.
> >>
> >> Signed-off-by: Gavin Shan
> >> ---
> >> include/uapi/linux/vfio.h | 5 -
> >> 1 file changed, 5 deletions(-)
> >>
> >> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> >> index d81c17f..3fd1e86 100644
> >> --- a/include/uapi/linux/vfio.h
> >> +++ b/include/uapi/linux/vfio.h
> >> @@ -492,11 +492,6 @@ struct vfio_eeh_pe_op {
> >> #define VFIO_EEH_PE_UNFREEZE_IO 2 /* Enable IO for frozen
> >> PE */
> >> #define VFIO_EEH_PE_UNFREEZE_DMA 3 /* Enable DMA for frozen PE */
> >> #define VFIO_EEH_PE_GET_STATE 4 /* PE state retrieval
> >> */
> >> -#define VFIO_EEH_PE_STATE_NORMAL 0 /* PE in functional state*/
> >> -#define VFIO_EEH_PE_STATE_RESET 1 /* PE reset in progress */
> >> -#define VFIO_EEH_PE_STATE_STOPPED2 /* Stopped DMA and IO
> >> */
> >> -#define VFIO_EEH_PE_STATE_STOPPED_DMA4 /* Stopped DMA only
> >> */
> >> -#define VFIO_EEH_PE_STATE_UNAVAIL5 /* State unavailable
> >> */
> >> #define VFIO_EEH_PE_RESET_DEACTIVATE 5 /* Deassert PE reset
> >> */
> >> #define VFIO_EEH_PE_RESET_HOT 6 /* Assert hot reset
> >> */
> >> #define VFIO_EEH_PE_RESET_FUNDAMENTAL 7 /* Assert fundamental
> >> reset */
> >
> >How do you know that nobody depends on these defines? I thought the
> >suggestion was to use the EEH_* defines for error injection, not to
> >remove existing VFIO_EEH_* defines. You could certainly redefine these
> >in terms of EEH_* defines instead. Thanks,
> >
>
> QEMU should be the first user to utilize the EEH capability exposed by
> the host kernel, and I believe QEMU doesn't use those constants yet.
> So it's right time to move those constants to uapi/asm/eeh.h. Once some
> one starts to use them, it's impossible to do so.
There are soon to be four kernel versions out there with these defines,
you can't be sure that nobody has already or won't in the future do
VFIO/EEH development on those kernels. The defines need to stay IMHO.
Thanks,
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/4] drivers/vfio: Remove duplicated PE states
On Thu, Mar 26, 2015 at 12:01:57PM +1100, David Gibson wrote:
>On Wed, Mar 25, 2015 at 06:46:28PM -0600, Alex Williamson wrote:
>> On Thu, 2015-03-26 at 10:20 +1100, Gavin Shan wrote:
>> > The set of constants for PE states defined in uapi/linux/vfio.h is
>> > duplicated to uapi/asm/eeh.h. The patch removes the set from the
>> > former.
>> >
>> > Signed-off-by: Gavin Shan
>> > ---
>> > include/uapi/linux/vfio.h | 5 -
>> > 1 file changed, 5 deletions(-)
>> >
>> > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
>> > index d81c17f..3fd1e86 100644
>> > --- a/include/uapi/linux/vfio.h
>> > +++ b/include/uapi/linux/vfio.h
>> > @@ -492,11 +492,6 @@ struct vfio_eeh_pe_op {
>> > #define VFIO_EEH_PE_UNFREEZE_IO 2 /* Enable IO for frozen
>> > PE */
>> > #define VFIO_EEH_PE_UNFREEZE_DMA 3 /* Enable DMA for frozen PE */
>> > #define VFIO_EEH_PE_GET_STATE 4 /* PE state retrieval
>> > */
>> > -#define VFIO_EEH_PE_STATE_NORMAL 0 /* PE in functional state*/
>> > -#define VFIO_EEH_PE_STATE_RESET 1 /* PE reset in progress */
>> > -#define VFIO_EEH_PE_STATE_STOPPED2 /* Stopped DMA and IO
>> > */
>> > -#define VFIO_EEH_PE_STATE_STOPPED_DMA4 /* Stopped DMA only
>> > */
>> > -#define VFIO_EEH_PE_STATE_UNAVAIL5 /* State unavailable
>> > */
>> > #define VFIO_EEH_PE_RESET_DEACTIVATE 5 /* Deassert PE reset
>> > */
>> > #define VFIO_EEH_PE_RESET_HOT 6 /* Assert hot reset
>> > */
>> > #define VFIO_EEH_PE_RESET_FUNDAMENTAL 7 /* Assert fundamental
>> > reset */
>>
>> How do you know that nobody depends on these defines? I thought the
>> suggestion was to use the EEH_* defines for error injection, not to
>> remove existing VFIO_EEH_* defines. You could certainly redefine these
>> in terms of EEH_* defines instead. Thanks,
>
>Yeah, since they're already exported, these can't be just removed, but
>should be redefined in terms of the new exported EEH defines.
>
I just explained to Alex.W with something as follows. Are you sure to
keep this set of defines in vfio.h? That way, the EEH error constants
are all defined in uapi/asm/eeh.h, but the EEH PE state constatns will
be distributed in vfio.h and uapi/asm/eeh.h at the same time. Actually,
I believe it's safe to move the PE state defines from vfio.h to
uapi/asm/eeh.h and now is the right time to do so :)
---
QEMU should be the first user to utilize the EEH capability exposed by
the host kernel, and I believe QEMU doesn't use those constants yet.
So it's right time to move those constants to uapi/asm/eeh.h. Once some
one starts to use them, it's impossible to do so.
>I also think this should be folded into 1/1.
>
The reason I didn't fold it to PATCH[1/4]: I was afraid the changs
will be taken via different trees (ppc-next and vfio-next).
Thanks,
Gavin
>--
>David Gibson | I'll have my music baroque, and my code
>david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
> | _way_ _around_!
>http://www.ozlabs.org/~dgibson
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/4] drivers/vfio: Remove duplicated PE states
On Wed, Mar 25, 2015 at 06:46:28PM -0600, Alex Williamson wrote:
> On Thu, 2015-03-26 at 10:20 +1100, Gavin Shan wrote:
> > The set of constants for PE states defined in uapi/linux/vfio.h is
> > duplicated to uapi/asm/eeh.h. The patch removes the set from the
> > former.
> >
> > Signed-off-by: Gavin Shan
> > ---
> > include/uapi/linux/vfio.h | 5 -
> > 1 file changed, 5 deletions(-)
> >
> > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> > index d81c17f..3fd1e86 100644
> > --- a/include/uapi/linux/vfio.h
> > +++ b/include/uapi/linux/vfio.h
> > @@ -492,11 +492,6 @@ struct vfio_eeh_pe_op {
> > #define VFIO_EEH_PE_UNFREEZE_IO2 /* Enable IO for frozen
> > PE */
> > #define VFIO_EEH_PE_UNFREEZE_DMA 3 /* Enable DMA for frozen PE */
> > #define VFIO_EEH_PE_GET_STATE 4 /* PE state retrieval
> > */
> > -#define VFIO_EEH_PE_STATE_NORMAL 0 /* PE in functional state*/
> > -#define VFIO_EEH_PE_STATE_RESET 1 /* PE reset in progress */
> > -#define VFIO_EEH_PE_STATE_STOPPED 2 /* Stopped DMA and IO*/
> > -#define VFIO_EEH_PE_STATE_STOPPED_DMA 4 /* Stopped DMA only
> > */
> > -#define VFIO_EEH_PE_STATE_UNAVAIL 5 /* State unavailable */
> > #define VFIO_EEH_PE_RESET_DEACTIVATE 5 /* Deassert PE reset
> > */
> > #define VFIO_EEH_PE_RESET_HOT 6 /* Assert hot reset
> > */
> > #define VFIO_EEH_PE_RESET_FUNDAMENTAL 7 /* Assert fundamental
> > reset */
>
> How do you know that nobody depends on these defines? I thought the
> suggestion was to use the EEH_* defines for error injection, not to
> remove existing VFIO_EEH_* defines. You could certainly redefine these
> in terms of EEH_* defines instead. Thanks,
Yeah, since they're already exported, these can't be just removed, but
should be redefined in terms of the new exported EEH defines.
I also think this should be folded into 1/1.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
pgpjMamFwkqXy.pgp
Description: PGP signature
Re: [Qemu-devel] PCI passthrough of 40G ethernet interface (Openstack/KVM)
On Tue, Mar 24, 2015 at 8:04 AM, jacob jacob wrote: > > The issue is running dpdk from within the vm itself. Is it possible > that the igb_uio driver needs additional updates/functionality to be > at parity with 1.2.37 version of i40e driver? > At this point I think you need to work with the DPDK folks. We don't directly support or test the PF driver in a passthru mode, and DPDK folks will have a better idea how this might affect their driver. sln -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/4] drivers/vfio: Remove duplicated PE states
On Wed, Mar 25, 2015 at 06:46:28PM -0600, Alex Williamson wrote:
>On Thu, 2015-03-26 at 10:20 +1100, Gavin Shan wrote:
>> The set of constants for PE states defined in uapi/linux/vfio.h is
>> duplicated to uapi/asm/eeh.h. The patch removes the set from the
>> former.
>>
>> Signed-off-by: Gavin Shan
>> ---
>> include/uapi/linux/vfio.h | 5 -
>> 1 file changed, 5 deletions(-)
>>
>> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
>> index d81c17f..3fd1e86 100644
>> --- a/include/uapi/linux/vfio.h
>> +++ b/include/uapi/linux/vfio.h
>> @@ -492,11 +492,6 @@ struct vfio_eeh_pe_op {
>> #define VFIO_EEH_PE_UNFREEZE_IO 2 /* Enable IO for frozen
>> PE */
>> #define VFIO_EEH_PE_UNFREEZE_DMA3 /* Enable DMA for frozen PE */
>> #define VFIO_EEH_PE_GET_STATE 4 /* PE state retrieval
>> */
>> -#define VFIO_EEH_PE_STATE_NORMAL 0 /* PE in functional state*/
>> -#define VFIO_EEH_PE_STATE_RESET1 /* PE reset in progress */
>> -#define VFIO_EEH_PE_STATE_STOPPED 2 /* Stopped DMA and IO*/
>> -#define VFIO_EEH_PE_STATE_STOPPED_DMA 4 /* Stopped DMA only
>> */
>> -#define VFIO_EEH_PE_STATE_UNAVAIL 5 /* State unavailable */
>> #define VFIO_EEH_PE_RESET_DEACTIVATE5 /* Deassert PE reset
>> */
>> #define VFIO_EEH_PE_RESET_HOT 6 /* Assert hot reset
>> */
>> #define VFIO_EEH_PE_RESET_FUNDAMENTAL 7 /* Assert fundamental
>> reset */
>
>How do you know that nobody depends on these defines? I thought the
>suggestion was to use the EEH_* defines for error injection, not to
>remove existing VFIO_EEH_* defines. You could certainly redefine these
>in terms of EEH_* defines instead. Thanks,
>
QEMU should be the first user to utilize the EEH capability exposed by
the host kernel, and I believe QEMU doesn't use those constants yet.
So it's right time to move those constants to uapi/asm/eeh.h. Once some
one starts to use them, it's impossible to do so.
Thanks,
Gavin
>Alex
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/4] drivers/vfio: Remove duplicated PE states
On Thu, 2015-03-26 at 10:20 +1100, Gavin Shan wrote:
> The set of constants for PE states defined in uapi/linux/vfio.h is
> duplicated to uapi/asm/eeh.h. The patch removes the set from the
> former.
>
> Signed-off-by: Gavin Shan
> ---
> include/uapi/linux/vfio.h | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index d81c17f..3fd1e86 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -492,11 +492,6 @@ struct vfio_eeh_pe_op {
> #define VFIO_EEH_PE_UNFREEZE_IO 2 /* Enable IO for frozen
> PE */
> #define VFIO_EEH_PE_UNFREEZE_DMA 3 /* Enable DMA for frozen PE */
> #define VFIO_EEH_PE_GET_STATE4 /* PE state retrieval
> */
> -#define VFIO_EEH_PE_STATE_NORMAL0 /* PE in functional state*/
> -#define VFIO_EEH_PE_STATE_RESET 1 /* PE reset in progress */
> -#define VFIO_EEH_PE_STATE_STOPPED 2 /* Stopped DMA and IO*/
> -#define VFIO_EEH_PE_STATE_STOPPED_DMA 4 /* Stopped DMA only
> */
> -#define VFIO_EEH_PE_STATE_UNAVAIL 5 /* State unavailable */
> #define VFIO_EEH_PE_RESET_DEACTIVATE 5 /* Deassert PE reset */
> #define VFIO_EEH_PE_RESET_HOT6 /* Assert hot reset
> */
> #define VFIO_EEH_PE_RESET_FUNDAMENTAL7 /* Assert fundamental
> reset */
How do you know that nobody depends on these defines? I thought the
suggestion was to use the EEH_* defines for error injection, not to
remove existing VFIO_EEH_* defines. You could certainly redefine these
in terms of EEH_* defines instead. Thanks,
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] E5-2620v2 - emulation stop error
On Thu, Mar 26, 2015 at 02:35:58AM +0300, Andrey Korolyov wrote: > Thanks, strangely the reboot is always failing now and always reaching > seabios greeting. May be prints straightened up a race (e.g. it is not > int19 problem really). > > object file part: > > d331 : > irq_trampoline_0x19(): > /root/seabios-1.8.1/src/romlayout.S:195 > d331: cd 19 int$0x19 > d333: cb lretw [...] > Jump to int19 (vector=f000e6f2) Thanks. So, it dies on the "int $0x19" instruction itself. The vector looks correct and I don't see anything in the cpu register state that looks wrong. Maybe one of the kvm developers will have an idea what could cause a fault there. -Kevin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] E5-2620v2 - emulation stop error
On Thu, Mar 26, 2015 at 2:02 AM, Kevin O'Connor wrote:
> On Thu, Mar 26, 2015 at 01:31:11AM +0300, Andrey Korolyov wrote:
>> On Wed, Mar 25, 2015 at 11:54 PM, Kevin O'Connor wrote:
>> >
>> > Can you add something like:
>> >
>> > -chardev file,path=seabioslog.`date +%s`,id=seabios -device
>> > isa-debugcon,iobase=0x402,chardev=seabios
>> >
>> > to the qemu command line and forward the resulting log from both a
>> > succesful boot and a failed one?
>> >
>> > -Kevin
>>
>> Of course, logs are attached.
>
> Thanks. From a diff of the two logs:
>
> 4: 3ffe - 4000 = 2 RESERVED
> 5: feffc000 - ff00 = 2 RESERVED
> 6: fffc - 0001 = 2 RESERVED
> -enter handle_19:
> - NULL
> -Booting from Hard Disk...
> -Booting from :7c00
>
> So, it got most of the way through the reboot - there's only a few
> function calls between the e820 map being dumped and the handle_19
> call. The fault also seems to show it stopped in the BIOS in 16bit
> mode:
>
>> EIP=d331 EFL=00010202 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0
>> ES = 9300
>> CS =f000 000f 9b00
>
> Can you add the patch below, force the fault, and forward the log.
>
> Also, if you recreate the failure can you take the EIP from the fault
> (eg, d331) and search for the corresponding function in the output of:
> objdump -m i386 -M i8086 -M suffix -ldr out/rom16.o | less
> (That is, search for "d331:".) If that's too much of a pain, just
> send me a direct email with the seabios out/rom16.o file and the new
> EIP of the fault. (I need the out/rom16.o that was used to build the
> version of SeaBIOS that faulted.)
>
> -Kevin
>
>
> diff --git a/src/post.c b/src/post.c
> index 9ea5620..bbd19c0 100644
> --- a/src/post.c
> +++ b/src/post.c
> @@ -185,21 +185,24 @@ prepareboot(void)
> pmm_prepboot();
> malloc_prepboot();
> memmap_prepboot();
> +dprintf(1, "a\n");
>
> HaveRunPost = 2;
>
> // Setup bios checksum.
> BiosChecksum -= checksum((u8*)BUILD_BIOS_ADDR, BUILD_BIOS_SIZE);
> +dprintf(1, "b\n");
> }
>
> // Begin the boot process by invoking an int0x19 in 16bit mode.
> void VISIBLE32FLAT
> startBoot(void)
> {
> +dprintf(1, "e\n");
> // Clear low-memory allocations (required by PMM spec).
> memset((void*)BUILD_STACK_ADDR, 0, BUILD_EBDA_MINIMUM -
> BUILD_STACK_ADDR);
>
> -dprintf(3, "Jump to int19\n");
> +dprintf(1, "Jump to int19 (vector=%x)\n", GET_IVT(0x19).segoff);
> struct bregs br;
> memset(&br, 0, sizeof(br));
> br.flags = F_IF;
> @@ -239,9 +242,11 @@ maininit(void)
> // Prepare for boot.
> prepareboot();
>
> +dprintf(1, "c\n");
> // Write protect bios memory.
> make_bios_readonly();
>
> +dprintf(1, "d\n");
> // Invoke int 19 to start boot process.
> startBoot();
> }
Thanks, strangely the reboot is always failing now and always reaching
seabios greeting. May be prints straightened up a race (e.g. it is not
int19 problem really).
object file part:
d331 :
irq_trampoline_0x19():
/root/seabios-1.8.1/src/romlayout.S:195
d331: cd 19 int$0x19
d333: cb lretw
reboot.failed
Description: Binary data
Re: x86: kvm: Revert "remove sched notifier for cross-cpu migrations"
On Wed, Mar 25, 2015 at 4:13 PM, Marcelo Tosatti wrote: > On Wed, Mar 25, 2015 at 03:48:02PM -0700, Andy Lutomirski wrote: >> On Wed, Mar 25, 2015 at 3:41 PM, Marcelo Tosatti wrote: >> > On Wed, Mar 25, 2015 at 03:33:10PM -0700, Andy Lutomirski wrote: >> >> On Mar 25, 2015 2:29 PM, "Marcelo Tosatti" wrote: >> >> > >> >> > On Wed, Mar 25, 2015 at 01:52:15PM +0100, Radim Krčmář wrote: >> >> > > 2015-03-25 12:08+0100, Radim Krčmář: >> >> > > > Reverting the patch protects us from any migration, but I don't >> >> > > > think we >> >> > > > need to care about changing VCPUs as long as we read a consistent >> >> > > > data >> >> > > > from kvmclock. (VCPU can change outside of this loop too, so it >> >> > > > doesn't >> >> > > > matter if we return a value not fit for this VCPU.) >> >> > > > >> >> > > > I think we could drop the second __getcpu if our kvmclock was being >> >> > > > handled better; maybe with a patch like the one below: >> >> > > >> >> > > The second __getcpu is not neccessary, but I forgot about rdtsc. >> >> > > We need to either use rtdscp, know the host has synchronized tsc, or >> >> > > monitor VCPU migrations. Only the last one works everywhere. >> >> > >> >> > The vdso code is only used if host has synchronized tsc. >> >> > >> >> > But you have to handle the case where host goes from synchronized tsc to >> >> > unsynchronized tsc (see the clocksource notifier in the host side). >> >> > >> >> >> >> Can't we change the host to freeze all vcpus and clear the stable bit >> >> on all of them if this happens? This would simplify and speed up >> >> vclock_gettime. >> >> >> >> --Andy >> > >> > Seems interesting to do on 512-vcpus, but sure, could be done. >> > >> >> If you have a 512-vcpu system that switches between stable and >> unstable more than once per migration, then I expect that you have >> serious problems and this is the least of your worries. >> >> Personally, I'd *much* rather we just made vcpu 0's pvti authoritative >> if we're stable. If nothing else, I'm not even remotely convinced >> that the current scheme gives monotonic timing due to skew between >> when the updates happen on different vcpus. > > Can you write down the problem ? > I can try. Suppose we start out with all vcpus agreeing on their pvti and perfect invariant TSCs. Now the host updates its frequency (due to NTP or whatever). KVM updates vcpu 0's pvti. Before KVM updates vcpu 1's pvti, guest code on vcpus 0 and 1 see synced TSCs but different pvti. They'll disagree on the time, and one of them will be ahead until vcpu 1's pvti gets updated. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 4/4] drivers/vfio: Remove duplicated PE states
The set of constants for PE states defined in uapi/linux/vfio.h is
duplicated to uapi/asm/eeh.h. The patch removes the set from the
former.
Signed-off-by: Gavin Shan
---
include/uapi/linux/vfio.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index d81c17f..3fd1e86 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -492,11 +492,6 @@ struct vfio_eeh_pe_op {
#define VFIO_EEH_PE_UNFREEZE_IO2 /* Enable IO for frozen
PE */
#define VFIO_EEH_PE_UNFREEZE_DMA 3 /* Enable DMA for frozen PE */
#define VFIO_EEH_PE_GET_STATE 4 /* PE state retrieval*/
-#define VFIO_EEH_PE_STATE_NORMAL 0 /* PE in functional state*/
-#define VFIO_EEH_PE_STATE_RESET 1 /* PE reset in progress */
-#define VFIO_EEH_PE_STATE_STOPPED 2 /* Stopped DMA and IO*/
-#define VFIO_EEH_PE_STATE_STOPPED_DMA 4 /* Stopped DMA only */
-#define VFIO_EEH_PE_STATE_UNAVAIL 5 /* State unavailable */
#define VFIO_EEH_PE_RESET_DEACTIVATE 5 /* Deassert PE reset */
#define VFIO_EEH_PE_RESET_HOT 6 /* Assert hot reset */
#define VFIO_EEH_PE_RESET_FUNDAMENTAL 7 /* Assert fundamental reset */
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/4] powerpc/eeh: Eliminate duplicated PE states
There are two equivalent sets of constants for PE states, defined
in arch/powerpc/include/asm/eeh.h and include/uapi/linux/vfio.h.
The former is used by EEH core and the latter is used by userspace.
The patch moves those constants from arch/powerpc/include/asm/eeh.h
to arch/powerpc/include/uapi/asm/eeh.h to avoid maintaining two
equivalent sets of constants.
Suggested-by: David Gibson
Signed-off-by: Gavin Shan
---
arch/powerpc/include/asm/eeh.h | 7 ++-
arch/powerpc/include/uapi/asm/eeh.h | 30 ++
2 files changed, 32 insertions(+), 5 deletions(-)
create mode 100644 arch/powerpc/include/uapi/asm/eeh.h
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index d777c0c..08c4042 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -27,6 +27,8 @@
#include
#include
+#include
+
struct pci_dev;
struct pci_bus;
@@ -184,11 +186,6 @@ enum {
#define EEH_STATE_DMA_ACTIVE (1 << 4)/* Active DMA */
#define EEH_STATE_MMIO_ENABLED (1 << 5)/* MMIO enabled */
#define EEH_STATE_DMA_ENABLED (1 << 6)/* DMA enabled */
-#define EEH_PE_STATE_NORMAL0 /* Normal state */
-#define EEH_PE_STATE_RESET 1 /* PE reset asserted*/
-#define EEH_PE_STATE_STOPPED_IO_DMA2 /* Frozen PE*/
-#define EEH_PE_STATE_STOPPED_DMA 4 /* Stopped DMA, Enabled IO */
-#define EEH_PE_STATE_UNAVAIL 5 /* Unavailable */
#define EEH_RESET_DEACTIVATE 0 /* Deactivate the PE reset */
#define EEH_RESET_HOT 1 /* Hot reset*/
#define EEH_RESET_FUNDAMENTAL 3 /* Fundamental reset*/
diff --git a/arch/powerpc/include/uapi/asm/eeh.h
b/arch/powerpc/include/uapi/asm/eeh.h
new file mode 100644
index 000..8bb34b0
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/eeh.h
@@ -0,0 +1,30 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * Copyright IBM Corp. 2015
+ *
+ * Authors: Gavin Shan
+ */
+
+#ifndef _ASM_POWERPC_EEH_H
+#define _ASM_POWERPC_EEH_H
+
+/* PE states */
+#define EEH_PE_STATE_NORMAL0 /* Normal state */
+#define EEH_PE_STATE_RESET 1 /* PE reset asserted*/
+#define EEH_PE_STATE_STOPPED_IO_DMA2 /* Frozen PE*/
+#define EEH_PE_STATE_STOPPED_DMA 4 /* Stopped DMA only */
+#define EEH_PE_STATE_UNAVAIL 5 /* Unavailable */
+
+#endif /* _ASM_POWERPC_EEH_H */
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/4] drivers/vfio: Support EEH error injection
The patch adds one more EEH sub-command (VFIO_EEH_PE_INJECT_ERR)
to inject the specified EEH error, which is represented by
(struct vfio_eeh_pe_err), to the indicated PE for testing purpose.
Signed-off-by: Gavin Shan
Reviewed-by: David Gibson
---
Documentation/vfio.txt| 12
drivers/vfio/vfio_spapr_eeh.c | 10 ++
include/uapi/linux/vfio.h | 14 +-
3 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt
index 96978ec..4c746a7 100644
--- a/Documentation/vfio.txt
+++ b/Documentation/vfio.txt
@@ -385,6 +385,18 @@ The code flow from the example above should be slightly
changed:
+ /* Inject EEH error, which is expected to be caused by 32-bits
+* config load.
+*/
+ pe_op.op = VFIO_EEH_PE_INJECT_ERR;
+ pe_op.err.type = EEH_ERR_TYPE_32;
+ pe_op.err.func = EEH_ERR_FUNC_LD_CFG_ADDR;
+ pe_op.err.addr = 0ul;
+ pe_op.err.mask = 0ul;
+ ioctl(container, VFIO_EEH_PE_OP, &pe_op);
+
+
+
/* When 0xFF's returned from reading PCI config space or IO BARs
* of the PCI device. Check the PE's state to see if that has been
* frozen.
diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
index 5fa42db..38edeb4 100644
--- a/drivers/vfio/vfio_spapr_eeh.c
+++ b/drivers/vfio/vfio_spapr_eeh.c
@@ -85,6 +85,16 @@ long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
case VFIO_EEH_PE_CONFIGURE:
ret = eeh_pe_configure(pe);
break;
+ case VFIO_EEH_PE_INJECT_ERR:
+ minsz = offsetofend(struct vfio_eeh_pe_op, err.mask);
+ if (op.argsz < minsz)
+ return -EINVAL;
+ if (copy_from_user(&op, (void __user *)arg, minsz))
+ return -EFAULT;
+
+ ret = eeh_pe_inject_err(pe, op.err.type, op.err.func,
+ op.err.addr, op.err.mask);
+ break;
default:
ret = -EINVAL;
}
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 82889c3..d81c17f 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -468,12 +468,23 @@ struct vfio_iommu_spapr_tce_info {
* - unfreeze IO/DMA for frozen PE;
* - read PE state;
* - reset PE;
- * - configure PE.
+ * - configure PE;
+ * - inject EEH error.
*/
+struct vfio_eeh_pe_err {
+ __u32 type;
+ __u32 func;
+ __u64 addr;
+ __u64 mask;
+};
+
struct vfio_eeh_pe_op {
__u32 argsz;
__u32 flags;
__u32 op;
+ union {
+ struct vfio_eeh_pe_err err;
+ };
};
#define VFIO_EEH_PE_DISABLE0 /* Disable EEH functionality */
@@ -490,6 +501,7 @@ struct vfio_eeh_pe_op {
#define VFIO_EEH_PE_RESET_HOT 6 /* Assert hot reset */
#define VFIO_EEH_PE_RESET_FUNDAMENTAL 7 /* Assert fundamental reset */
#define VFIO_EEH_PE_CONFIGURE 8 /* PE configuration */
+#define VFIO_EEH_PE_INJECT_ERR 9 /* Inject EEH error */
#define VFIO_EEH_PE_OP _IO(VFIO_TYPE, VFIO_BASE + 21)
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/4] powerpc/eeh: Introduce eeh_pe_inject_err()
The patch defines PCI error types and functions in uapi/asm/eeh.h
and exports function eeh_pe_inject_err(), which will be called by
VFIO driver to inject the specified PCI error to the indicated
PE for testing purpose.
Signed-off-by: Gavin Shan
Reviewed-by: David Gibson
---
arch/powerpc/include/asm/eeh.h | 2 ++
arch/powerpc/include/uapi/asm/eeh.h | 26 ++
arch/powerpc/kernel/eeh.c | 35 +++
3 files changed, 63 insertions(+)
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index 08c4042..cd6003b 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -291,6 +291,8 @@ int eeh_pe_set_option(struct eeh_pe *pe, int option);
int eeh_pe_get_state(struct eeh_pe *pe);
int eeh_pe_reset(struct eeh_pe *pe, int option);
int eeh_pe_configure(struct eeh_pe *pe);
+int eeh_pe_inject_err(struct eeh_pe *pe, int type, int func,
+ unsigned long addr, unsigned long mask);
/**
* EEH_POSSIBLE_ERROR() -- test for possible MMIO failure.
diff --git a/arch/powerpc/include/uapi/asm/eeh.h
b/arch/powerpc/include/uapi/asm/eeh.h
index 8bb34b0..291b7d1 100644
--- a/arch/powerpc/include/uapi/asm/eeh.h
+++ b/arch/powerpc/include/uapi/asm/eeh.h
@@ -27,4 +27,30 @@
#define EEH_PE_STATE_STOPPED_DMA 4 /* Stopped DMA only */
#define EEH_PE_STATE_UNAVAIL 5 /* Unavailable */
+/* EEH error types and functions */
+#define EEH_ERR_TYPE_320 /* 32-bits error
*/
+#define EEH_ERR_TYPE_641 /* 64-bits error
*/
+#define EEH_ERR_FUNC_MIN 0
+#define EEH_ERR_FUNC_LD_MEM_ADDR 0 /* Memory load */
+#define EEH_ERR_FUNC_LD_MEM_DATA 1
+#define EEH_ERR_FUNC_LD_IO_ADDR2 /* IO load */
+#define EEH_ERR_FUNC_LD_IO_DATA3
+#define EEH_ERR_FUNC_LD_CFG_ADDR 4 /* Config load */
+#define EEH_ERR_FUNC_LD_CFG_DATA 5
+#define EEH_ERR_FUNC_ST_MEM_ADDR 6 /* Memory store */
+#define EEH_ERR_FUNC_ST_MEM_DATA 7
+#define EEH_ERR_FUNC_ST_IO_ADDR8 /* IO store */
+#define EEH_ERR_FUNC_ST_IO_DATA9
+#define EEH_ERR_FUNC_ST_CFG_ADDR 10 /* Config store */
+#define EEH_ERR_FUNC_ST_CFG_DATA 11
+#define EEH_ERR_FUNC_DMA_RD_ADDR 12 /* DMA read */
+#define EEH_ERR_FUNC_DMA_RD_DATA 13
+#define EEH_ERR_FUNC_DMA_RD_MASTER 14
+#define EEH_ERR_FUNC_DMA_RD_TARGET 15
+#define EEH_ERR_FUNC_DMA_WR_ADDR 16 /* DMA write*/
+#define EEH_ERR_FUNC_DMA_WR_DATA 17
+#define EEH_ERR_FUNC_DMA_WR_MASTER 18
+#define EEH_ERR_FUNC_DMA_WR_TARGET 19
+#define EEH_ERR_FUNC_MAX 19
+
#endif /* _ASM_POWERPC_EEH_H */
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 76253eb..daa68a1 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -1636,6 +1636,41 @@ int eeh_pe_configure(struct eeh_pe *pe)
}
EXPORT_SYMBOL_GPL(eeh_pe_configure);
+/**
+ * eeh_pe_inject_err - Injecting the specified PCI error to the indicated PE
+ * @pe: the indicated PE
+ * @type: error type
+ * @function: error function
+ * @addr: address
+ * @mask: address mask
+ *
+ * The routine is called to inject the specified PCI error, which
+ * is determined by @type and @function, to the indicated PE for
+ * testing purpose.
+ */
+int eeh_pe_inject_err(struct eeh_pe *pe, int type, int func,
+ unsigned long addr, unsigned long mask)
+{
+ /* Invalid PE ? */
+ if (!pe)
+ return -ENODEV;
+
+ /* Unsupported operation ? */
+ if (!eeh_ops || !eeh_ops->err_inject)
+ return -ENOENT;
+
+ /* Check on PCI error type */
+ if (type != EEH_ERR_TYPE_32 && type != EEH_ERR_TYPE_64)
+ return -EINVAL;
+
+ /* Check on PCI error function */
+ if (func < EEH_ERR_FUNC_MIN || func > EEH_ERR_FUNC_MAX)
+ return -EINVAL;
+
+ return eeh_ops->err_inject(pe, type, func, addr, mask);
+}
+EXPORT_SYMBOL_GPL(eeh_pe_inject_err);
+
static int proc_eeh_show(struct seq_file *m, void *v)
{
if (!eeh_enabled()) {
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/4] EEH Error Injection Support for VFIO Devices
The series of patches are extention to EEH support for VFIO PCI devices,
which allows to inject EEH errors to VFIO PCI devices from userspace
for testing purpose.
Changelog
=
v3 -> v4:
* Move constants for EEH PE states defined in uapi/linux/vfio.h
to uapi/asm/eeh.h.
v2 -> v3:
* Use offsetofend(), instead of sizeof(struct vfio_eeh_pe_op)
to calculate argument buffer size.
v1 -> v2:
* Use EEH_ERR_FUNC_{MIN,MAX} to validate PCI error function.
* Put additional arguments for error injection to union in
struct vfio_eeh_pe_op.
Gavin Shan (4):
powerpc/eeh: Eliminate duplicated PE states
powerpc/eeh: Introduce eeh_pe_inject_err()
drivers/vfio: Support EEH error injection
drivers/vfio: Remove duplicated PE states
Documentation/vfio.txt | 12
arch/powerpc/include/asm/eeh.h | 9 +++---
arch/powerpc/include/uapi/asm/eeh.h | 56 +
arch/powerpc/kernel/eeh.c | 35 +++
drivers/vfio/vfio_spapr_eeh.c | 10 +++
include/uapi/linux/vfio.h | 19 +
6 files changed, 130 insertions(+), 11 deletions(-)
create mode 100644 arch/powerpc/include/uapi/asm/eeh.h
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL 0/3] 4.0 patch queue 2015-03-25
On Wed, Mar 25, 2015 at 10:58:54PM +0100, Alexander Graf wrote: > Hi Paolo, > > This is my current patch queue for 4.0. Please pull. > > Alex > > > The following changes since commit f710a12d73dfa1c3a5d2417f2482b970f03bb850: > > Merge tag 'kvm-arm-fixes-4.0-rc5' of > git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm (2015-03-16 > 20:08:56 -0300) > > are available in the git repository at: > > > git://github.com/agraf/linux-2.6.git tags/signed-for-4.0 > > for you to fetch changes up to 2bf27601c7b50b6ced72f27304109dc52eb52919: > > KVM: PPC: Book3S HV: Fix instruction emulation (2015-03-20 11:42:33 +0100) Pulled, thanks. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v3 24/26] KVM: Update Posted-Interrupts Descriptor when vCPU is blocked
On Mon, Mar 16, 2015 at 11:42:06AM +, Wu, Feng wrote:
> > Do you have any reason why having the code at vcpu_put/vcpu_load is
> > better than the proposal to have the code at kvm_vcpu_block?
>
> I think your proposal is good, I just want to better understand your idea
> here.:)
Reduce the overhead of vcpu sched in / vcpu sched out, basically.
> One thing, even we put the code to kvm_vcpu_block, we still need to add code
> at vcpu_put/vcpu_load for the preemption case like what I did now.
>
> >
> > >
> > > Global vector is a limited resources in the system, and this involves
> > > common x86 interrupt code changes. I am not sure we can allocate
> > > so many dedicated global vector for KVM usage.
> >
> > Why not? Have KVM use all free vectors (so if vectors are necessary for
> > other purposes, people should shrink the KVM vector pool).
>
> If we want to allocate more global vector for this usage, we need hpa's
> input about it. Peter, what is your opinion?
Peter?
> > BTW the Intel docs talk about that ("one vector per vCPU").
> Yes, the Spec talks about this, but it is more complex using one vector per
> vCPU.
>
> >
> > > > > > It seems there is a bunch free:
> > > > > >
> > > > > > commit 52aec3308db85f4e9f5c8b9f5dc4fbd0138c6fa4
> > > > > > Author: Alex Shi
> > > > > > Date: Thu Jun 28 09:02:23 2012 +0800
> > > > > >
> > > > > > x86/tlb: replace INVALIDATE_TLB_VECTOR by
> > > > CALL_FUNCTION_VECTOR
> > > > > >
> > > > > > Can you add only vcpus which have posted IRTEs that point to this
> > > > > > pCPU
> > > > > > to the HLT'ed vcpu lists? (so for example, vcpus without assigned
> > > > > > devices are not part of the list).
> > > > >
> > > > > Is it easy to find whether a vCPU (or the associated domain) has
> > > > > assigned
> > > > devices?
> > > > > If so, we can only add those vCPUs with assigned devices.
> > > >
> > > > When configuring IRTE, at kvm_arch_vfio_update_pi_irte?
> > >
> > > Yes.
> > >
> > > >
> > > > > > > +
> > > > > > > static int __init vmx_init(void)
> > > > > > > {
> > > > > > > int r, i, msr;
> > > > > > > @@ -9429,6 +9523,8 @@ static int __init vmx_init(void)
> > > > > > >
> > > > > > > update_ple_window_actual_max();
> > > > > > >
> > > > > > > + wakeup_handler_callback = wakeup_handler;
> > > > > > > +
> > > > > > > return 0;
> > > > > > >
> > > > > > > out7:
> > > > > > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > > > > > > index 0033df3..1551a46 100644
> > > > > > > --- a/arch/x86/kvm/x86.c
> > > > > > > +++ b/arch/x86/kvm/x86.c
> > > > > > > @@ -6152,6 +6152,21 @@ static int vcpu_enter_guest(struct
> > kvm_vcpu
> > > > > > *vcpu)
> > > > > > > kvm_vcpu_reload_apic_access_page(vcpu);
> > > > > > > }
> > > > > > >
> > > > > > > + /*
> > > > > > > + * Since posted-interrupts can be set by VT-d HW now, in this
> > > > > > > + * case, KVM_REQ_EVENT is not set. We move the following
> > > > > > > + * operations out of the if statement.
> > > > > > > + */
> > > > > > > + if (kvm_lapic_enabled(vcpu)) {
> > > > > > > + /*
> > > > > > > + * Update architecture specific hints for APIC
> > > > > > > + * virtual interrupt delivery.
> > > > > > > + */
> > > > > > > + if (kvm_x86_ops->hwapic_irr_update)
> > > > > > > + kvm_x86_ops->hwapic_irr_update(vcpu,
> > > > > > > + kvm_lapic_find_highest_irr(vcpu));
> > > > > > > + }
> > > > > > > +
> > > > > >
> > > > > > This is a hot fast path. You can set KVM_REQ_EVENT from
> > wakeup_handler.
> > > > >
> > > > > I am afraid Setting KVM_REQ_EVENT from wakeup_handler doesn't help
> > > > much,
> > > > > if vCPU is running in ROOT mode, and VT-d hardware issues an
> > > > > notification
> > > > event,
> > > > > POSTED_INTR_VECTOR interrupt handler will be called.
> > > >
> > > > If vCPU is in root mode, remapping HW will find IRTE configured with
> > > > vector == POSTED_INTR_WAKEUP_VECTOR, use that vector, which will
> > > > VM-exit, and execute the interrupt handler wakeup_handler. Right?
> > >
> > > There are two cases:
> > > Case 1: vCPU is blocked, so it is in root mode, this is what you described
> > above.
> > > Case 2, vCPU is running in root mode, such as, handling vm-exits, in this
> > > case,
> > > the notification vector is 'POSTED_INTR_VECTOR', and if external
> > > interrupts
> > > from assigned devices happen, the handled of 'POSTED_INTR_VECTOR' will
> > > be called ( it is 'smp_kvm_posted_intr_ipi' in fact), this routine
> > > doesn't need
> > > do real things, since the pending interrupts in PIR will be synced to vIRR
> > before
> > > VM-Entry (this code have already been there when enabling CPU-side
> > > posted-interrupt along with APICv). Like what I said before, it is a
> > > little hard
> > to
> > > get vCPU related information in it, even if we get, it is not accurate
> > > and may
> > harm
> > > the performance.(need search)
> > >
> > > So only setting KVM_REQ_EVEN
Re: x86: kvm: Revert "remove sched notifier for cross-cpu migrations"
On Wed, Mar 25, 2015 at 03:48:02PM -0700, Andy Lutomirski wrote: > On Wed, Mar 25, 2015 at 3:41 PM, Marcelo Tosatti wrote: > > On Wed, Mar 25, 2015 at 03:33:10PM -0700, Andy Lutomirski wrote: > >> On Mar 25, 2015 2:29 PM, "Marcelo Tosatti" wrote: > >> > > >> > On Wed, Mar 25, 2015 at 01:52:15PM +0100, Radim Krčmář wrote: > >> > > 2015-03-25 12:08+0100, Radim Krčmář: > >> > > > Reverting the patch protects us from any migration, but I don't > >> > > > think we > >> > > > need to care about changing VCPUs as long as we read a consistent > >> > > > data > >> > > > from kvmclock. (VCPU can change outside of this loop too, so it > >> > > > doesn't > >> > > > matter if we return a value not fit for this VCPU.) > >> > > > > >> > > > I think we could drop the second __getcpu if our kvmclock was being > >> > > > handled better; maybe with a patch like the one below: > >> > > > >> > > The second __getcpu is not neccessary, but I forgot about rdtsc. > >> > > We need to either use rtdscp, know the host has synchronized tsc, or > >> > > monitor VCPU migrations. Only the last one works everywhere. > >> > > >> > The vdso code is only used if host has synchronized tsc. > >> > > >> > But you have to handle the case where host goes from synchronized tsc to > >> > unsynchronized tsc (see the clocksource notifier in the host side). > >> > > >> > >> Can't we change the host to freeze all vcpus and clear the stable bit > >> on all of them if this happens? This would simplify and speed up > >> vclock_gettime. > >> > >> --Andy > > > > Seems interesting to do on 512-vcpus, but sure, could be done. > > > > If you have a 512-vcpu system that switches between stable and > unstable more than once per migration, then I expect that you have > serious problems and this is the least of your worries. > > Personally, I'd *much* rather we just made vcpu 0's pvti authoritative > if we're stable. If nothing else, I'm not even remotely convinced > that the current scheme gives monotonic timing due to skew between > when the updates happen on different vcpus. Can you write down the problem ? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] E5-2620v2 - emulation stop error
On Thu, Mar 26, 2015 at 01:31:11AM +0300, Andrey Korolyov wrote:
> On Wed, Mar 25, 2015 at 11:54 PM, Kevin O'Connor wrote:
> >
> > Can you add something like:
> >
> > -chardev file,path=seabioslog.`date +%s`,id=seabios -device
> > isa-debugcon,iobase=0x402,chardev=seabios
> >
> > to the qemu command line and forward the resulting log from both a
> > succesful boot and a failed one?
> >
> > -Kevin
>
> Of course, logs are attached.
Thanks. From a diff of the two logs:
4: 3ffe - 4000 = 2 RESERVED
5: feffc000 - ff00 = 2 RESERVED
6: fffc - 0001 = 2 RESERVED
-enter handle_19:
- NULL
-Booting from Hard Disk...
-Booting from :7c00
So, it got most of the way through the reboot - there's only a few
function calls between the e820 map being dumped and the handle_19
call. The fault also seems to show it stopped in the BIOS in 16bit
mode:
> EIP=d331 EFL=00010202 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0
> ES = 9300
> CS =f000 000f 9b00
Can you add the patch below, force the fault, and forward the log.
Also, if you recreate the failure can you take the EIP from the fault
(eg, d331) and search for the corresponding function in the output of:
objdump -m i386 -M i8086 -M suffix -ldr out/rom16.o | less
(That is, search for "d331:".) If that's too much of a pain, just
send me a direct email with the seabios out/rom16.o file and the new
EIP of the fault. (I need the out/rom16.o that was used to build the
version of SeaBIOS that faulted.)
-Kevin
diff --git a/src/post.c b/src/post.c
index 9ea5620..bbd19c0 100644
--- a/src/post.c
+++ b/src/post.c
@@ -185,21 +185,24 @@ prepareboot(void)
pmm_prepboot();
malloc_prepboot();
memmap_prepboot();
+dprintf(1, "a\n");
HaveRunPost = 2;
// Setup bios checksum.
BiosChecksum -= checksum((u8*)BUILD_BIOS_ADDR, BUILD_BIOS_SIZE);
+dprintf(1, "b\n");
}
// Begin the boot process by invoking an int0x19 in 16bit mode.
void VISIBLE32FLAT
startBoot(void)
{
+dprintf(1, "e\n");
// Clear low-memory allocations (required by PMM spec).
memset((void*)BUILD_STACK_ADDR, 0, BUILD_EBDA_MINIMUM - BUILD_STACK_ADDR);
-dprintf(3, "Jump to int19\n");
+dprintf(1, "Jump to int19 (vector=%x)\n", GET_IVT(0x19).segoff);
struct bregs br;
memset(&br, 0, sizeof(br));
br.flags = F_IF;
@@ -239,9 +242,11 @@ maininit(void)
// Prepare for boot.
prepareboot();
+dprintf(1, "c\n");
// Write protect bios memory.
make_bios_readonly();
+dprintf(1, "d\n");
// Invoke int 19 to start boot process.
startBoot();
}
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: x86: kvm: Revert "remove sched notifier for cross-cpu migrations"
On Wed, Mar 25, 2015 at 3:41 PM, Marcelo Tosatti wrote: > On Wed, Mar 25, 2015 at 03:33:10PM -0700, Andy Lutomirski wrote: >> On Mar 25, 2015 2:29 PM, "Marcelo Tosatti" wrote: >> > >> > On Wed, Mar 25, 2015 at 01:52:15PM +0100, Radim Krčmář wrote: >> > > 2015-03-25 12:08+0100, Radim Krčmář: >> > > > Reverting the patch protects us from any migration, but I don't think >> > > > we >> > > > need to care about changing VCPUs as long as we read a consistent data >> > > > from kvmclock. (VCPU can change outside of this loop too, so it >> > > > doesn't >> > > > matter if we return a value not fit for this VCPU.) >> > > > >> > > > I think we could drop the second __getcpu if our kvmclock was being >> > > > handled better; maybe with a patch like the one below: >> > > >> > > The second __getcpu is not neccessary, but I forgot about rdtsc. >> > > We need to either use rtdscp, know the host has synchronized tsc, or >> > > monitor VCPU migrations. Only the last one works everywhere. >> > >> > The vdso code is only used if host has synchronized tsc. >> > >> > But you have to handle the case where host goes from synchronized tsc to >> > unsynchronized tsc (see the clocksource notifier in the host side). >> > >> >> Can't we change the host to freeze all vcpus and clear the stable bit >> on all of them if this happens? This would simplify and speed up >> vclock_gettime. >> >> --Andy > > Seems interesting to do on 512-vcpus, but sure, could be done. > If you have a 512-vcpu system that switches between stable and unstable more than once per migration, then I expect that you have serious problems and this is the least of your worries. Personally, I'd *much* rather we just made vcpu 0's pvti authoritative if we're stable. If nothing else, I'm not even remotely convinced that the current scheme gives monotonic timing due to skew between when the updates happen on different vcpus. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: x86: kvm: Revert "remove sched notifier for cross-cpu migrations"
On Wed, Mar 25, 2015 at 03:33:10PM -0700, Andy Lutomirski wrote: > On Mar 25, 2015 2:29 PM, "Marcelo Tosatti" wrote: > > > > On Wed, Mar 25, 2015 at 01:52:15PM +0100, Radim Krčmář wrote: > > > 2015-03-25 12:08+0100, Radim Krčmář: > > > > Reverting the patch protects us from any migration, but I don't think we > > > > need to care about changing VCPUs as long as we read a consistent data > > > > from kvmclock. (VCPU can change outside of this loop too, so it doesn't > > > > matter if we return a value not fit for this VCPU.) > > > > > > > > I think we could drop the second __getcpu if our kvmclock was being > > > > handled better; maybe with a patch like the one below: > > > > > > The second __getcpu is not neccessary, but I forgot about rdtsc. > > > We need to either use rtdscp, know the host has synchronized tsc, or > > > monitor VCPU migrations. Only the last one works everywhere. > > > > The vdso code is only used if host has synchronized tsc. > > > > But you have to handle the case where host goes from synchronized tsc to > > unsynchronized tsc (see the clocksource notifier in the host side). > > > > Can't we change the host to freeze all vcpus and clear the stable bit > on all of them if this happens? This would simplify and speed up > vclock_gettime. > > --Andy Seems interesting to do on 512-vcpus, but sure, could be done. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: x86: kvm: Revert "remove sched notifier for cross-cpu migrations"
On Mar 25, 2015 2:29 PM, "Marcelo Tosatti" wrote: > > On Wed, Mar 25, 2015 at 01:52:15PM +0100, Radim Krčmář wrote: > > 2015-03-25 12:08+0100, Radim Krčmář: > > > Reverting the patch protects us from any migration, but I don't think we > > > need to care about changing VCPUs as long as we read a consistent data > > > from kvmclock. (VCPU can change outside of this loop too, so it doesn't > > > matter if we return a value not fit for this VCPU.) > > > > > > I think we could drop the second __getcpu if our kvmclock was being > > > handled better; maybe with a patch like the one below: > > > > The second __getcpu is not neccessary, but I forgot about rdtsc. > > We need to either use rtdscp, know the host has synchronized tsc, or > > monitor VCPU migrations. Only the last one works everywhere. > > The vdso code is only used if host has synchronized tsc. > > But you have to handle the case where host goes from synchronized tsc to > unsynchronized tsc (see the clocksource notifier in the host side). > Can't we change the host to freeze all vcpus and clear the stable bit on all of them if this happens? This would simplify and speed up vclock_gettime. --Andy -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] E5-2620v2 - emulation stop error
On Wed, Mar 25, 2015 at 11:54 PM, Kevin O'Connor wrote: > On Wed, Mar 25, 2015 at 11:43:31PM +0300, Andrey Korolyov wrote: >> On Mon, Mar 16, 2015 at 10:17 PM, Andrey Korolyov wrote: >> > For now, it looks like bug have a mixed Murphy-Heisenberg nature, as >> > it appearance is very rare (compared to the number of actual launches) >> > and most probably bounded to the physical characteristics of my >> > production nodes. As soon as I reach any reproducible path for a >> > regular workstation environment, I`ll let everyone know. Also I am >> > starting to think that issue can belong to the particular motherboard >> > firmware revision, despite fact that the CPU microcode is the same >> > everywhere. >> >> >> Hello everyone, I`ve managed to reproduce this issue >> *deterministically* with latest seabios with smp fix and 3.18.3. The >> error occuring just *once* per vm until hypervisor reboots, at least >> in my setup, this is definitely crazy... >> >> - launch two VMs (Centos 7 in my case), >> - wait a little while they are booting, >> - attach serial console (I am using virsh list for this exact purpose), >> - issue acpi reboot or reset, does not matter, >> - VM always hangs at boot, most times with sgabios initialization >> string printed out [1], but sometimes it hangs a bit later [2], >> - no matter how many times I try to relaunch the QEMU afterwards, the >> issue does not appear on VM which experienced problem once; >> - trace and sample args can be seen in [3] and [4] respectively. > > Can you add something like: > > -chardev file,path=seabioslog.`date +%s`,id=seabios -device > isa-debugcon,iobase=0x402,chardev=seabios > > to the qemu command line and forward the resulting log from both a > succesful boot and a failed one? > > -Kevin Of course, logs are attached. reboot.failed Description: Binary data reboot.succeeded Description: Binary data
Re: [PATCH v2 06/12] KVM: mark kvm->buses as empty once they were destroyed
On Wed, Mar 25, 2015 at 05:09:13PM +, Marc Zyngier wrote: > On 23/03/15 15:58, Andre Przywara wrote: > > 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 with the VGIC using the > > kvm_io_bus later (the unregistering is in there to be able to roll > > back a faulting init). > > > > Signed-off-by: Andre Przywara > > That seems sensible, but I don't see why nobody else hits that. What are > we doing differently? It should be valid to call kvm_io_bus_unregister_dev after kvm_io_bus_destroy. Are you patching it to handle NULL kvm->buses[bus_idx] ? > Otherwise, > > Reviewed-by: Marc Zyngier > > Paolo, Marcelo, can we have your Ack on this? > > Thanks, -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL 3/3] KVM: PPC: Book3S HV: Fix instruction emulation
From: Paul Mackerras
Commit 4a157d61b48c ("KVM: PPC: Book3S HV: Fix endianness of
instruction obtained from HEIR register") had the side effect that
we no longer reset vcpu->arch.last_inst to -1 on guest exit in
the cases where the instruction is not fetched from the guest.
This means that if instruction emulation turns out to be required
in those cases, the host will emulate the wrong instruction, since
vcpu->arch.last_inst will contain the last instruction that was
emulated.
This fixes it by making sure that vcpu->arch.last_inst is reset
to -1 in those cases.
Signed-off-by: Paul Mackerras
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index bb94e6f..6cbf163 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -1005,6 +1005,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
/* Save HEIR (HV emulation assist reg) in emul_inst
if this is an HEI (HV emulation interrupt, e40) */
li r3,KVM_INST_FETCH_FAILED
+ stw r3,VCPU_LAST_INST(r9)
cmpwi r12,BOOK3S_INTERRUPT_H_EMUL_ASSIST
bne 11f
mfspr r3,SPRN_HEIR
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL 1/3] KVM: PPC: Book3S HV: Fix spinlock/mutex ordering issue in kvmppc_set_lpcr()
From: Paul Mackerras
Currently, kvmppc_set_lpcr() has a spinlock around the whole function,
and inside that does mutex_lock(&kvm->lock). It is not permitted to
take a mutex while holding a spinlock, because the mutex_lock might
call schedule(). In addition, this causes lockdep to warn about a
lock ordering issue:
==
[ INFO: possible circular locking dependency detected ]
3.18.0-kvm-04645-gdfea862-dirty #131 Not tainted
---
qemu-system-ppc/8179 is trying to acquire lock:
(&kvm->lock){+.+.+.}, at: [] .kvmppc_set_lpcr+0xf4/0x1c0
[kvm_hv]
but task is already holding lock:
(&(&vcore->lock)->rlock){+.+...}, at: []
.kvmppc_set_lpcr+0x40/0x1c0 [kvm_hv]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&(&vcore->lock)->rlock){+.+...}:
[] .mutex_lock_nested+0x80/0x570
[] .kvmppc_vcpu_run_hv+0xc4/0xe40 [kvm_hv]
[] .kvmppc_vcpu_run+0x2c/0x40 [kvm]
[] .kvm_arch_vcpu_ioctl_run+0x54/0x160 [kvm]
[] .kvm_vcpu_ioctl+0x4a8/0x7b0 [kvm]
[] .do_vfs_ioctl+0x444/0x770
[] .SyS_ioctl+0xc4/0xe0
[] syscall_exit+0x0/0x98
-> #0 (&kvm->lock){+.+.+.}:
[] .lock_acquire+0xcc/0x1a0
[] .mutex_lock_nested+0x80/0x570
[] .kvmppc_set_lpcr+0xf4/0x1c0 [kvm_hv]
[] .kvmppc_set_one_reg_hv+0x4dc/0x990 [kvm_hv]
[] .kvmppc_set_one_reg+0x44/0x330 [kvm]
[] .kvm_vcpu_ioctl_set_one_reg+0x5c/0x150 [kvm]
[] .kvm_arch_vcpu_ioctl+0x214/0x2c0 [kvm]
[] .kvm_vcpu_ioctl+0xe0/0x7b0 [kvm]
[] .do_vfs_ioctl+0x444/0x770
[] .SyS_ioctl+0xc4/0xe0
[] syscall_exit+0x0/0x98
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0CPU1
lock(&(&vcore->lock)->rlock);
lock(&kvm->lock);
lock(&(&vcore->lock)->rlock);
lock(&kvm->lock);
*** DEADLOCK ***
2 locks held by qemu-system-ppc/8179:
#0: (&vcpu->mutex){+.+.+.}, at: [] .vcpu_load+0x28/0x90
[kvm]
#1: (&(&vcore->lock)->rlock){+.+...}, at: []
.kvmppc_set_lpcr+0x40/0x1c0 [kvm_hv]
stack backtrace:
CPU: 4 PID: 8179 Comm: qemu-system-ppc Not tainted
3.18.0-kvm-04645-gdfea862-dirty #131
Call Trace:
[c01a66c0f310] [c0b486ac] .dump_stack+0x88/0xb4 (unreliable)
[c01a66c0f390] [c00f8bec] .print_circular_bug+0x27c/0x3d0
[c01a66c0f440] [c00fe9e8] .__lock_acquire+0x2028/0x2190
[c01a66c0f5d0] [c00ff28c] .lock_acquire+0xcc/0x1a0
[c01a66c0f6a0] [c0b3c120] .mutex_lock_nested+0x80/0x570
[c01a66c0f7c0] [decc1f54] .kvmppc_set_lpcr+0xf4/0x1c0 [kvm_hv]
[c01a66c0f860] [decc510c] .kvmppc_set_one_reg_hv+0x4dc/0x990
[kvm_hv]
[c01a66c0f8d0] [deb9f234] .kvmppc_set_one_reg+0x44/0x330 [kvm]
[c01a66c0f960] [deb9c9dc] .kvm_vcpu_ioctl_set_one_reg+0x5c/0x150
[kvm]
[c01a66c0f9f0] [deb9ced4] .kvm_arch_vcpu_ioctl+0x214/0x2c0 [kvm]
[c01a66c0faf0] [deb940b0] .kvm_vcpu_ioctl+0xe0/0x7b0 [kvm]
[c01a66c0fcb0] [c026cbb4] .do_vfs_ioctl+0x444/0x770
[c01a66c0fd90] [c026cfa4] .SyS_ioctl+0xc4/0xe0
[c01a66c0fe30] [c0009264] syscall_exit+0x0/0x98
This fixes it by moving the mutex_lock()/mutex_unlock() pair outside
the spin-locked region.
Signed-off-by: Paul Mackerras
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/book3s_hv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index de4018a..b273193 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -942,20 +942,20 @@ static int kvm_arch_vcpu_ioctl_set_sregs_hv(struct
kvm_vcpu *vcpu,
static void kvmppc_set_lpcr(struct kvm_vcpu *vcpu, u64 new_lpcr,
bool preserve_top32)
{
+ struct kvm *kvm = vcpu->kvm;
struct kvmppc_vcore *vc = vcpu->arch.vcore;
u64 mask;
+ mutex_lock(&kvm->lock);
spin_lock(&vc->lock);
/*
* If ILE (interrupt little-endian) has changed, update the
* MSR_LE bit in the intr_msr for each vcpu in this vcore.
*/
if ((new_lpcr & LPCR_ILE) != (vc->lpcr & LPCR_ILE)) {
- struct kvm *kvm = vcpu->kvm;
struct kvm_vcpu *vcpu;
int i;
- mutex_lock(&kvm->lock);
kvm_for_each_vcpu(i, vcpu, kvm) {
if (vcpu->arch.vcore != vc)
continue;
@@ -964,7 +964,6 @@ static void kvmppc_set_lpcr(struct kvm_vcpu *vcpu, u64
new_lpcr,
else
vcpu->arch.intr_msr &= ~MSR_LE;
}
- mutex_unlock(&kvm->lock);
}
/*
@@ -981,6 +980,7 @@ static void kvmppc_set_lpcr(struct kvm_vcpu *vcp
[PULL 2/3] KVM: PPC: Book3S HV: Endian fix for accessing VPA yield count
From: Paul Mackerras The VPA (virtual processor area) is defined by PAPR and is therefore big-endian, so we need a be32_to_cpu when reading it in kvmppc_get_yield_count(). Without this, H_CONFER always fails on a little-endian host, causing SMP guests to waste time spinning on spinlocks. Signed-off-by: Paul Mackerras Signed-off-by: Alexander Graf --- arch/powerpc/kvm/book3s_hv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c index b273193..de74756 100644 --- a/arch/powerpc/kvm/book3s_hv.c +++ b/arch/powerpc/kvm/book3s_hv.c @@ -636,7 +636,7 @@ static int kvmppc_get_yield_count(struct kvm_vcpu *vcpu) spin_lock(&vcpu->arch.vpa_update_lock); lppaca = (struct lppaca *)vcpu->arch.vpa.pinned_addr; if (lppaca) - yield_count = lppaca->yield_count; + yield_count = be32_to_cpu(lppaca->yield_count); spin_unlock(&vcpu->arch.vpa_update_lock); return yield_count; } -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL 0/3] 4.0 patch queue 2015-03-25
Hi Paolo, This is my current patch queue for 4.0. Please pull. Alex The following changes since commit f710a12d73dfa1c3a5d2417f2482b970f03bb850: Merge tag 'kvm-arm-fixes-4.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm (2015-03-16 20:08:56 -0300) are available in the git repository at: git://github.com/agraf/linux-2.6.git tags/signed-for-4.0 for you to fetch changes up to 2bf27601c7b50b6ced72f27304109dc52eb52919: KVM: PPC: Book3S HV: Fix instruction emulation (2015-03-20 11:42:33 +0100) Patch queue for 4.0 - 2015-03-25 A few bug fixes for Book3S HV KVM: - Fix spinlock ordering - Fix idle guests on LE hosts - Fix instruction emulation Paul Mackerras (3): KVM: PPC: Book3S HV: Fix spinlock/mutex ordering issue in kvmppc_set_lpcr() KVM: PPC: Book3S HV: Endian fix for accessing VPA yield count KVM: PPC: Book3S HV: Fix instruction emulation arch/powerpc/kvm/book3s_hv.c| 8 arch/powerpc/kvm/book3s_hv_rmhandlers.S | 1 + 2 files changed, 5 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 04/12] KVM: x86: remove now unneeded include directory from Makefile
On Wed, Mar 25, 2015 at 05:01:52PM +, Marc Zyngier wrote: > On 23/03/15 15:58, Andre Przywara wrote: > > 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 > > Reviewed-by: Marc Zyngier > > Paolo, Marcelo: can we have your Ack on this? > > Thanks, > > M. Reviewed-by: Marcelo Tosatti -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 02/12] KVM: move iodev.h from virt/kvm/ to include/kvm
On Wed, Mar 25, 2015 at 05:00:02PM +, Marc Zyngier wrote: > On 23/03/15 15:58, Andre Przywara wrote: > > 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 the file into include/kvm, so that a > > more natural "#include " can be used by all of the code. > > This also solves a problem later when using struct kvm_io_device > > in arm_vgic.h. > > Fixing up the FSF address in the GPL header and a wrong include path > > on the way. > > > > Signed-off-by: Andre Przywara > > Acked-by: Christoffer Dall > > Reviewed-by: Marc Zyngier > > Paolo, Marcelo: can we have your Ack on this? > > Thanks, Reviewed-by: Marcelo Tosatti -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: x86: kvm: Revert "remove sched notifier for cross-cpu migrations"
On Wed, Mar 25, 2015 at 01:52:15PM +0100, Radim Krčmář wrote: > 2015-03-25 12:08+0100, Radim Krčmář: > > Reverting the patch protects us from any migration, but I don't think we > > need to care about changing VCPUs as long as we read a consistent data > > from kvmclock. (VCPU can change outside of this loop too, so it doesn't > > matter if we return a value not fit for this VCPU.) > > > > I think we could drop the second __getcpu if our kvmclock was being > > handled better; maybe with a patch like the one below: > > The second __getcpu is not neccessary, but I forgot about rdtsc. > We need to either use rtdscp, know the host has synchronized tsc, or > monitor VCPU migrations. Only the last one works everywhere. The vdso code is only used if host has synchronized tsc. But you have to handle the case where host goes from synchronized tsc to unsynchronized tsc (see the clocksource notifier in the host side). -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] E5-2620v2 - emulation stop error
On Wed, Mar 25, 2015 at 11:43:31PM +0300, Andrey Korolyov wrote: > On Mon, Mar 16, 2015 at 10:17 PM, Andrey Korolyov wrote: > > For now, it looks like bug have a mixed Murphy-Heisenberg nature, as > > it appearance is very rare (compared to the number of actual launches) > > and most probably bounded to the physical characteristics of my > > production nodes. As soon as I reach any reproducible path for a > > regular workstation environment, I`ll let everyone know. Also I am > > starting to think that issue can belong to the particular motherboard > > firmware revision, despite fact that the CPU microcode is the same > > everywhere. > > > Hello everyone, I`ve managed to reproduce this issue > *deterministically* with latest seabios with smp fix and 3.18.3. The > error occuring just *once* per vm until hypervisor reboots, at least > in my setup, this is definitely crazy... > > - launch two VMs (Centos 7 in my case), > - wait a little while they are booting, > - attach serial console (I am using virsh list for this exact purpose), > - issue acpi reboot or reset, does not matter, > - VM always hangs at boot, most times with sgabios initialization > string printed out [1], but sometimes it hangs a bit later [2], > - no matter how many times I try to relaunch the QEMU afterwards, the > issue does not appear on VM which experienced problem once; > - trace and sample args can be seen in [3] and [4] respectively. Can you add something like: -chardev file,path=seabioslog.`date +%s`,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios to the qemu command line and forward the resulting log from both a succesful boot and a failed one? -Kevin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] E5-2620v2 - emulation stop error
> - attach serial console (I am using virsh list for this exact purpose), virsh console of course, sorry -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] E5-2620v2 - emulation stop error
On Mon, Mar 16, 2015 at 10:17 PM, Andrey Korolyov wrote: > For now, it looks like bug have a mixed Murphy-Heisenberg nature, as > it appearance is very rare (compared to the number of actual launches) > and most probably bounded to the physical characteristics of my > production nodes. As soon as I reach any reproducible path for a > regular workstation environment, I`ll let everyone know. Also I am > starting to think that issue can belong to the particular motherboard > firmware revision, despite fact that the CPU microcode is the same > everywhere. Hello everyone, I`ve managed to reproduce this issue *deterministically* with latest seabios with smp fix and 3.18.3. The error occuring just *once* per vm until hypervisor reboots, at least in my setup, this is definitely crazy... - launch two VMs (Centos 7 in my case), - wait a little while they are booting, - attach serial console (I am using virsh list for this exact purpose), - issue acpi reboot or reset, does not matter, - VM always hangs at boot, most times with sgabios initialization string printed out [1], but sometimes it hangs a bit later [2], - no matter how many times I try to relaunch the QEMU afterwards, the issue does not appear on VM which experienced problem once; - trace and sample args can be seen in [3] and [4] respectively. 1) Google, Inc. Serial Graphics Adapter 06/11/14 SGABIOS $Id: sgabios.S 8 2010-04-22 00:03:40Z nlaredo $ (pbuilder@zorak) Wed Jun 11 05:57:34 UTC 2014 Term: 211x62 4 0 2) Google, Inc. Serial Graphics Adapter 06/11/14 SGABIOS $Id: sgabios.S 8 2010-04-22 00:03:40Z nlaredo $ (pbuilder@zorak) Wed Jun 11 05:57:34 UTC 2014 Term: 211x62 4 0 [...empty screen...] SeaBIOS (version 1.8.1-20150325_230423-testnode) Machine UUID 3c78721f-7317-4f85-bcbe-f5ad46d293a1 iPXE (http://ipxe.org) 00:02.0 C100 PCI2.10 PnP PMM+3FF95BA0+3FEF5BA0 C10 3) KVM internal error. Suberror: 2 extra data[0]: 80ef extra data[1]: 8b0d EAX= EBX= ECX= EDX= ESI= EDI= EBP= ESP=6d2c EIP=d331 EFL=00010202 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES = 9300 CS =f000 000f 9b00 SS = 9300 DS = 9300 FS = 9300 GS = 9300 LDT= 8200 TR = 8b00 GDT= 000f6cb0 0037 IDT= 03ff CR0=0010 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=66 c3 cd 02 cb cd 10 cb cd 13 cb cd 15 cb cd 16 cb cd 18 cb 19 cb cd 1c cb cd 4a cb fa fc 66 ba 47 d3 0f 00 e9 ad fe f3 90 f0 0f ba 2d d4 fe fb 3f 4) /usr/bin/qemu-system-x86_64 -name centos71 -S -machine pc-i440fx-2.1,accel=kvm,usb=off -cpu SandyBridge,+kvm_pv_eoi -bios /usr/share/seabios/bios.bin -m 1024 -realtime mlock=off -smp 12,sockets=1,cores=12,threads=12 -uuid 3c78721f-7317-4f85-bcbe-f5ad46d293a1 -nographic -no-user-config -nodefaults -device sga -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/centos71.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device nec-usb-xhci,id=usb,bus=pci.0,addr=0x3 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive file=rbd:dev-rack2/centos7-1.raw:id=qemukvm:key=XX:auth_supported=cephx\;none:mon_host=10.6.0.1\:6789\;10.6.0.3\:6789\;10.6.0.4\:6789,if=none,id=drive-virtio-disk0,format=raw,cache=writeback,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/centos71.sock,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.1 -msg timestamp=on -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] qspinlock stuff -v15
On Mon, Mar 16, 2015 at 02:16:13PM +0100, Peter Zijlstra wrote: > Hi Waiman, > > As promised; here is the paravirt stuff I did during the trip to BOS last > week. > > All the !paravirt patches are more or less the same as before (the only real > change is the copyright lines in the first patch). > > The paravirt stuff is 'simple' and KVM only -- the Xen code was a little more > convoluted and I've no real way to test that but it should be stright fwd to > make work. > > I ran this using the virtme tool (thanks Andy) on my laptop with a 4x > overcommit on vcpus (16 vcpus as compared to the 4 my laptop actually has) and > it both booted and survived a hackbench run (perf bench sched messaging -g 20 > -l 5000). > > So while the paravirt code isn't the most optimal code ever conceived it does > work. > > Also, the paravirt patching includes replacing the call with "movb $0, %arg1" > for the native case, which should greatly reduce the cost of having > CONFIG_PARAVIRT_SPINLOCKS enabled on actual hardware. Ah nice. That could be spun out as a seperate patch to optimize the existing ticket locks I presume. Now with the old pv ticketlock code an vCPU would only go to sleep once and be woken up when it was its turn. With this new code it is woken up twice (and twice it goes to sleep). With an overcommit scenario this would imply that we will have at least twice as many VMEXIT as with the previous code. I presume when you did benchmarking this did not even register? Thought I wonder if it would if you ran the benchmark for a week or so. > > I feel that if someone were to do a Xen patch we can go ahead and merge this > stuff (finally!). > > These patches do not implement the paravirt spinlock debug stats currently > implemented (separately) by KVM and Xen, but that should not be too hard to do > on top and in the 'generic' code -- no reason to duplicate all that. > > Of course; once this lands people can look at improving the paravirt nonsense. > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: arm/arm64: fix MMIO handling on userland induced accesses
On 24/03/15 16:03, Andre Przywara wrote: > The guest is not the only user of the MMIO handling routines, userland > can also read and write to those handlers. Since we don't use the > KVM iobus framework in this case, we have to set the data pointer to > some actual memory before executing the handler routines. > This allows to use QEMU as the userland control tool. > > Signed-off-by: Andre Przywara > --- > Hi, > > just embarrassingly realised that I haven't tested the latest version of this > series with QEMU, so this bug slipped me. Sorry for that! I will merge this > patch in the next revision of this series (or just send a new version of > 11/12). I'll squash it into patch #11 when I merge it. Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 12/12] KVM: arm/arm64: remove now obsolete VGIC specific MMIO handling code
On 23/03/15 15:58, Andre Przywara wrote: > 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 Reviewed-by: Marc Zyngier M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 10/12] KVM: arm/arm64: prepare GICv3 emulation to use kvm_io_bus MMIO handling
On 23/03/15 15:58, Andre Przywara wrote:
> 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: VCPU) they are connected with.
> We use the kvm_io_bus framework to register two devices per VCPU, as
> each block is handled independently by the VGIC code.
>
> Signed-off-by: Andre Przywara
> ---
> include/kvm/arm_vgic.h |1 +
> virt/kvm/arm/vgic-v3-emul.c | 34 +-
> virt/kvm/arm/vgic.c | 18 ++
> 3 files changed, 52 insertions(+), 1 deletion(-)
>
> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
> index 4523984..d6705f4 100644
> --- a/include/kvm/arm_vgic.h
> +++ b/include/kvm/arm_vgic.h
> @@ -252,6 +252,7 @@ struct vgic_dist {
>
> struct vgic_vm_ops vm_ops;
> struct vgic_io_device dist_iodev;
> + struct vgic_io_device *redist_iodevs;
> };
>
> struct vgic_v2_cpu_if {
> diff --git a/virt/kvm/arm/vgic-v3-emul.c b/virt/kvm/arm/vgic-v3-emul.c
> index 14943e3..35679d1 100644
> --- a/virt/kvm/arm/vgic-v3-emul.c
> +++ b/virt/kvm/arm/vgic-v3-emul.c
> @@ -766,6 +766,9 @@ static int vgic_v3_map_resources(struct kvm *kvm,
> {
> int ret = 0;
> struct vgic_dist *dist = &kvm->arch.vgic;
> + gpa_t rdbase = dist->vgic_redist_base;
> + struct vgic_io_device *iodevs = NULL;
> + int i;
>
> if (!irqchip_in_kernel(kvm))
> return 0;
> @@ -791,7 +794,36 @@ static int vgic_v3_map_resources(struct kvm *kvm,
> goto out;
> }
>
> - kvm->arch.vgic.ready = true;
> + ret = vgic_register_kvm_io_dev(kvm, dist->vgic_dist_base,
> +GIC_V3_DIST_SIZE, vgic_v3_dist_ranges,
> +-1, &dist->dist_iodev);
> + if (ret)
> + goto out;
> +
> + iodevs = kcalloc(dist->nr_cpus * 2, sizeof(iodevs[0]), GFP_KERNEL);
> + if (!iodevs) {
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + /* kvm_vgic_destroy() will take care of destroying the devices later. */
> + for (i = 0; i < dist->nr_cpus; i++) {
> + ret = vgic_register_kvm_io_dev(kvm, rdbase,
> +SZ_64K, vgic_redist_ranges,
> +i, &iodevs[i * 2]);
> + if (ret)
> + goto out;
> + ret = vgic_register_kvm_io_dev(kvm, rdbase + SGI_BASE_OFFSET,
> +SZ_64K, vgic_redist_sgi_ranges,
> +i, &iodevs[i * 2 + 1]);
> + if (ret)
> + goto out;
> + rdbase += GIC_V3_REDIST_SIZE;
> + }
The "two devices per redistributor" sent me spinning for a while. I can
see why you're doing so (it makes it easier to switch from one model to
the other), but I'd really like to see a subsequent patch that merge them.
It will be a lot more readable, and will match the architecture (despite
being on two separate 64k pages, they are part of the same device).
> +
> + dist->redist_iodevs = iodevs;
> + dist->ready = true;
> +
> out:
> if (ret)
> kvm_vgic_destroy(kvm);
> diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
> index 9a732d0..9cbb55f4 100644
> --- a/virt/kvm/arm/vgic.c
> +++ b/virt/kvm/arm/vgic.c
> @@ -992,6 +992,8 @@ int vgic_register_kvm_io_dev(struct kvm *kvm, gpa_t base,
> int len,
> static void vgic_unregister_kvm_io_dev(struct kvm *kvm)
> {
> struct vgic_dist *dist = &kvm->arch.vgic;
> + struct vgic_io_device *iodevs;
> + int i;
>
> if (!dist || !kvm->buses[KVM_MMIO_BUS])
> return;
> @@ -1001,6 +1003,22 @@ static void vgic_unregister_kvm_io_dev(struct kvm *kvm)
> if (dist->dist_iodev.dev.ops)
> kvm_io_bus_unregister_dev(kvm, KVM_MMIO_BUS,
> &dist->dist_iodev.dev);
> +
> + iodevs = dist->redist_iodevs;
> + if (iodevs) {
> + for (i = 0; i < dist->nr_cpus * 2; i++) {
> + /*
> + * Because of a failed initialization we could get here
> + * without ever having registered a device.
> + */
> + if (!iodevs[i].dev.ops)
> + continue;
> + kvm_io_bus_unregister_dev(kvm, KVM_MMIO_BUS,
> + &iodevs[i].dev);
> + }
> + kfree(iodevs);
> + dist->redist_iodevs = NULL;
> + }
> mutex_unlock(&kvm->slots_lock);
> }
>
>
Other than the above,
Reviewed-by: Marc Zyngier
M.
--
Jazz is not dead. It just smells funny...
--
To
Re: [PATCH v2 09/12] KVM: arm/arm64: prepare GICv2 emulation to be handled by kvm_io_bus
On 23/03/15 15:58, Andre Przywara wrote: > 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 Reviewed-by: Marc Zyngier M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Xen-devel] ARM: KVM/XEN: how should we support virt-what?
On Wed, 25 Mar 2015, Ian Campbell wrote: > On Wed, 2015-03-25 at 10:44 +0100, Andrew Jones wrote: > > Hello ARM virt maintainers, > > > > I'd like to start a discussion about supporting virt-what[1]. virt-what > > allows userspace to determine if the system it's running on is running > > in a guest, and of what type (KVM, Xen, etc.). Despite it being a best > > effort tool, see the Caveat emptor in [1], it has become quite a useful > > tool, and is showing up in different places, such as OpenStack. If you > > look at the code[2], specifically [3], then you'll see how it works on > > x86, which is to use the dedicated hypervisor cpuid leaves. I'm > > wondering what equivalent we have, or can develop, for arm. > > Here are some thoughts; > > 0) there's already something we can use, and I just need to be told > >about it. > > 1) be as similar as possible to x86 by dedicating some currently > >undefined sysreg bits. This would take buy-in from lots of parties, > >so is not likely the way to go. > > 2) create a specific DT node that will get exposed through sysfs, or > >somewhere. > > 3) same as (2), but just use the nodes currently in mach-virt's DT > >as the indication we're a guest. This would just be a heuristic, > >i.e. "have virtio mmio" && psci.method == hvc, or something, > >and we'd still need a way to know if we're kvm vs. xen vs. ??. > > FWIW Xen has a specific node, > https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/tree/Bindings/arm/xen.txt > > Doesn't help you with ACPI systems though. IIRC there will be a Xen > table of some sort. This is the Xen specific ACPI table: http://wiki.xenproject.org/mediawiki/images/c/c4/Xen-environment-table.pdf -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 08/12] KVM: arm/arm64: implement kvm_io_bus MMIO handling for the VGIC
On 23/03/15 15:58, Andre Przywara wrote: > 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 patches. > > Signed-off-by: Andre Przywara Reviewed-by: Marc Zyngier M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/12] KVM: arm/arm64: simplify vgic_find_range() and callers
On 23/03/15 15:58, Andre Przywara wrote: > 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 directly. > > Signed-off-by: Andre Przywara > Reviewed-by: Christoffer Dall Reviewed-by: Marc Zyngier M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 06/12] KVM: mark kvm->buses as empty once they were destroyed
On 23/03/15 15:58, Andre Przywara wrote:
> 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 with the VGIC using the
> kvm_io_bus later (the unregistering is in there to be able to roll
> back a faulting init).
>
> Signed-off-by: Andre Przywara
That seems sensible, but I don't see why nobody else hits that. What are
we doing differently?
Otherwise,
Reviewed-by: Marc Zyngier
Paolo, Marcelo, can we have your Ack on this?
Thanks,
M.
> ---
> virt/kvm/kvm_main.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 8c7ab0b..6f164eb 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -604,8 +604,10 @@ static void kvm_destroy_vm(struct kvm *kvm)
> list_del(&kvm->vm_list);
> spin_unlock(&kvm_lock);
> kvm_free_irq_routing(kvm);
> - for (i = 0; i < KVM_NR_BUSES; i++)
> + for (i = 0; i < KVM_NR_BUSES; i++) {
> kvm_io_bus_destroy(kvm->buses[i]);
> + kvm->buses[i] = NULL;
> + }
> kvm_coalesced_mmio_free(kvm);
> #if defined(CONFIG_MMU_NOTIFIER) && defined(KVM_ARCH_WANT_MMU_NOTIFIER)
> mmu_notifier_unregister(&kvm->mmu_notifier, kvm->mm);
>
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 04/12] KVM: x86: remove now unneeded include directory from Makefile
On 23/03/15 15:58, Andre Przywara wrote: > 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 Reviewed-by: Marc Zyngier Paolo, Marcelo: can we have your Ack on this? Thanks, M. > --- > arch/x86/kvm/Makefile |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile > index 08f790d..16e8f96 100644 > --- a/arch/x86/kvm/Makefile > +++ b/arch/x86/kvm/Makefile > @@ -1,5 +1,5 @@ > > -ccflags-y += -Ivirt/kvm -Iarch/x86/kvm > +ccflags-y += -Iarch/x86/kvm > > CFLAGS_x86.o := -I. > CFLAGS_svm.o := -I. > -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 05/12] KVM: arm/arm64: rename struct kvm_mmio_range to vgic_io_range
On 23/03/15 15:58, Andre Przywara wrote: > 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 Reviewed-by: Marc Zyngier M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 03/12] KVM: arm/arm64: remove now unneeded include directory from Makefile
On 23/03/15 15:58, Andre Przywara wrote: > 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: Christoffer Dall Reviewed-by: Marc Zyngier M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 02/12] KVM: move iodev.h from virt/kvm/ to include/kvm
On 23/03/15 15:58, Andre Przywara wrote:
> 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 the file into include/kvm, so that a
> more natural "#include " can be used by all of the code.
> This also solves a problem later when using struct kvm_io_device
> in arm_vgic.h.
> Fixing up the FSF address in the GPL header and a wrong include path
> on the way.
>
> Signed-off-by: Andre Przywara
> Acked-by: Christoffer Dall
Reviewed-by: Marc Zyngier
Paolo, Marcelo: can we have your Ack on this?
Thanks,
M.
> ---
> arch/powerpc/kvm/mpic.c |2 +-
> arch/x86/kvm/i8254.h |2 +-
> arch/x86/kvm/ioapic.h |2 +-
> arch/x86/kvm/irq.h|2 +-
> arch/x86/kvm/lapic.h |2 +-
> include/kvm/iodev.h | 76
> virt/kvm/coalesced_mmio.c |2 +-
> virt/kvm/eventfd.c|2 +-
> virt/kvm/iodev.h | 77
> -
> virt/kvm/kvm_main.c |2 +-
> 10 files changed, 84 insertions(+), 85 deletions(-)
> create mode 100644 include/kvm/iodev.h
> delete mode 100644 virt/kvm/iodev.h
>
> diff --git a/arch/powerpc/kvm/mpic.c b/arch/powerpc/kvm/mpic.c
> index 8542f07..4703fad 100644
> --- a/arch/powerpc/kvm/mpic.c
> +++ b/arch/powerpc/kvm/mpic.c
> @@ -34,7 +34,7 @@
> #include
> #include
> #include
> -#include "iodev.h"
> +#include
>
> #define MAX_CPU 32
> #define MAX_SRC 256
> diff --git a/arch/x86/kvm/i8254.h b/arch/x86/kvm/i8254.h
> index dd1b16b..c84990b 100644
> --- a/arch/x86/kvm/i8254.h
> +++ b/arch/x86/kvm/i8254.h
> @@ -3,7 +3,7 @@
>
> #include
>
> -#include "iodev.h"
> +#include
>
> struct kvm_kpit_channel_state {
> u32 count; /* can be 65536 */
> diff --git a/arch/x86/kvm/ioapic.h b/arch/x86/kvm/ioapic.h
> index c2e36d9..d9e02ca 100644
> --- a/arch/x86/kvm/ioapic.h
> +++ b/arch/x86/kvm/ioapic.h
> @@ -3,7 +3,7 @@
>
> #include
>
> -#include "iodev.h"
> +#include
>
> struct kvm;
> struct kvm_vcpu;
> diff --git a/arch/x86/kvm/irq.h b/arch/x86/kvm/irq.h
> index 2d03568..ad68c73 100644
> --- a/arch/x86/kvm/irq.h
> +++ b/arch/x86/kvm/irq.h
> @@ -27,7 +27,7 @@
> #include
> #include
>
> -#include "iodev.h"
> +#include
> #include "ioapic.h"
> #include "lapic.h"
>
> diff --git a/arch/x86/kvm/lapic.h b/arch/x86/kvm/lapic.h
> index 0bc6c65..e284c28 100644
> --- a/arch/x86/kvm/lapic.h
> +++ b/arch/x86/kvm/lapic.h
> @@ -1,7 +1,7 @@
> #ifndef __KVM_X86_LAPIC_H
> #define __KVM_X86_LAPIC_H
>
> -#include "iodev.h"
> +#include
>
> #include
>
> diff --git a/include/kvm/iodev.h b/include/kvm/iodev.h
> new file mode 100644
> index 000..a6d208b
> --- /dev/null
> +++ b/include/kvm/iodev.h
> @@ -0,0 +1,76 @@
> +/*
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see
Re: [PATCH v2 01/12] KVM: Redesign kvm_io_bus_ API to pass VCPU structure to the callbacks.
On 23/03/15 15:58, Andre Przywara wrote: > 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 Reviewed-by: Marc Zyngier M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Guest memory backed by PCI BAR (x86)
Hello, I have an unusual goal of presenting SDRAM located on a real PCIe device (exposed via BAR) to a guest as normal memory. Eventually I'd like to split up guest memory between PCI memory and host memory as different NUMA nodes to optimize performance; but for now I'm focusing on just getting the guest to use memory over PCIe entirely, ignoring the awful performance. My first attempt was to modify qemu's "-mem-path" parameter to also support mmap()able files in addition to hugetlbfs paths. This was fairly straightforward, and using a tmpfs file (backed by host SDRAM) as guest RAM appears to work fine. I was hoping I could then use a PCI sysfs resource file instead of a tmpfs file (i.e., /sys/bus/pci/devices/:bb:ss.f/resourceN) to achieve the desired effect. But I haven't been able to get Linux or memtest86+ to boot with this arrangement. It only boots when KVM acceleration is disabled. When KVM acceleration is enabled, SeaBIOS seems to function fine running out of PCI memory space, but booting the OS resets. Specifically, the following happens (I'll stick with the memtest86+ 5.01 test case for simplicity): setup.S of memtest: ---[snip]--- /* * Note that the short jump isn't strictly needed, althought there are * reasons why it might be a good idea. It won't hurt in any case. */ movw$0x0001, %ax# protected mode (PE) bit lmsw%ax # This is it# jmp flush_instr flush_instr: movw$KERNEL_DS, %ax movw%ax, %ds movw%ax, %es movw%ax, %ss< broken here movw%ax, %fs movw%ax, %gs ---[snip]--- In this portion that's attempting to enter protected mode, the "movw %ax, %ss" instruction execution results in the guest resetting. gdb shows that after stepping through this instruction, CS:IP points to F000:E05B (entry_post within SeaBIOS). I'm new to KVM, so I'm hoping someone could provide some guidance on what might be wrong, what you'd recommend to get this working, or how I might debug this better. I'm using qemu 2.2.0 and an EL6 kernel (2.6.32-358.23.2.el6.x86_64). Thanks, Nate -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.16.y-ckt 070/165] KVM: MIPS: Fix trace event to save PC directly
3.16.7-ckt9 -stable review patch. If anyone has any objections, please let me
know.
--
From: James Hogan
commit b3cffac04eca9af46e1e23560a8ee22b1bd36d43 upstream.
Currently the guest exit trace event saves the VCPU pointer to the
structure, and the guest PC is retrieved by dereferencing it when the
event is printed rather than directly from the trace record. This isn't
safe as the printing may occur long afterwards, after the PC has changed
and potentially after the VCPU has been freed. Usually this results in
the same (wrong) PC being printed for multiple trace events. It also
isn't portable as userland has no way to access the VCPU data structure
when interpreting the trace record itself.
Lets save the actual PC in the structure so that the correct value is
accessible later.
Fixes: 669e846e6c4e ("KVM/MIPS32: MIPS arch specific APIs for KVM")
Signed-off-by: James Hogan
Cc: Paolo Bonzini
Cc: Ralf Baechle
Cc: Marcelo Tosatti
Cc: Gleb Natapov
Cc: Steven Rostedt
Cc: Ingo Molnar
Cc: linux-m...@linux-mips.org
Cc: kvm@vger.kernel.org
Acked-by: Steven Rostedt
Signed-off-by: Marcelo Tosatti
Signed-off-by: Luis Henriques
---
arch/mips/kvm/trace.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/mips/kvm/trace.h b/arch/mips/kvm/trace.h
index bc9e0f406c08..e51621e36152 100644
--- a/arch/mips/kvm/trace.h
+++ b/arch/mips/kvm/trace.h
@@ -26,18 +26,18 @@ TRACE_EVENT(kvm_exit,
TP_PROTO(struct kvm_vcpu *vcpu, unsigned int reason),
TP_ARGS(vcpu, reason),
TP_STRUCT__entry(
- __field(struct kvm_vcpu *, vcpu)
+ __field(unsigned long, pc)
__field(unsigned int, reason)
),
TP_fast_assign(
- __entry->vcpu = vcpu;
+ __entry->pc = vcpu->arch.pc;
__entry->reason = reason;
),
TP_printk("[%s]PC: 0x%08lx",
kvm_mips_exit_types_str[__entry->reason],
- __entry->vcpu->arch.pc)
+ __entry->pc)
);
#endif /* _TRACE_KVM_H */
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: x86: kvm: Revert "remove sched notifier for cross-cpu migrations"
2015-03-23 20:21-0300, Marcelo Tosatti: > 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 Tosatti > CC: sta...@kernel.org # 3.11+ Please improve the commit message. "KVM: x86: update pvclock area conditionally [...]" was merged half a year before the patch we are reverting and is completely unrelated to the bug we are fixing now, (reverted patch just was just wrong) Reviewed-by: Radim Krčmář > diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c > @@ -82,18 +82,15 @@ static notrace cycle_t vread_pvclock(int *mode) > /* > - * Note: hypervisor must guarantee that: > - * 1. cpu ID number maps 1:1 to per-CPU pvclock time info. > - * 2. that per-CPU pvclock time info is updated if the > - *underlying CPU changes. > - * 3. that version is increased whenever underlying CPU > - *changes. > - * > + * When looping to get a consistent (time-info, tsc) pair, we > + * also need to deal with the possibility we can switch vcpus, > + * so make sure we always re-fetch time-info for the current vcpu. (All points from the original comment need to hold -- it would be nicer to keep both.) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: x86: kvm: Revert "remove sched notifier for cross-cpu migrations"
2015-03-25 12:08+0100, Radim Krčmář: > Reverting the patch protects us from any migration, but I don't think we > need to care about changing VCPUs as long as we read a consistent data > from kvmclock. (VCPU can change outside of this loop too, so it doesn't > matter if we return a value not fit for this VCPU.) > > I think we could drop the second __getcpu if our kvmclock was being > handled better; maybe with a patch like the one below: The second __getcpu is not neccessary, but I forgot about rdtsc. We need to either use rtdscp, know the host has synchronized tsc, or monitor VCPU migrations. Only the last one works everywhere. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM: KVM/XEN: how should we support virt-what?
On 25/03/15 09:44, Andrew Jones wrote: > Hello ARM virt maintainers, > > I'd like to start a discussion about supporting virt-what[1]. virt-what > allows userspace to determine if the system it's running on is running > in a guest, and of what type (KVM, Xen, etc.). Despite it being a best > effort tool, see the Caveat emptor in [1], it has become quite a useful > tool, and is showing up in different places, such as OpenStack. If you > look at the code[2], specifically [3], then you'll see how it works on > x86, which is to use the dedicated hypervisor cpuid leaves. I'm > wondering what equivalent we have, or can develop, for arm. > Here are some thoughts; > 0) there's already something we can use, and I just need to be told >about it. > 1) be as similar as possible to x86 by dedicating some currently >undefined sysreg bits. This would take buy-in from lots of parties, >so is not likely the way to go. > 2) create a specific DT node that will get exposed through sysfs, or >somewhere. > 3) same as (2), but just use the nodes currently in mach-virt's DT >as the indication we're a guest. This would just be a heuristic, >i.e. "have virtio mmio" && psci.method == hvc, or something, >and we'd still need a way to know if we're kvm vs. xen vs. ??. KVM doesn't have any specific DT node so far (at least kvmtool doesn't expose anything, and QEMU doesn't seem to do it either). You could define KVM as being !Xen by looking for the Xen hypervisor node, but that's quite a heuristic. Overall, I'm quite reluctant to introduce things that would immediately become an ABI (cue the recent bogomips flame wars), forming a contract between the host userspace and the guest userspace. M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: x86: kvm: Revert "remove sched notifier for cross-cpu migrations"
2015-03-24 19:59-0300, Marcelo Tosatti: > On Tue, Mar 24, 2015 at 04:34:12PM +0100, Radim Krčmář wrote: > > 2015-03-23 20:21-0300, Marcelo Tosatti: > > > 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". > > > > I think that the revert doesn't fix point 2.: "KVM: x86: update pvclock > > [...]" changed the host to skip clock update on physical CPU change, but > > guest's task migration notifier isn't tied to it at all. > > "per-CPU pvclock time info is updated if the underlying CPU changes" > is the same as > "always perform clock update on physical CPU change". > > That was a requirement for the original patch, to drop migration > notifiers. > > > (Guest can have all tasks pinned, so the revert changed nothing.) > > > > > Add task migration notification back. > > > > > > Problem noticed by Andy Lutomirski. > > > > What is the problem? > > > > Thanks. > > The problem is this: > > T1) guest thread1 on vcpu1. > T2) guest thread1 on vcpu2. > T3) guest thread1 on vcpu1. > > Inside a pvclock read loop. > > Since the writes by hypervisor of pvclock area are not ordered, > you cannot rely on version being updated _before_ > the rest of pvclock data. > > (in the case above, "has the physical cpu changed" check, inside the > guests thread1, obviously fails). Ah, thanks! so the "KVM: x86: update pvclock area conditionally [...]" has nothing to do with it -- that really confused me. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Xen-devel] ARM: KVM/XEN: how should we support virt-what?
On Wed, 2015-03-25 at 10:44 +0100, Andrew Jones wrote: > Hello ARM virt maintainers, > > I'd like to start a discussion about supporting virt-what[1]. virt-what > allows userspace to determine if the system it's running on is running > in a guest, and of what type (KVM, Xen, etc.). Despite it being a best > effort tool, see the Caveat emptor in [1], it has become quite a useful > tool, and is showing up in different places, such as OpenStack. If you > look at the code[2], specifically [3], then you'll see how it works on > x86, which is to use the dedicated hypervisor cpuid leaves. I'm > wondering what equivalent we have, or can develop, for arm. > Here are some thoughts; > 0) there's already something we can use, and I just need to be told >about it. > 1) be as similar as possible to x86 by dedicating some currently >undefined sysreg bits. This would take buy-in from lots of parties, >so is not likely the way to go. > 2) create a specific DT node that will get exposed through sysfs, or >somewhere. > 3) same as (2), but just use the nodes currently in mach-virt's DT >as the indication we're a guest. This would just be a heuristic, >i.e. "have virtio mmio" && psci.method == hvc, or something, >and we'd still need a way to know if we're kvm vs. xen vs. ??. FWIW Xen has a specific node, https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/tree/Bindings/arm/xen.txt Doesn't help you with ACPI systems though. IIRC there will be a Xen table of some sort. Ian. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: x86: kvm: Revert "remove sched notifier for cross-cpu migrations"
2015-03-24 15:33-0700, Andy Lutomirski: > On Tue, Mar 24, 2015 at 8:34 AM, Radim Krčmář wrote: > > What is the problem? > > The kvmclock spec says that the host will increment a version field to > an odd number, then update stuff, then increment it to an even number. > The host is buggy and doesn't do this, and the result is observable > when one vcpu reads another vcpu's kvmclock data. > > Since there's no good way for a guest kernel to keep its vdso from > reading a different vcpu's kvmclock data, this is a real corner-case > bug. This patch allows the vdso to retry when this happens. I don't > think it's a great solution, but it should mostly work. Great explanation, thank you. Reverting the patch protects us from any migration, but I don't think we need to care about changing VCPUs as long as we read a consistent data from kvmclock. (VCPU can change outside of this loop too, so it doesn't matter if we return a value not fit for this VCPU.) I think we could drop the second __getcpu if our kvmclock was being handled better; maybe with a patch like the one below: diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index cc2c759f69a3..8658599e0024 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -1658,12 +1658,24 @@ static int kvm_guest_time_update(struct kvm_vcpu *v) &guest_hv_clock, sizeof(guest_hv_clock return 0; - /* -* The interface expects us to write an even number signaling that the -* update is finished. Since the guest won't see the intermediate -* state, we just increase by 2 at the end. + /* A guest can read other VCPU's kvmclock; specification says that +* version is odd if data is being modified and even after it is +* consistent. +* We write three times to be sure. +* 1) update version to odd number +* 2) write modified data (version is still odd) +* 3) update version to even number +* +* TODO: optimize +* - only two writes should be enough -- version is first +* - the second write could update just version */ - vcpu->hv_clock.version = guest_hv_clock.version + 2; + guest_hv_clock.version += 1; + kvm_write_guest_cached(v->kvm, &vcpu->pv_time, + &guest_hv_clock, + sizeof(guest_hv_clock)); + + vcpu->hv_clock.version = guest_hv_clock.version; /* retain PVCLOCK_GUEST_STOPPED if set in guest copy */ pvclock_flags = (guest_hv_clock.flags & PVCLOCK_GUEST_STOPPED); @@ -1684,6 +1696,11 @@ static int kvm_guest_time_update(struct kvm_vcpu *v) kvm_write_guest_cached(v->kvm, &vcpu->pv_time, &vcpu->hv_clock, sizeof(vcpu->hv_clock)); + + vcpu->hv_clock.version += 1; + kvm_write_guest_cached(v->kvm, &vcpu->pv_time, + &vcpu->hv_clock, + sizeof(vcpu->hv_clock)); return 0; } -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM: KVM/XEN: how should we support virt-what?
On 25/03/2015 10:44, Andrew Jones wrote: > 2) create a specific DT node that will get exposed through sysfs, or >somewhere. Looking at custom DT nodes is what PowerPC does. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 8/9] mips/kvm: Support FPU in MIPS KVM guests
Support the new KVM_CAP_MIPS_FPU capability, which allows the host's FPU
to be exposed to the KVM guest.
The capability is enabled if the guest core has an FPU according to its
Config1 register. Various config bits are now writeable so that KVM is
aware of the configuration (Config1.FP) and so that QEMU can
save/restore the guest modifiable bits (Config5.FRE, Config5.UFR,
Config5.UFE). The FCSR/FIR registers and the floating point registers
are now saved/restored (depending on the FR mode bit).
Signed-off-by: James Hogan
Cc: Paolo Bonzini
Cc: Leon Alrae
Cc: Aurelien Jarno
---
Changes in v2:
- Change (1 << x) to (1U << x) in important places to avoid compiler
defined behaviour (Leon).
- Removed update of linux-headers/linux/kvm.h, see patch 1 (Paolo).
---
target-mips/cpu.h | 2 +
target-mips/kvm.c | 124 --
2 files changed, 122 insertions(+), 4 deletions(-)
diff --git a/target-mips/cpu.h b/target-mips/cpu.h
index f9d2b4c5af80..68c8260da0e6 100644
--- a/target-mips/cpu.h
+++ b/target-mips/cpu.h
@@ -462,6 +462,8 @@ struct CPUMIPSState {
#define CP0C5_CV 29
#define CP0C5_EVA28
#define CP0C5_MSAEn 27
+#define CP0C5_UFE9
+#define CP0C5_FRE8
#define CP0C5_SBRI 6
#define CP0C5_UFR2
#define CP0C5_NFExists 0
diff --git a/target-mips/kvm.c b/target-mips/kvm.c
index e8a8858f0cfb..4920244c161a 100644
--- a/target-mips/kvm.c
+++ b/target-mips/kvm.c
@@ -29,6 +29,8 @@
#define DPRINTF(fmt, ...) \
do { if (DEBUG_KVM) { fprintf(stderr, fmt, ## __VA_ARGS__); } } while (0)
+static int kvm_mips_fpu_cap;
+
const KVMCapabilityInfo kvm_arch_required_capabilities[] = {
KVM_CAP_LAST_INFO
};
@@ -45,16 +47,29 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
/* MIPS has 128 signals */
kvm_set_sigmask_len(s, 16);
+kvm_mips_fpu_cap = kvm_check_extension(s, KVM_CAP_MIPS_FPU);
+
DPRINTF("%s\n", __func__);
return 0;
}
int kvm_arch_init_vcpu(CPUState *cs)
{
+MIPSCPU *cpu = MIPS_CPU(cs);
+CPUMIPSState *env = &cpu->env;
int ret = 0;
qemu_add_vm_change_state_handler(kvm_mips_update_state, cs);
+if (kvm_mips_fpu_cap && env->CP0_Config1 & (1 << CP0C1_FP)) {
+ret = kvm_vcpu_enable_cap(cs, KVM_CAP_MIPS_FPU, 0, 0);
+if (ret < 0) {
+/* mark unsupported so it gets disabled on reset */
+kvm_mips_fpu_cap = 0;
+ret = 0;
+}
+}
+
DPRINTF("%s\n", __func__);
return ret;
}
@@ -63,8 +78,8 @@ void kvm_mips_reset_vcpu(MIPSCPU *cpu)
{
CPUMIPSState *env = &cpu->env;
-if (env->CP0_Config1 & (1 << CP0C1_FP)) {
-fprintf(stderr, "Warning: FPU not supported with KVM, disabling\n");
+if (!kvm_mips_fpu_cap && env->CP0_Config1 & (1 << CP0C1_FP)) {
+fprintf(stderr, "Warning: KVM does not support FPU, disabling\n");
env->CP0_Config1 &= ~(1 << CP0C1_FP);
}
@@ -363,11 +378,14 @@ static inline int kvm_mips_get_one_ureg64(CPUState *cs,
uint64 reg_id,
}
#define KVM_REG_MIPS_CP0_CONFIG_MASK(1U << CP0C0_M)
-#define KVM_REG_MIPS_CP0_CONFIG1_MASK (1U << CP0C1_M)
+#define KVM_REG_MIPS_CP0_CONFIG1_MASK ((1U << CP0C1_M) | \
+ (1U << CP0C1_FP))
#define KVM_REG_MIPS_CP0_CONFIG2_MASK (1U << CP0C2_M)
#define KVM_REG_MIPS_CP0_CONFIG3_MASK (1U << CP0C3_M)
#define KVM_REG_MIPS_CP0_CONFIG4_MASK (1U << CP0C4_M)
-#define KVM_REG_MIPS_CP0_CONFIG5_MASK 0
+#define KVM_REG_MIPS_CP0_CONFIG5_MASK ((1U << CP0C5_UFE) | \
+ (1U << CP0C5_FRE) | \
+ (1U << CP0C5_UFR))
static inline int kvm_mips_change_one_reg(CPUState *cs, uint64_t reg_id,
int32_t *addr, int32_t mask)
@@ -529,6 +547,98 @@ static void kvm_mips_update_state(void *opaque, int
running, RunState state)
}
}
+static int kvm_mips_put_fpu_registers(CPUState *cs, int level)
+{
+MIPSCPU *cpu = MIPS_CPU(cs);
+CPUMIPSState *env = &cpu->env;
+int err, ret = 0;
+unsigned int i;
+
+/* Only put FPU state if we're emulating a CPU with an FPU */
+if (env->CP0_Config1 & (1 << CP0C1_FP)) {
+/* FPU Control Registers */
+if (level == KVM_PUT_FULL_STATE) {
+err = kvm_mips_put_one_ureg(cs, KVM_REG_MIPS_FCR_IR,
+&env->active_fpu.fcr0);
+if (err < 0) {
+DPRINTF("%s: Failed to put FCR_IR (%d)\n", __func__, err);
+ret = err;
+}
+}
+err = kvm_mips_put_one_ureg(cs, KVM_REG_MIPS_FCR_CSR,
+&env->active_fpu.fcr31);
+if (err < 0) {
+DPRINTF("%s: Failed to put FCR_CSR (%d)\n", __func__, err);
+ret = err;
+}
+
+/* Floating point registers */
+for (i = 0; i < 32; ++i) {
+if (env->CP0_Status & (1 << CP0
[PATCH v2 6/9] mips/kvm: Support unsigned KVM registers
Add KVM register access functions for the uint32_t type. This is
required for FP and MSA control registers, which are represented as
unsigned 32-bit integers.
Signed-off-by: James Hogan
Cc: Paolo Bonzini
Cc: Leon Alrae
Cc: Aurelien Jarno
---
target-mips/kvm.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/target-mips/kvm.c b/target-mips/kvm.c
index ead8c5f73930..4e5c8ba3d10c 100644
--- a/target-mips/kvm.c
+++ b/target-mips/kvm.c
@@ -243,6 +243,18 @@ static inline int kvm_mips_put_one_reg(CPUState *cs,
uint64_t reg_id,
return kvm_vcpu_ioctl(cs, KVM_SET_ONE_REG, &cp0reg);
}
+static inline int kvm_mips_put_one_ureg(CPUState *cs, uint64_t reg_id,
+uint32_t *addr)
+{
+uint64_t val64 = *addr;
+struct kvm_one_reg cp0reg = {
+.id = reg_id,
+.addr = (uintptr_t)&val64
+};
+
+return kvm_vcpu_ioctl(cs, KVM_SET_ONE_REG, &cp0reg);
+}
+
static inline int kvm_mips_put_one_ulreg(CPUState *cs, uint64_t reg_id,
target_ulong *addr)
{
@@ -283,6 +295,23 @@ static inline int kvm_mips_get_one_reg(CPUState *cs,
uint64_t reg_id,
return ret;
}
+static inline int kvm_mips_get_one_ureg(CPUState *cs, uint64_t reg_id,
+uint32_t *addr)
+{
+int ret;
+uint64_t val64 = 0;
+struct kvm_one_reg cp0reg = {
+.id = reg_id,
+.addr = (uintptr_t)&val64
+};
+
+ret = kvm_vcpu_ioctl(cs, KVM_GET_ONE_REG, &cp0reg);
+if (ret >= 0) {
+*addr = val64;
+}
+return ret;
+}
+
static inline int kvm_mips_get_one_ulreg(CPUState *cs, uint64 reg_id,
target_ulong *addr)
{
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/9] DONT APPLY: linux-headers: Update MIPS KVM headers
This patch updates the linux headers based solely on the changes in my
"MIPS: KVM: Guest FPU & SIMD (MSA) support" KVM patchset. It is provided
for reference since those changes haven't been merged yet. The stored
headers will need to be synced after my KVM patches are merged and
before the rest of this patchset is applied.
The individual KVM patches that make up this change are:
- "[PATCH 07/20] MIPS: KVM: Clean up register definitions a little"
https://patchwork.kernel.org/patch/5986171/
- "[PATCH 14/20] MIPS: KVM: Expose FPU registers"
https://patchwork.kernel.org/patch/5986211/
- "[PATCH 15/20] MIPS: KVM: Wire up FPU capability"
https://patchwork.kernel.org/patch/5986201/
- "[PATCH 19/20] MIPS: KVM: Expose MSA registers"
https://patchwork.kernel.org/patch/5986191/
- "[PATCH 20/20] MIPS: KVM: Wire up MSA capability"
https://patchwork.kernel.org/patch/5986151/
Signed-off-by: James Hogan
Cc: Paolo Bonzini
Cc: Leon Alrae
Cc: Aurelien Jarno
---
Changes in v2:
- Removed most of patch 7 and updates to linux-headers/linux/kvm.h from
patches 8 and 9, and put in this patch for reference (Paolo).
---
linux-headers/asm-mips/kvm.h | 160 ++-
linux-headers/linux/kvm.h| 2 +
2 files changed, 101 insertions(+), 61 deletions(-)
diff --git a/linux-headers/asm-mips/kvm.h b/linux-headers/asm-mips/kvm.h
index 2c04b6d9ff85..6985eb59b085 100644
--- a/linux-headers/asm-mips/kvm.h
+++ b/linux-headers/asm-mips/kvm.h
@@ -36,77 +36,85 @@ struct kvm_regs {
/*
* for KVM_GET_FPU and KVM_SET_FPU
- *
- * If Status[FR] is zero (32-bit FPU), the upper 32-bits of the FPRs
- * are zero filled.
*/
struct kvm_fpu {
- __u64 fpr[32];
- __u32 fir;
- __u32 fccr;
- __u32 fexr;
- __u32 fenr;
- __u32 fcsr;
- __u32 pad;
};
/*
- * For MIPS, we use KVM_SET_ONE_REG and KVM_GET_ONE_REG to access CP0
+ * For MIPS, we use KVM_SET_ONE_REG and KVM_GET_ONE_REG to access various
* registers. The id field is broken down as follows:
*
- * bits[2..0] - Register 'sel' index.
- * bits[7..3] - Register 'rd' index.
- * bits[15..8] - Must be zero.
- * bits[31..16] - 1 -> CP0 registers.
- * bits[51..32] - Must be zero.
* bits[63..52] - As per linux/kvm.h
+ * bits[51..32] - Must be zero.
+ * bits[31..16] - Register set.
+ *
+ * Register set = 0: GP registers from kvm_regs (see definitions below).
+ *
+ * Register set = 1: CP0 registers.
+ * bits[15..8] - Must be zero.
+ * bits[7..3] - Register 'rd' index.
+ * bits[2..0] - Register 'sel' index.
+ *
+ * Register set = 2: KVM specific registers (see definitions below).
+ *
+ * Register set = 3: FPU / MSA registers (see definitions below).
*
* Other sets registers may be added in the future. Each set would
* have its own identifier in bits[31..16].
- *
- * The registers defined in struct kvm_regs are also accessible, the
- * id values for these are below.
*/
-#define KVM_REG_MIPS_R0 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 0)
-#define KVM_REG_MIPS_R1 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 1)
-#define KVM_REG_MIPS_R2 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 2)
-#define KVM_REG_MIPS_R3 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 3)
-#define KVM_REG_MIPS_R4 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 4)
-#define KVM_REG_MIPS_R5 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 5)
-#define KVM_REG_MIPS_R6 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 6)
-#define KVM_REG_MIPS_R7 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 7)
-#define KVM_REG_MIPS_R8 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 8)
-#define KVM_REG_MIPS_R9 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 9)
-#define KVM_REG_MIPS_R10 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 10)
-#define KVM_REG_MIPS_R11 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 11)
-#define KVM_REG_MIPS_R12 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 12)
-#define KVM_REG_MIPS_R13 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 13)
-#define KVM_REG_MIPS_R14 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 14)
-#define KVM_REG_MIPS_R15 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 15)
-#define KVM_REG_MIPS_R16 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 16)
-#define KVM_REG_MIPS_R17 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 17)
-#define KVM_REG_MIPS_R18 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 18)
-#define KVM_REG_MIPS_R19 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 19)
-#define KVM_REG_MIPS_R20 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 20)
-#define KVM_REG_MIPS_R21 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 21)
-#define KVM_REG_MIPS_R22 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 22)
-#define KVM_REG_MIPS_R23 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 23)
-#define KVM_REG_MIPS_R24 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 24)
-#define KVM_REG_MIPS_R25 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 25)
-#define KVM_REG_MIPS_R26 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 26)
-#define KVM_REG_MIPS_R27 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 27)
-#define KVM_REG_MIPS_R28 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 28)
-#define KVM_REG_MIPS_R29 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 29)
-#define KVM_REG_MIPS_R30 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 30)
-#define KVM_REG_MIPS_R31 (KVM_REG_MIPS | KVM_RE
[PATCH v2 9/9] mips/kvm: Support MSA in MIPS KVM guests
Support the new KVM_CAP_MIPS_MSA capability, which allows MIPS SIMD
Architecture (MSA) to be exposed to the KVM guest.
The capability is enabled if the guest core has MSA according to its
Config3 register. Various config bits are now writeable so that KVM is
aware of the configuration (Config3.MSAP) and so that QEMU can
save/restore the guest modifiable bits (Config5.MSAEn). The MSACSR/MSAIR
registers and the MSA vector registers are now saved/restored. Since the
FP registers are a subset of the vector registers, they are omitted if
the guest has MSA.
Signed-off-by: James Hogan
Cc: Paolo Bonzini
Cc: Leon Alrae
Cc: Aurelien Jarno
---
Changes in v2:
- Change (1 << x) to (1U << x) in important places to avoid compiler
defined behaviour (Leon).
- Removed update of linux-headers/linux/kvm.h, see patch 1 (Paolo).
---
target-mips/kvm.c | 127 +-
1 file changed, 107 insertions(+), 20 deletions(-)
diff --git a/target-mips/kvm.c b/target-mips/kvm.c
index 4920244c161a..b9e7a97afca0 100644
--- a/target-mips/kvm.c
+++ b/target-mips/kvm.c
@@ -30,6 +30,7 @@
do { if (DEBUG_KVM) { fprintf(stderr, fmt, ## __VA_ARGS__); } } while (0)
static int kvm_mips_fpu_cap;
+static int kvm_mips_msa_cap;
const KVMCapabilityInfo kvm_arch_required_capabilities[] = {
KVM_CAP_LAST_INFO
@@ -48,6 +49,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
kvm_set_sigmask_len(s, 16);
kvm_mips_fpu_cap = kvm_check_extension(s, KVM_CAP_MIPS_FPU);
+kvm_mips_msa_cap = kvm_check_extension(s, KVM_CAP_MIPS_MSA);
DPRINTF("%s\n", __func__);
return 0;
@@ -70,6 +72,15 @@ int kvm_arch_init_vcpu(CPUState *cs)
}
}
+if (kvm_mips_msa_cap && env->CP0_Config3 & (1 << CP0C3_MSAP)) {
+ret = kvm_vcpu_enable_cap(cs, KVM_CAP_MIPS_MSA, 0, 0);
+if (ret < 0) {
+/* mark unsupported so it gets disabled on reset */
+kvm_mips_msa_cap = 0;
+ret = 0;
+}
+}
+
DPRINTF("%s\n", __func__);
return ret;
}
@@ -82,6 +93,10 @@ void kvm_mips_reset_vcpu(MIPSCPU *cpu)
fprintf(stderr, "Warning: KVM does not support FPU, disabling\n");
env->CP0_Config1 &= ~(1 << CP0C1_FP);
}
+if (!kvm_mips_msa_cap && env->CP0_Config3 & (1 << CP0C3_MSAP)) {
+fprintf(stderr, "Warning: KVM does not support MSA, disabling\n");
+env->CP0_Config3 &= ~(1 << CP0C3_MSAP);
+}
DPRINTF("%s\n", __func__);
}
@@ -381,9 +396,11 @@ static inline int kvm_mips_get_one_ureg64(CPUState *cs,
uint64 reg_id,
#define KVM_REG_MIPS_CP0_CONFIG1_MASK ((1U << CP0C1_M) | \
(1U << CP0C1_FP))
#define KVM_REG_MIPS_CP0_CONFIG2_MASK (1U << CP0C2_M)
-#define KVM_REG_MIPS_CP0_CONFIG3_MASK (1U << CP0C3_M)
+#define KVM_REG_MIPS_CP0_CONFIG3_MASK ((1U << CP0C3_M) | \
+ (1U << CP0C3_MSAP))
#define KVM_REG_MIPS_CP0_CONFIG4_MASK (1U << CP0C4_M)
-#define KVM_REG_MIPS_CP0_CONFIG5_MASK ((1U << CP0C5_UFE) | \
+#define KVM_REG_MIPS_CP0_CONFIG5_MASK ((1U << CP0C5_MSAEn) | \
+ (1U << CP0C5_UFE) | \
(1U << CP0C5_FRE) | \
(1U << CP0C5_UFR))
@@ -572,17 +589,53 @@ static int kvm_mips_put_fpu_registers(CPUState *cs, int
level)
ret = err;
}
-/* Floating point registers */
+/*
+ * FPU register state is a subset of MSA vector state, so don't put FPU
+ * registers if we're emulating a CPU with MSA.
+ */
+if (!(env->CP0_Config3 & (1 << CP0C3_MSAP))) {
+/* Floating point registers */
+for (i = 0; i < 32; ++i) {
+if (env->CP0_Status & (1 << CP0St_FR)) {
+err = kvm_mips_put_one_ureg64(cs, KVM_REG_MIPS_FPR_64(i),
+ &env->active_fpu.fpr[i].d);
+} else {
+err = kvm_mips_get_one_ureg(cs, KVM_REG_MIPS_FPR_32(i),
+&env->active_fpu.fpr[i].w[FP_ENDIAN_IDX]);
+}
+if (err < 0) {
+DPRINTF("%s: Failed to put FPR%u (%d)\n", __func__, i,
err);
+ret = err;
+}
+}
+}
+}
+
+/* Only put MSA state if we're emulating a CPU with MSA */
+if (env->CP0_Config3 & (1 << CP0C3_MSAP)) {
+/* MSA Control Registers */
+if (level == KVM_PUT_FULL_STATE) {
+err = kvm_mips_put_one_reg(cs, KVM_REG_MIPS_MSA_IR,
+ &env->msair);
+if (err < 0) {
+DPRINTF("%s: Failed to put MSA_IR (%d)\n", __func__, err);
+ret = err;
+}
+}
+err = kvm_mips_put_one_reg(cs, KVM_REG_MIPS_MSA_CSR,
+ &env->active_tc.msacsr);
+
[PATCH v2 2/9] mips/kvm: Sync with newer MIPS KVM headers
The KVM_REG_MIPS_COUNT_* definitions are now included in
linux-headers/asm-mips/kvm.h since commit b061808d39fa ("linux-headers:
update linux headers to kvm/next"), therefore the duplicate definitions
in target-mips/kvm.c can now be dropped.
The MIPS_C0_{32,64} macros are also updated to utilise definitions more
recently added to the asm-mips/kvm.h header.
Signed-off-by: James Hogan
Cc: Paolo Bonzini
Cc: Leon Alrae
Cc: Aurelien Jarno
---
Changes in v2:
- Add the changes to MIPS_CP0_{32,64} macros from v1 patch 7, since the
rest of that patch is now unnecessary and the change is along the same
lines as this patch.
- (not added Leon's Reviewed-by due to above non-reviewed change).
---
target-mips/kvm.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/target-mips/kvm.c b/target-mips/kvm.c
index 4d1f7ead8142..bbdaccc9d729 100644
--- a/target-mips/kvm.c
+++ b/target-mips/kvm.c
@@ -206,10 +206,10 @@ int kvm_mips_set_ipi_interrupt(MIPSCPU *cpu, int irq, int
level)
}
#define MIPS_CP0_32(_R, _S) \
-(KVM_REG_MIPS | KVM_REG_SIZE_U32 | 0x1 | (8 * (_R) + (_S)))
+(KVM_REG_MIPS_CP0 | KVM_REG_SIZE_U32 | (8 * (_R) + (_S)))
#define MIPS_CP0_64(_R, _S) \
-(KVM_REG_MIPS | KVM_REG_SIZE_U64 | 0x1 | (8 * (_R) + (_S)))
+(KVM_REG_MIPS_CP0 | KVM_REG_SIZE_U64 | (8 * (_R) + (_S)))
#define KVM_REG_MIPS_CP0_INDEX MIPS_CP0_32(0, 0)
#define KVM_REG_MIPS_CP0_CONTEXTMIPS_CP0_64(4, 0)
@@ -226,17 +226,6 @@ int kvm_mips_set_ipi_interrupt(MIPSCPU *cpu, int irq, int
level)
#define KVM_REG_MIPS_CP0_EPCMIPS_CP0_64(14, 0)
#define KVM_REG_MIPS_CP0_ERROREPC MIPS_CP0_64(30, 0)
-/* CP0_Count control */
-#define KVM_REG_MIPS_COUNT_CTL (KVM_REG_MIPS | KVM_REG_SIZE_U64 | \
- 0x2 | 0)
-#define KVM_REG_MIPS_COUNT_CTL_DC 0x0001 /* master disable */
-/* CP0_Count resume monotonic nanoseconds */
-#define KVM_REG_MIPS_COUNT_RESUME (KVM_REG_MIPS | KVM_REG_SIZE_U64 | \
- 0x2 | 1)
-/* CP0_Count rate in Hz */
-#define KVM_REG_MIPS_COUNT_HZ (KVM_REG_MIPS | KVM_REG_SIZE_U64 | \
- 0x2 | 2)
-
static inline int kvm_mips_put_one_reg(CPUState *cs, uint64_t reg_id,
int32_t *addr)
{
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/9] mips/kvm: Implement Config CP0 registers
Implement saving and restoring to KVM state of the Config CP0 registers
(namely Config, Config1, Config2, Config3, Config4, and Config5). These
control the features available to a guest, and a few of the fields will
soon be writeable by a guest so QEMU needs to know about them so as not
to clobber them on migration/savevm.
Signed-off-by: James Hogan
Cc: Paolo Bonzini
Cc: Leon Alrae
Cc: Aurelien Jarno
---
Changes in v2:
- Fix line wrapping of kvm_mips_get_one_reg() calls from Config4 and
Config5 (Leon).
- Change (1 << x) to (1U << x) in important places to avoid compiler
defined behaviour (Leon).
---
target-mips/kvm.c | 106 ++
1 file changed, 106 insertions(+)
diff --git a/target-mips/kvm.c b/target-mips/kvm.c
index d41facfca0d5..ead8c5f73930 100644
--- a/target-mips/kvm.c
+++ b/target-mips/kvm.c
@@ -223,6 +223,12 @@ int kvm_mips_set_ipi_interrupt(MIPSCPU *cpu, int irq, int
level)
#define KVM_REG_MIPS_CP0_CAUSE MIPS_CP0_32(13, 0)
#define KVM_REG_MIPS_CP0_EPCMIPS_CP0_64(14, 0)
#define KVM_REG_MIPS_CP0_PRID MIPS_CP0_32(15, 0)
+#define KVM_REG_MIPS_CP0_CONFIG MIPS_CP0_32(16, 0)
+#define KVM_REG_MIPS_CP0_CONFIG1MIPS_CP0_32(16, 1)
+#define KVM_REG_MIPS_CP0_CONFIG2MIPS_CP0_32(16, 2)
+#define KVM_REG_MIPS_CP0_CONFIG3MIPS_CP0_32(16, 3)
+#define KVM_REG_MIPS_CP0_CONFIG4MIPS_CP0_32(16, 4)
+#define KVM_REG_MIPS_CP0_CONFIG5MIPS_CP0_32(16, 5)
#define KVM_REG_MIPS_CP0_ERROREPC MIPS_CP0_64(30, 0)
static inline int kvm_mips_put_one_reg(CPUState *cs, uint64_t reg_id,
@@ -305,6 +311,34 @@ static inline int kvm_mips_get_one_reg64(CPUState *cs,
uint64 reg_id,
return kvm_vcpu_ioctl(cs, KVM_GET_ONE_REG, &cp0reg);
}
+#define KVM_REG_MIPS_CP0_CONFIG_MASK(1U << CP0C0_M)
+#define KVM_REG_MIPS_CP0_CONFIG1_MASK (1U << CP0C1_M)
+#define KVM_REG_MIPS_CP0_CONFIG2_MASK (1U << CP0C2_M)
+#define KVM_REG_MIPS_CP0_CONFIG3_MASK (1U << CP0C3_M)
+#define KVM_REG_MIPS_CP0_CONFIG4_MASK (1U << CP0C4_M)
+#define KVM_REG_MIPS_CP0_CONFIG5_MASK 0
+
+static inline int kvm_mips_change_one_reg(CPUState *cs, uint64_t reg_id,
+ int32_t *addr, int32_t mask)
+{
+int err;
+int32_t tmp, change;
+
+err = kvm_mips_get_one_reg(cs, reg_id, &tmp);
+if (err < 0) {
+return err;
+}
+
+/* only change bits in mask */
+change = (*addr ^ tmp) & mask;
+if (!change) {
+return 0;
+}
+
+tmp = tmp ^ change;
+return kvm_mips_put_one_reg(cs, reg_id, &tmp);
+}
+
/*
* We freeze the KVM timer when either the VM clock is stopped or the state is
* saved (the state is dirty).
@@ -527,6 +561,48 @@ static int kvm_mips_put_cp0_registers(CPUState *cs, int
level)
DPRINTF("%s: Failed to put CP0_PRID (%d)\n", __func__, err);
ret = err;
}
+err = kvm_mips_change_one_reg(cs, KVM_REG_MIPS_CP0_CONFIG,
+ &env->CP0_Config0,
+ KVM_REG_MIPS_CP0_CONFIG_MASK);
+if (err < 0) {
+DPRINTF("%s: Failed to change CP0_CONFIG (%d)\n", __func__, err);
+ret = err;
+}
+err = kvm_mips_change_one_reg(cs, KVM_REG_MIPS_CP0_CONFIG1,
+ &env->CP0_Config1,
+ KVM_REG_MIPS_CP0_CONFIG1_MASK);
+if (err < 0) {
+DPRINTF("%s: Failed to change CP0_CONFIG1 (%d)\n", __func__, err);
+ret = err;
+}
+err = kvm_mips_change_one_reg(cs, KVM_REG_MIPS_CP0_CONFIG2,
+ &env->CP0_Config2,
+ KVM_REG_MIPS_CP0_CONFIG2_MASK);
+if (err < 0) {
+DPRINTF("%s: Failed to change CP0_CONFIG2 (%d)\n", __func__, err);
+ret = err;
+}
+err = kvm_mips_change_one_reg(cs, KVM_REG_MIPS_CP0_CONFIG3,
+ &env->CP0_Config3,
+ KVM_REG_MIPS_CP0_CONFIG3_MASK);
+if (err < 0) {
+DPRINTF("%s: Failed to change CP0_CONFIG3 (%d)\n", __func__, err);
+ret = err;
+}
+err = kvm_mips_change_one_reg(cs, KVM_REG_MIPS_CP0_CONFIG4,
+ &env->CP0_Config4,
+ KVM_REG_MIPS_CP0_CONFIG4_MASK);
+if (err < 0) {
+DPRINTF("%s: Failed to change CP0_CONFIG4 (%d)\n", __func__, err);
+ret = err;
+}
+err = kvm_mips_change_one_reg(cs, KVM_REG_MIPS_CP0_CONFIG5,
+ &env->CP0_Config5,
+ KVM_REG_MIPS_CP0_CONFIG5_MASK);
+if (err < 0) {
+DPRINTF("%s: Failed to change CP0_CONFIG5 (%d)\n", __func__, err);
+ret = err;
+}
err = kvm_mips_put_one_ulreg(cs, KVM_REG_MIPS_CP0_ERROREPC,
&env->CP0_ErrorEPC);
if (err < 0) {
@@ -618,6 +694,36 @@ static int kvm_mips_get_cp0_registers(CPUState *cs)
DPRINTF("%s: Faile
[PATCH v2 3/9] mips/kvm: Remove a couple of noisy DPRINTFs
The DPRINTFs in cpu_mips_io_interrupts_pending() and kvm_arch_pre_run()
are particularly noisy during normal execution, and also not
particularly helpful. Remove them so that more important debug messages
can be more easily seen.
Signed-off-by: James Hogan
Reviewed-by: Leon Alrae
Cc: Paolo Bonzini
Cc: Aurelien Jarno
---
target-mips/kvm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/target-mips/kvm.c b/target-mips/kvm.c
index bbdaccc9d729..1722a6a40598 100644
--- a/target-mips/kvm.c
+++ b/target-mips/kvm.c
@@ -87,7 +87,6 @@ static inline int cpu_mips_io_interrupts_pending(MIPSCPU *cpu)
{
CPUMIPSState *env = &cpu->env;
-DPRINTF("%s: %#x\n", __func__, env->CP0_Cause & (1 << (2 + CP0Ca_IP)));
return env->CP0_Cause & (0x1 << (2 + CP0Ca_IP));
}
@@ -112,7 +111,6 @@ void kvm_arch_pre_run(CPUState *cs, struct kvm_run *run)
void kvm_arch_post_run(CPUState *cs, struct kvm_run *run)
{
-DPRINTF("%s\n", __func__);
}
int kvm_arch_process_async_events(CPUState *cs)
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/9] mips/kvm: Implement PRid CP0 register
Implement saving and restoring to KVM state of the Processor ID (PRid)
CP0 register. This allows QEMU to control the PRid exposed to the guest
instead of using the default set by KVM.
Signed-off-by: James Hogan
Reviewed-by: Leon Alrae
Cc: Paolo Bonzini
Cc: Aurelien Jarno
---
target-mips/kvm.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/target-mips/kvm.c b/target-mips/kvm.c
index 1722a6a40598..d41facfca0d5 100644
--- a/target-mips/kvm.c
+++ b/target-mips/kvm.c
@@ -222,6 +222,7 @@ int kvm_mips_set_ipi_interrupt(MIPSCPU *cpu, int irq, int
level)
#define KVM_REG_MIPS_CP0_STATUS MIPS_CP0_32(12, 0)
#define KVM_REG_MIPS_CP0_CAUSE MIPS_CP0_32(13, 0)
#define KVM_REG_MIPS_CP0_EPCMIPS_CP0_64(14, 0)
+#define KVM_REG_MIPS_CP0_PRID MIPS_CP0_32(15, 0)
#define KVM_REG_MIPS_CP0_ERROREPC MIPS_CP0_64(30, 0)
static inline int kvm_mips_put_one_reg(CPUState *cs, uint64_t reg_id,
@@ -521,6 +522,11 @@ static int kvm_mips_put_cp0_registers(CPUState *cs, int
level)
DPRINTF("%s: Failed to put CP0_EPC (%d)\n", __func__, err);
ret = err;
}
+err = kvm_mips_put_one_reg(cs, KVM_REG_MIPS_CP0_PRID, &env->CP0_PRid);
+if (err < 0) {
+DPRINTF("%s: Failed to put CP0_PRID (%d)\n", __func__, err);
+ret = err;
+}
err = kvm_mips_put_one_ulreg(cs, KVM_REG_MIPS_CP0_ERROREPC,
&env->CP0_ErrorEPC);
if (err < 0) {
@@ -607,6 +613,11 @@ static int kvm_mips_get_cp0_registers(CPUState *cs)
DPRINTF("%s: Failed to get CP0_EPC (%d)\n", __func__, err);
ret = err;
}
+err = kvm_mips_get_one_reg(cs, KVM_REG_MIPS_CP0_PRID, &env->CP0_PRid);
+if (err < 0) {
+DPRINTF("%s: Failed to get CP0_PRID (%d)\n", __func__, err);
+ret = err;
+}
err = kvm_mips_get_one_ulreg(cs, KVM_REG_MIPS_CP0_ERROREPC,
&env->CP0_ErrorEPC);
if (err < 0) {
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 7/9] mips/kvm: Support signed 64-bit KVM registers
Rename kvm_mips_{get,put}_one_reg64() to kvm_mips_{get,put}_one_ureg64()
since they take an int64_t pointer, and add separate signed 64-bit
accessors. These will be used for double precision floating point
registers.
Signed-off-by: James Hogan
Cc: Paolo Bonzini
Cc: Leon Alrae
Cc: Aurelien Jarno
---
target-mips/kvm.c | 40 +++-
1 file changed, 31 insertions(+), 9 deletions(-)
diff --git a/target-mips/kvm.c b/target-mips/kvm.c
index 4e5c8ba3d10c..e8a8858f0cfb 100644
--- a/target-mips/kvm.c
+++ b/target-mips/kvm.c
@@ -268,7 +268,18 @@ static inline int kvm_mips_put_one_ulreg(CPUState *cs,
uint64_t reg_id,
}
static inline int kvm_mips_put_one_reg64(CPUState *cs, uint64_t reg_id,
- uint64_t *addr)
+ int64_t *addr)
+{
+struct kvm_one_reg cp0reg = {
+.id = reg_id,
+.addr = (uintptr_t)addr
+};
+
+return kvm_vcpu_ioctl(cs, KVM_SET_ONE_REG, &cp0reg);
+}
+
+static inline int kvm_mips_put_one_ureg64(CPUState *cs, uint64_t reg_id,
+ uint64_t *addr)
{
struct kvm_one_reg cp0reg = {
.id = reg_id,
@@ -330,7 +341,18 @@ static inline int kvm_mips_get_one_ulreg(CPUState *cs,
uint64 reg_id,
}
static inline int kvm_mips_get_one_reg64(CPUState *cs, uint64 reg_id,
- uint64_t *addr)
+ int64_t *addr)
+{
+struct kvm_one_reg cp0reg = {
+.id = reg_id,
+.addr = (uintptr_t)addr
+};
+
+return kvm_vcpu_ioctl(cs, KVM_GET_ONE_REG, &cp0reg);
+}
+
+static inline int kvm_mips_get_one_ureg64(CPUState *cs, uint64 reg_id,
+ uint64_t *addr)
{
struct kvm_one_reg cp0reg = {
.id = reg_id,
@@ -385,13 +407,13 @@ static int kvm_mips_save_count(CPUState *cs)
int err, ret = 0;
/* freeze KVM timer */
-err = kvm_mips_get_one_reg64(cs, KVM_REG_MIPS_COUNT_CTL, &count_ctl);
+err = kvm_mips_get_one_ureg64(cs, KVM_REG_MIPS_COUNT_CTL, &count_ctl);
if (err < 0) {
DPRINTF("%s: Failed to get COUNT_CTL (%d)\n", __func__, err);
ret = err;
} else if (!(count_ctl & KVM_REG_MIPS_COUNT_CTL_DC)) {
count_ctl |= KVM_REG_MIPS_COUNT_CTL_DC;
-err = kvm_mips_put_one_reg64(cs, KVM_REG_MIPS_COUNT_CTL, &count_ctl);
+err = kvm_mips_put_one_ureg64(cs, KVM_REG_MIPS_COUNT_CTL, &count_ctl);
if (err < 0) {
DPRINTF("%s: Failed to set COUNT_CTL.DC=1 (%d)\n", __func__, err);
ret = err;
@@ -427,14 +449,14 @@ static int kvm_mips_restore_count(CPUState *cs)
int err_dc, err, ret = 0;
/* check the timer is frozen */
-err_dc = kvm_mips_get_one_reg64(cs, KVM_REG_MIPS_COUNT_CTL, &count_ctl);
+err_dc = kvm_mips_get_one_ureg64(cs, KVM_REG_MIPS_COUNT_CTL, &count_ctl);
if (err_dc < 0) {
DPRINTF("%s: Failed to get COUNT_CTL (%d)\n", __func__, err_dc);
ret = err_dc;
} else if (!(count_ctl & KVM_REG_MIPS_COUNT_CTL_DC)) {
/* freeze timer (sets COUNT_RESUME for us) */
count_ctl |= KVM_REG_MIPS_COUNT_CTL_DC;
-err = kvm_mips_put_one_reg64(cs, KVM_REG_MIPS_COUNT_CTL, &count_ctl);
+err = kvm_mips_put_one_ureg64(cs, KVM_REG_MIPS_COUNT_CTL, &count_ctl);
if (err < 0) {
DPRINTF("%s: Failed to set COUNT_CTL.DC=1 (%d)\n", __func__, err);
ret = err;
@@ -458,7 +480,7 @@ static int kvm_mips_restore_count(CPUState *cs)
/* resume KVM timer */
if (err_dc >= 0) {
count_ctl &= ~KVM_REG_MIPS_COUNT_CTL_DC;
-err = kvm_mips_put_one_reg64(cs, KVM_REG_MIPS_COUNT_CTL, &count_ctl);
+err = kvm_mips_put_one_ureg64(cs, KVM_REG_MIPS_COUNT_CTL, &count_ctl);
if (err < 0) {
DPRINTF("%s: Failed to set COUNT_CTL.DC=0 (%d)\n", __func__, err);
ret = err;
@@ -491,8 +513,8 @@ static void kvm_mips_update_state(void *opaque, int
running, RunState state)
} else {
/* Set clock restore time to now */
count_resume = qemu_clock_get_ns(QEMU_CLOCK_REALTIME);
-ret = kvm_mips_put_one_reg64(cs, KVM_REG_MIPS_COUNT_RESUME,
- &count_resume);
+ret = kvm_mips_put_one_ureg64(cs, KVM_REG_MIPS_COUNT_RESUME,
+ &count_resume);
if (ret < 0) {
fprintf(stderr, "Failed setting COUNT_RESUME\n");
return;
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/9] mips/kvm: Support FPU & SIMD (MSA) in MIPS KVM guests
Review on v1 has gone quiet, so here's v2 which addresses the feedback
received for v1. Thanks to all who have taken the time to review it so
far.
This patchset primarily adds support for FPU and MIPS SIMD Architecture
(MSA) in MIPS KVM guests to QEMU. It depends on the KVM patchset which I
recently submitted to add the corresponding hypervisor support to KVM
("[PATCH 00/20] MIPS: KVM: Guest FPU & SIMD (MSA) support").
All comments welcome.
Changes in v2:
- Moved most of patch 7 and updates to linux-headers/linux/kvm.h from
patches 8 and 9 into a new patch 1, which is purely for reference
(Paolo).
- Add the changes to MIPS_CP0_{32,64} macros from v1 patch 7 to patch 2,
since the rest of that patch is now unnecessary and the change is
along the same lines as patch 2 (not added Leon's Reviewed-by to this
patch due to that non-reviewed change).
- Fix line wrapping of kvm_mips_get_one_reg() calls from Config4 and
Config5 in patch 5 (Leon).
- Change (1 << x) to (1U << x) in important places in patch 5, 8 & 9 to
avoid compiler defined behaviour (Leon).
James Hogan (9):
DONT APPLY: linux-headers: Update MIPS KVM headers
mips/kvm: Sync with newer MIPS KVM headers
mips/kvm: Remove a couple of noisy DPRINTFs
mips/kvm: Implement PRid CP0 register
mips/kvm: Implement Config CP0 registers
mips/kvm: Support unsigned KVM registers
mips/kvm: Support signed 64-bit KVM registers
mips/kvm: Support FPU in MIPS KVM guests
mips/kvm: Support MSA in MIPS KVM guests
linux-headers/asm-mips/kvm.h | 160 ++---
linux-headers/linux/kvm.h| 2 +
target-mips/cpu.h| 2 +
target-mips/kvm.c| 410 ---
4 files changed, 487 insertions(+), 87 deletions(-)
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ARM: KVM/XEN: how should we support virt-what?
Hello ARM virt maintainers, I'd like to start a discussion about supporting virt-what[1]. virt-what allows userspace to determine if the system it's running on is running in a guest, and of what type (KVM, Xen, etc.). Despite it being a best effort tool, see the Caveat emptor in [1], it has become quite a useful tool, and is showing up in different places, such as OpenStack. If you look at the code[2], specifically [3], then you'll see how it works on x86, which is to use the dedicated hypervisor cpuid leaves. I'm wondering what equivalent we have, or can develop, for arm. Here are some thoughts; 0) there's already something we can use, and I just need to be told about it. 1) be as similar as possible to x86 by dedicating some currently undefined sysreg bits. This would take buy-in from lots of parties, so is not likely the way to go. 2) create a specific DT node that will get exposed through sysfs, or somewhere. 3) same as (2), but just use the nodes currently in mach-virt's DT as the indication we're a guest. This would just be a heuristic, i.e. "have virtio mmio" && psci.method == hvc, or something, and we'd still need a way to know if we're kvm vs. xen vs. ??. Thanks, drew [1] http://people.redhat.com/~rjones/virt-what/ [2] http://git.annexia.org/?p=virt-what.git;a=summary [3] http://git.annexia.org/?p=virt-what.git;a=blob_plain;f=virt-what-cpuid-helper.c;hb=HEAD -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
