[PATCH] Restore cr3 after tests on PCID
The INVPCID enabling test assumes cr3[11:0] is 0. But at present PCID enabling test sets cr3[11:0] to 1 for its own purpose and doesn't restore the register, which leads to a failure when INVPCID test tries to enable PCIDE. This patch restores cr3 after PCID enabling test is done so that PCIDE can be enabled normally in later tests. Signed-off-by: Junjie Mao junjie@intel.com --- x86/pcid.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/x86/pcid.c b/x86/pcid.c index de0f6fe..8bfeba2 100644 --- a/x86/pcid.c +++ b/x86/pcid.c @@ -79,6 +79,7 @@ void test_pcid_enabled(void) write_cr3(cr3 | 0x001); if (write_cr4_checking(cr4 | X86_CR4_PCIDE) != GP_VECTOR) goto report; +write_cr3(cr3); passed = 1; -- 1.7.1 -- 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] KVM: x86: Check INVPCID feature bit in EBX of leaf 7
Checks and operations on the INVPCID feature bit should use EBX of CPUID leaf 7
instead of ECX.
Signed-off-by: Junjie Mao junjie@intel.com
---
arch/x86/kvm/vmx.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index c00f03d..002b4a5 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -6575,7 +6575,7 @@ static void vmx_cpuid_update(struct kvm_vcpu *vcpu)
/* Exposing INVPCID only when PCID is exposed */
best = kvm_find_cpuid_entry(vcpu, 0x7, 0);
if (vmx_invpcid_supported()
- best (best-ecx bit(X86_FEATURE_INVPCID))
+ best (best-ebx bit(X86_FEATURE_INVPCID))
guest_cpuid_has_pcid(vcpu)) {
exec_control |= SECONDARY_EXEC_ENABLE_INVPCID;
vmcs_write32(SECONDARY_VM_EXEC_CONTROL,
@@ -6585,7 +6585,7 @@ static void vmx_cpuid_update(struct kvm_vcpu *vcpu)
vmcs_write32(SECONDARY_VM_EXEC_CONTROL,
exec_control);
if (best)
- best-ecx = ~bit(X86_FEATURE_INVPCID);
+ best-ebx = ~bit(X86_FEATURE_INVPCID);
}
}
--
1.7.1
--
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
FW: [PATCH kvm-unit-tests RESEND] Restore cr3 after tests on PCID
The INVPCID enabling test assumes cr3[11:0] is 0. But at present PCID enabling test sets cr3[11:0] to 1 for its own purpose and doesn't restore the register, which leads to a failure when INVPCID test tries to enable PCIDE. This patch restores cr3 after PCID enabling test is done so that PCIDE can be enabled normally in later tests. Signed-off-by: Junjie Mao junjie@intel.com --- x86/pcid.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/x86/pcid.c b/x86/pcid.c index de0f6fe..8bfeba2 100644 --- a/x86/pcid.c +++ b/x86/pcid.c @@ -79,6 +79,7 @@ void test_pcid_enabled(void) write_cr3(cr3 | 0x001); if (write_cr4_checking(cr4 | X86_CR4_PCIDE) != GP_VECTOR) goto report; +write_cr3(cr3); passed = 1; -- 1.7.1 -- 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: [RFC 1/5] KVM: Move KVM_SET_ONE_REG/KVM_GET_ONE_REG to generic code.
On 08/28/2012 04:45 PM, Rusty Russell wrote: Avi has indicated that this is the future. For now, make it dependent on KVM_HAVE_ONE_REG (and define that for PPC and S/390). I want GET_MULTI, really. But maybe iterating over ONE_REG isn't so bad since we do it so rarely.: Would all register IDs fit in 64 bits? cpuid (read only) is addressed using eax (32-bits), ecx (for some values of eax), and yields 4 32-bit values. That's 66 bits of addressing, independent of some way to discriminate between register sets. I guess we could special case the cases where ecx is needed, or only allow 8 bits for ecx (always okay so far). Other x86 state: GPRs - ok MSRs - ok FPU - one register per xmm/st(x)? the entire xsave area? APIC - one register per apic register? the entire 4k page? Various non-register state (pending exceptions, run state, blocked-by-sti/ss) - ok SVM/VMX state - ok Segments: one register per segment? one per component? Control registers: ok. Should userspace be careful to set registers in legal ways only? i.e. cannot set cr3[0:11] if cr4.pae=0, or vice versa, so need three writes? IOAPIC/PIC/PIT - not vcpu state Debug registers - ok xcr - ok Yuch, we have a lot of state in that thing. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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: [RFC 5/5] KVM: ARM: Access all registers via KVM_GET_ONE_REG/KVM_SET_ONE_REG.
On 08/29/2012 08:29 AM, Christoffer Dall wrote: On Tue, Aug 28, 2012 at 4:48 PM, Rusty Russell rusty.russ...@linaro.org wrote: No structures at all any more. I fail to see the great benefit of all this. The code is certainly not easier to read and it's certainly not more clear what is going on. Is this simply so we don't have to copy header files into QEMU when QEMU needs to support a new architecture? We have to do that anyway no? Do core registers really often change and often we need new registers for an existing architecture? I can see this for cp15 stuff, but core registers? The nice thing about it is that the hardware vendors can keep adding stuff, and we don't need new ioctls. Just new encodings for register numbers. x86 needed 6-7 updates (some due to our missing some hidden state). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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: [RFC 5/5] KVM: ARM: Access all registers via KVM_GET_ONE_REG/KVM_SET_ONE_REG.
On 08/29/2012 11:21 AM, Rusty Russell wrote: + /* Coprocessor 0 means we want a core register. */ + if ((u32)reg-id KVM_REG_ARM_COPROC_START == 0) + return set_core_reg(vcpu, reg); ...but if we do go this path, you can't use coprocessor 0 to mean core register -- cp0 could be a valid coprocessor (the ARM ARM reserves cp0..cp7 for vendor specific features). Use something outside 0..15. OK, changed that too (16). And tomorrow they will add 16. Have the first byte say where the state belongs (core or coprocessor) second byte refer to the register family (if applicable), the rest identifies the register within that family. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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] [PATCH 4/4] kvm: i386: Add classic PCI device assignment
On Tue, Aug 28, 2012 at 9:51 PM, Anthony Liguori anth...@codemonkey.ws wrote:
Blue Swirl blauwir...@gmail.com writes:
On Tue, Aug 28, 2012 at 7:31 PM, Anthony Liguori anth...@codemonkey.ws
wrote:
Blue Swirl blauwir...@gmail.com writes:
On Tue, Aug 28, 2012 at 5:28 PM, Michael S. Tsirkin m...@redhat.com
wrote:
On Tue, Aug 28, 2012 at 05:01:55PM +, Blue Swirl wrote:
On Tue, Aug 28, 2012 at 7:35 AM, Michael Tokarev m...@tls.msk.ru wrote:
On 27.08.2012 22:56, Blue Swirl wrote:
[]
+static uint32_t slow_bar_readb(void *opaque, target_phys_addr_t
addr)
+{
+AssignedDevRegion *d = opaque;
+uint8_t *in = d-u.r_virtbase + addr;
Don't perform arithmetic with void pointers.
There are a few places in common qemu code which does this for a very
long time. So I guess it is safe now.
It's a non-standard GCC extension.
So? We use many other GCC extensions. grep for typeof.
Dependencies should not be introduced trivially. In this case, it's
pretty easy to avoid void pointer arithmetic as Jan's next version
shows.
The standard is vague with respect void arithmetic. Most compilers
allow it. A very good analysis of the standard can be found below.
http://stackoverflow.com/questions/3523145/pointer-arithmetic-for-void-pointer-in-c
The analysis would seem to show that arithmetic may be acceptable, but
it doesn't say that void pointers must be treated like char pointers.
In my view, this would make sense:
char *cptr;
void *vptr;
Since
cptr++;
is equivalent to
cptr = (char *)((uintptr_t)cptr + sizeof(*cptr));
therefore
vptr++;
should be equivalent to
vptr = (void *)((uintptr_t)vptr + sizeof(*vptr));
That is, vptr++ should be equivalent to vptr += 0 because sizeof(void)
should be 0 if allowed.
sizeof(void) == 1
With GCC at least.
It's not valid C (0 is just how I think it should be if allowed). Also
GCC can reject it even with std=gnu89 (default, C89 with GNU
extensions):
$ cat void.c
unsigned long x = sizeof(void);
$ gcc -pedantic void.c -c
void.c:1: warning: invalid application of 'sizeof' to a void type
Regards,
Anthony Liguori
Regards,
Anthony Liguori
Is there a work in progress to build GCC with visual studio?
If yes what are the chances KVM device assignment
will work on windows?
IIRC there was really a project to use KVM on Windows and another
project to build QEMU with MSVC.
Look QEMU codebase is what it is. Unless you rework all existing
code to confirm to your taste, I do not see why you NACK valid new code
unless it confirms to same.
Yes, I'd be happy to fix the style with huge patches at once. But our
fearless leader does not agree, so we are stuck with the codebase
being what it is until it is fixed one step at a time.
/mjt
--
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
--
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: [RFC 0/5] Making KVM_GET_ONE_REG/KVM_SET_ONE_REG generic.
On 08/29/2012 11:39 AM, Rusty Russell wrote:
-4.76 KVM_VCPU_GET_MSR_INDEX_LIST
+4.76 KVM_VCPU_GET_REG_LIST
-Capability: basic
+Capability: KVM_CAP_REG_LIST
Architectures: arm
all
Type: vcpu ioctl
-Parameters: struct kvm_msr_list (in/out)
+Parameters: struct kvm_reg_list (in/out)
Returns: 0 on success; -1 on error
Errors:
- E2BIG: the msr index list is too big to fit in the array specified by
- the user.
+ E2BIG: the reg index list is too big to fit in the array specified by
+ the user (the number required will be written into n).
struct kvm_msr_list {
- __u32 nmsrs; /* number of msrs in entries */
- __u32 indices[0];
+ __u64 n; /* number of registers in reg[] */
+ __u64 reg[0];
};
People complain that this interface is hard to use.
How about supplying the address of the array (in addition to n) so you
don't have to deal with variable sized arrays, and dropping E2BIG in
favour of always updating n (n changed to something bigger than you had
- reallocate and rerun)
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
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: [RFC 1/5] KVM: Move KVM_SET_ONE_REG/KVM_GET_ONE_REG to generic code.
On 1 September 2012 10:11, Avi Kivity a...@redhat.com wrote: Other x86 state: Control registers: ok. Should userspace be careful to set registers in legal ways only? i.e. cannot set cr3[0:11] if cr4.pae=0, or vice versa, so need three writes? The principle I'm hoping we can hold to for ARM is that the kernel only exposes state in such a way that it's always possible for userspace to migrate it with a simple read everything, send to destination, write everything, ie without needing to know anything of the semantics of any of these registers. This means that registers which have access controls (eg can't write this unless you wrote to that other one first) should not enforce those checks for userspace get/set. More significantly, it means that registers with odd behaviour, like write 1 to clear or register A selects which of an array of underlying registers is exposed in register B are not directly exposed at all. Instead the kernel provides some other (ersatz) register indexes which let userspace do plain get/set on the underlying state. The idea is that then migration depends only on whether the destination kernel supports all the registers the source kernel does, and we avoid extra dependencies on the source and destination qemu. (Most of the state being transferred is of no interest to userspace at all.) [It also makes write-multiple easier to use.] -- PMM -- 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: [RFC 5/5] KVM: ARM: Access all registers via KVM_GET_ONE_REG/KVM_SET_ONE_REG.
On 1 September 2012 10:16, Avi Kivity a...@redhat.com wrote: On 08/29/2012 11:21 AM, Rusty Russell wrote: + /* Coprocessor 0 means we want a core register. */ + if ((u32)reg-id KVM_REG_ARM_COPROC_START == 0) + return set_core_reg(vcpu, reg); ...but if we do go this path, you can't use coprocessor 0 to mean core register -- cp0 could be a valid coprocessor (the ARM ARM reserves cp0..cp7 for vendor specific features). Use something outside 0..15. OK, changed that too (16). And tomorrow they will add 16. Not possible in the instruction encoding :-) We haven't used anywhere near all the coprocessors (even given we've let the vendors have 0..7, ARM itself uses only 10 and 11 for the FPU, 14 for debug/perf and 15 for system control (and 14 and 15 still have lots of spare space). -- PMM -- 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: [RFC 1/5] KVM: Move KVM_SET_ONE_REG/KVM_GET_ONE_REG to generic code.
On 09/01/2012 03:18 AM, Peter Maydell wrote: On 1 September 2012 10:11, Avi Kivity a...@redhat.com wrote: Other x86 state: Control registers: ok. Should userspace be careful to set registers in legal ways only? i.e. cannot set cr3[0:11] if cr4.pae=0, or vice versa, so need three writes? The principle I'm hoping we can hold to for ARM is that the kernel only exposes state in such a way that it's always possible for userspace to migrate it with a simple read everything, send to destination, write everything, ie without needing to know anything of the semantics of any of these registers. This means that registers which have access controls (eg can't write this unless you wrote to that other one first) should not enforce those checks for userspace get/set. More significantly, it means that registers with odd behaviour, like write 1 to clear or register A selects which of an array of underlying registers is exposed in register B are not directly exposed at all. Instead the kernel provides some other (ersatz) register indexes which let userspace do plain get/set on the underlying state. I came to the same conclusion. It could be implemented via a KVM_REQ_REEVALUATE, which causes all registers to be validated and applied before guest entry. The idea is that then migration depends only on whether the destination kernel supports all the registers the source kernel does, and we avoid extra dependencies on the source and destination qemu. (Most of the state being transferred is of no interest to userspace at all.) [It also makes write-multiple easier to use.] We also need to support migration to an earlier kernel. That means new state is not transferred (of course this state must not be exposed to the guest). There is also the hack with subsections: if we discover new hidden state, then qemu can avoid transferring it to an older kernel, provided the value matches the default (which should be often, otherwise the bug would have been discovered much earlier). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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: [Bright Cluster Manager Support #2699] NFSoRDMA not working with KVM when cache disabled
Hi, That is FULL install (I think) I create a new virtual machine each time I test it. Ta, Andrew On Aug 31, 2012, at 11:20 PM, Martijn de Vries wrote: Hi Andrew, That's pretty strange. I am not a KVM expert, so I don't know what happens under the hood when you disable cache. Have you tried doing a FULL install? Best regards, Martijn On Fri, Aug 31, 2012 at 7:06 PM, Andrew Holway supp...@brightcomputing.comwrote: Fri Aug 31 19:06:00 2012: Request 2699 was acted upon. Transaction: Ticket created by a.hol...@syseleven.de Queue: Bright Subject: NFSoRDMA not working with KVM when cache disabled Owner: Nobody Requestors: a.hol...@syseleven.de Status: new Ticket URL: http://support.brightcomputing.com/rt/Ticket/Display.html?id=2699 Hi, I am trying to host KVM machines on an NFSoRDMA mount. This works: -drive file=/mnt/vm001.img,if=none,id=drive-virtio-disk0,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 This Doesn't! -drive file=/mnt/vm001.img,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2 Any ideas why this could be? Thanks, Andrew dmesg: vda: vda: vda1 vda: vda1 vda: vda1 vda2 vda: vda1 vda2 vda: vda1 vda2 vda3 vda: vda1 vda2 vda3 vda: vda1 vda2 vda3 vda4 vda: vda1 vda2 vda3 vda4 vda: vda1 vda2 vda3 vda4 vda5 vda: vda1 vda2 vda3 vda4 vda5 vda: vda1 vda2 vda3 vda4 vda5 vda6 vda: vda1 vda2 vda3 vda4 vda5 vda6 Adding 15998968k swap on /dev/vda5. Priority:-1 extents:1 across:15998968k EXT3-fs (vda1): error: can't find ext3 filesystem on dev vda1. /var/log/messages Aug 31 18:53:46 (none) node-installer: Mounting disks. Aug 31 18:53:46 (none) node-installer: Updating device status: mounting disks Aug 31 18:53:46 (none) node-installer: Detecting device '/dev/sda': not found Aug 31 18:53:46 (none) node-installer: Detecting device '/dev/hda': not found Aug 31 18:53:46 (none) node-installer: Detecting device '/dev/vda': found Aug 31 18:53:46 (none) node-installer: swapon /dev/vda5 Aug 31 18:53:46 (none) node-installer: mkdir -p /localdisk/ Aug 31 18:53:46 (none) kernel: Adding 15998968k swap on /dev/vda5. Priority:-1 extents:1 across:15998968k Aug 31 18:53:46 (none) node-installer: Mounting /dev/vda1 on /localdisk/ Aug 31 18:53:46 (none) node-installer: mount -t ext3 -o defaults,noatime,nodiratime /dev/vda1 /localdisk/ Aug 31 18:53:46 (none) node-installer: mount: wrong fs type, bad option, bad superblock on /dev/vda1, Aug 31 18:53:46 (none) node-installer:missing codepage or helper program, or other error Aug 31 18:53:46 (none) node-installer:In some cases useful info is found in syslog - try Aug 31 18:53:46 (none) node-installer:dmesg | tail or so Aug 31 18:53:46 (none) node-installer: Aug 31 18:53:46 (none) node-installer: Command failed. Aug 31 18:53:46 (none) node-installer: Running: mount -t ext3 -o defaults,noatime,nodiratime /dev/vda1 /localdisk/ failed: Aug 31 18:53:46 (none) node-installer: Non zero exit code: 32 Aug 31 18:53:46 (none) kernel: EXT3-fs (vda1): error: can't find ext3 filesystem on dev vda1. Aug 31 18:53:46 (none) node-installer: Failed to mount disks. (Exit code 12, signal 0) Aug 31 18:53:46 (none) node-installer: There was a fatal problem. This node can not be installed until the problem is corrected. Aug 31 18:53:46 (none) node-installer: The error was: failed to mount disks Aug 31 18:53:46 (none) node-installer: Updating device status: failed to mount disks Aug 31 18:53:28 (none) node-installer: Creating primary partition /dev/vda3. Aug 31 18:53:28 (none) node-installer: parted -s -- /dev/vda mkpart primary ext3 22530 24578 Aug 31 18:53:28 (none) kernel: vda: vda1 vda2 vda3 Aug 31 18:53:28 (none) node-installer: dd if=/dev/zero of=/dev/vda3 bs=1k count=4 Aug 31 18:53:28 (none) node-installer: 4+0 records in Aug 31 18:53:28 (none) node-installer: 4+0 records out Aug 31 18:53:28 (none) node-installer: 4096 bytes (4.1 kB) copied, 0.000842261 s, 4.9 MB/s Aug 31 18:53:28 (none) node-installer: Running partprobe on device: /dev/vda Aug 31 18:53:28 (none) kernel: vda: vda1 vda2 vda3 Aug 31 18:53:45 (none) node-installer: Creating ext3 filesystem on /dev/vda3 Aug 31 18:53:45 (none) node-installer: mke2fs -j /dev/vda3 Aug 31 18:53:45 (none) node-installer: mke2fs 1.41.12 (17-May-2010) Aug 31 18:53:45 (none) node-installer: Filesystem label= Aug 31 18:53:45 (none) node-installer: OS type: Linux Aug 31 18:53:45 (none) node-installer: Block size=4096 (log=2) Aug 31 18:53:45 (none) node-installer: Fragment size=4096 (log=2) Aug 31 18:53:45 (none) node-installer: Stride=0 blocks, Stripe width=0 blocks Aug 31 18:53:45 (none) node-installer: 125184 inodes, 499968 blocks Aug 31 18:53:45 (none) node-installer: 24998 blocks
Re: [RFC 0/5] Making KVM_GET_ONE_REG/KVM_SET_ONE_REG generic.
Rusty Russell rusty.russ...@linaro.org writes: Hi all, This compiles, completely untested, but it's my attempt to give Avi (and Alexander) what he asked for in a generic register accessor. And here's the tested version: see my new onereg-abi branch. My next step is to demux CSELR, but that won't be until Tuesday. Cheers, Rusty. The following changes since commit bc9cf74d26786dd2063155f9c703b8cb19d4270d: KVM: ARM: Add trace and fix prints on guest aborts (2012-08-28 22:35:53 -0700) are available in the git repository at: gitol...@ra.kernel.org:/pub/scm/linux/kernel/git/rusty/linux-kvm-arm.git onereg-abi for you to fetch changes up to fcecd7ddb31cf75d509b7a7bb2df033042b1d6a8: KVM ARM: Update api.txt (2012-09-01 21:56:06 +0930) Rusty Russell (8): KVM: ARM: Fix walk_msrs() KVM: Move KVM_SET_ONE_REG/KVM_GET_ONE_REG to generic code. KVM: Add KVM_REG_SIZE() helper. KVM: ARM: use KVM_SET_ONE_REG/KVM_GET_ONE_REG. KVM: Add KVM_VCPU_GET_REG_LIST. KVM: ARM: Use KVM_VCPU_GET_REG_LIST. KVM: ARM: Access all registers via KVM_GET_ONE_REG/KVM_SET_ONE_REG. KVM ARM: Update api.txt Documentation/virtual/kvm/api.txt | 61 - arch/arm/include/asm/kvm.h | 77 arch/arm/include/asm/kvm_coproc.h |6 +- arch/arm/include/asm/kvm_host.h | 35 -- arch/arm/kvm/arm.c | 29 - arch/arm/kvm/coproc.c | 234 +++ arch/arm/kvm/emulate.c |2 +- arch/arm/kvm/guest.c| 158 ++- arch/arm/kvm/reset.c|4 +- arch/powerpc/include/asm/kvm_host.h |1 + arch/powerpc/kvm/book3s_hv.c|4 +- arch/powerpc/kvm/book3s_pr.c|4 +- arch/powerpc/kvm/booke.c|4 +- arch/powerpc/kvm/powerpc.c | 15 --- arch/s390/include/asm/kvm_host.h|1 + arch/s390/kvm/kvm-s390.c| 19 +-- include/linux/kvm.h | 10 +- include/linux/kvm_host.h|9 +- virt/kvm/kvm_main.c | 38 ++ 19 files changed, 340 insertions(+), 371 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: [RFC 0/5] Making KVM_GET_ONE_REG/KVM_SET_ONE_REG generic.
Avi Kivity a...@redhat.com writes:
-Capability: basic
+Capability: KVM_CAP_REG_LIST
Architectures: arm
all
OK, I guess that's to be true in future. Fixed.
Type: vcpu ioctl
-Parameters: struct kvm_msr_list (in/out)
+Parameters: struct kvm_reg_list (in/out)
Returns: 0 on success; -1 on error
Errors:
- E2BIG: the msr index list is too big to fit in the array specified by
- the user.
+ E2BIG: the reg index list is too big to fit in the array specified by
+ the user (the number required will be written into n).
struct kvm_msr_list {
-__u32 nmsrs; /* number of msrs in entries */
-__u32 indices[0];
+__u64 n; /* number of registers in reg[] */
+__u64 reg[0];
};
People complain that this interface is hard to use.
How about supplying the address of the array (in addition to n) so you
don't have to deal with variable sized arrays, and dropping E2BIG in
favour of always updating n (n changed to something bigger than you had
- reallocate and rerun)
We re-write n anyway, *and* return -E2BIG. Not returning an error is
asking for trouble.
Passing an address in a struct is pretty bad, since it involves
compatibility wrappers. I don't think that is what makes the API hard
to use.
Cheers,
Rusty.
--
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: [RFC 0/5] Making KVM_GET_ONE_REG/KVM_SET_ONE_REG generic.
Rusty Russell ru...@rustcorp.com.au writes: Rusty Russell rusty.russ...@linaro.org writes: Hi all, This compiles, completely untested, but it's my attempt to give Avi (and Alexander) what he asked for in a generic register accessor. And here's the tested version: see my new onereg-abi branch. My next step is to demux CSELR, but that won't be until Tuesday. Cheers, Rusty. The following changes since commit bc9cf74d26786dd2063155f9c703b8cb19d4270d: KVM: ARM: Add trace and fix prints on guest aborts (2012-08-28 22:35:53 -0700) are available in the git repository at: gitol...@ra.kernel.org:/pub/scm/linux/kernel/git/rusty/linux-kvm-arm.git onereg-abi ie: git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-kvm-arm.git onereg-abi Cheers, Rusty. -- 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: [RFC 5/5] KVM: ARM: Access all registers via KVM_GET_ONE_REG/KVM_SET_ONE_REG.
On Sep 1, 2012, at 6:25 AM, Peter Maydell peter.mayd...@linaro.org wrote: On 1 September 2012 10:16, Avi Kivity a...@redhat.com wrote: On 08/29/2012 11:21 AM, Rusty Russell wrote: + /* Coprocessor 0 means we want a core register. */ + if ((u32)reg-id KVM_REG_ARM_COPROC_START == 0) + return set_core_reg(vcpu, reg); ...but if we do go this path, you can't use coprocessor 0 to mean core register -- cp0 could be a valid coprocessor (the ARM ARM reserves cp0..cp7 for vendor specific features). Use something outside 0..15. OK, changed that too (16). And tomorrow they will add 16. Not possible in the instruction encoding :-) We haven't used anywhere near all the coprocessors (even given we've let the vendors have 0..7, ARM itself uses only 10 and 11 for the FPU, 14 for debug/perf and 15 for system control (and 14 and 15 still have lots of spare space). Yeah, but folding core registers under coprocessors feels just too fishy, so I think we should have a separate field. -Christoffer-- 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
