Re: Device pass-through
On 06.01.2012 08:25, Gordon Messmer wrote:
On 01/05/2012 11:07 AM, Gordon Messmer wrote:
I started with an update to seabios, from the bundled version
0.6.1.2-8.el6 to a rebuilt package from F16, 0.6.2-3.el6. That's enough
to get the guest to boot with the pass-through video card. It doesn't
work, currently, and I'm pretty sure that's because I can't read the ROM
from the card. I'm going to look around for a solution to that and will
update again.
Well, I finally figured out that I have to enable the reading of roms
from the device by writing 1 to the rom node in /sys/. Now the
problem is that the rom is 64k, and only 32k are making it into the
guest. I saw a reference to this problem here:
http://www.spinics.net/lists/kvm/msg49946.html
I've updated seabios to 0.6.3, and I've rebuilt the qemu-kvm packages
from F16 on CentOS 6.2 to try those. It took a while, but didn't change
the results. I'm still only able to read 32k of rom from the node in
/sys/ in the guest.
Perhaps I'd have better luck with a different card.
In the meantime, thanks for your advice. I think I'm close, and I'll
keep working on the project. If I get it working, I'll send along
further details with the steps I had to take.
Do you have the ROM as a file on your HDD perhaps? If so, you can try
the following: -device pci-assign,host=05:00.0,romfile=${ROMFILE}.
This used to work fine for me even with ROM file of around 130k.
Regards,
André
--
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
SPEC-file for making RPMs (with rpmbuild)
Hi, Is there a spec-file somewhere for creating RPMs from the newest qemu-kvm release? Regards, Guido -- 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: SPEC-file for making RPMs (with rpmbuild)
On Fri, Jan 06, 2012 at 11:11:21AM +0100, Guido Winkelmann wrote: Hi, Is there a spec-file somewhere for creating RPMs from the newest qemu-kvm release? The current Fedora RPM specfiles are always a good bet to start off with: http://pkgs.fedoraproject.org/gitweb/?p=qemu.git;a=blob;f=qemu.spec;hb=HEAD By default these will build all QEMU targets, and a dedicated qemu-kvm binary too.There is a flag to restrict it to x86 only for cases where you don't want all archs. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- 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] KVM: SVM: Add support for AMD's OSVW feature in guests
On Thu, Jan 05, 2012 at 01:37:36PM -0500, Boris Ostrovsky wrote:
On 01/05/12 06:20, Marcelo Tosatti wrote:
On Tue, Jan 03, 2012 at 11:38:13PM -0500, Boris Ostrovsky wrote:
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index e32243e..b19769d 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -110,6 +110,13 @@ struct nested_state {
#define MSRPM_OFFSETS 16
static u32 msrpm_offsets[MSRPM_OFFSETS] __read_mostly;
+/*
+ * Set osvw_len to higher value when updated Revision Guides
+ * are published and we know what the new status bits are
+ */
+static uint64_t osvw_len = 4, osvw_status;
+static DEFINE_SPINLOCK(svm_lock);
No need for this lock, operation already serialized by kvm_lock.
Will remove the lock.
struct vcpu_svm {
struct kvm_vcpu vcpu;
struct vmcb *vmcb;
@@ -556,6 +563,20 @@ static void svm_init_erratum_383(void)
erratum_383_found = true;
}
+static void svm_init_osvw(struct kvm_vcpu *vcpu)
+{
+ /*
+* Guests should see errata 400 and 415 as fixed (assuming that
+* HLT and IO instructions are intercepted).
+*/
+ vcpu-arch.osvw.length = (osvw_len= 3) ? (osvw_len) : 3;
+ vcpu-arch.osvw.status = osvw_status ~(6ULL);
Do you really want to expose the hosts osvw_status and osvw_len? If
only exposure of 400 and 415 as fixed is necessary, then dealing with
migration is simpler (that is, you control what workarounds are applied
in the guest instead of making it dependent on particular hosts).
I do think we should (selectively) expose osvw information to the
host. As of today we have 4 errata described by these bits. Two of
them (400 and 415) don't need to be seen by the guest and the patch
would mask them off. As for the other two (errata 383 and 298) ---
the guest should be aware of them and the patch passes them through.
Since osvw_len is initialized to 4 and cannot become larger no other
bits will be passed to guests until we update the initial value (by
a future patch).
OK.
If we are concerned about migration we can always ovewrite
vcpu-arch.osvw registers from userspace when creating a guest.
+ /* Mark erratum 298 as present */
+ if (osvw_len == 0 boot_cpu_data.x86 == 0x10)
+ vcpu-arch.osvw.status |= 1;
+}
Why is it necessary to explicitly do this? Please add documentation.
That's because we may have bumped vcpu-arch.osvw.length to 3 in
order to signal the guest that 400 and 415 are fixed. By doing this
we are also telling the guest that it can rely on state of bit0.
If we leave bit0 as 0 the guest will assume that 298 is fixed.
However, if host's osvw_length is 0 it means that the physical HW
*may* still be affected. So we take conservative approach and tell
the guest that it should work around 298.
I'll add a comment to that effect.
OK thanks.
+ case MSR_AMD64_OSVW_ID_LENGTH:
+ if (!guest_cpuid_has_osvw(vcpu))
+ return 1;
+ vcpu-arch.osvw.length = data;
+ break;
+ case MSR_AMD64_OSVW_STATUS:
+ if (!guest_cpuid_has_osvw(vcpu))
+ return 1;
+ vcpu-arch.osvw.status = data;
+ break;
If writes are allowed, it is necessary to migrate this.
Not sure I understand what you mean here. Isn't vcpu-arch state
migrated with the guest?
Since the MSR value is setup in the kernel, there is no need to migrate
it, actually.
--
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-ppc core dumps randomly on postgresql thread safety test
This is a QEMU bug, please send the bug report to qemu-de...@nongnu.org. On Thu, Jan 05, 2012 at 05:26:26PM -0500, Rengert, Mark wrote: Hi - I am using scratchbox2 under Ubuntu 10.04 to build postgresql for ppc. About half the time the configuration test for thread safety fails with a qemu-ppc coredump. It fails less often when QEMU_STRACE is defined but it still fails sometimes. It appears to happen in the pthread_join() call, I think. Here is the info requested on the KVM bug report webpage (http://www.linux-kvm.org/page/Bugs): CPU model: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz Host kernel: Linux florida 2.6.32-36-generic-pae #79-Ubuntu SMP Tue Nov 8 23:25:26 UTC 2011 i686 GNU/Linux Guest: via sb2 -t powerpc-unknown-linux-gnu Qemu command: (generated by scratchbox) /usr/bin/qemu-ppc -U LD_PRELOAD -L / -0 ./conftest ./conftest -- 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: kvm_steal_time_issue
On Thu, Jan 05, 2012 at 04:12:54PM +0200, d...@il.ibm.com wrote: I am using k3.2.0-rc1 where the kvm steal time handling is included The .config file has :CONFIG_PARAVIRT_GUEST=y,CONFIG_PARAVIRT_TIME_ACCOUNTING=y. I have a host and 2 guests with that kernel and devised a scenario where one guest should have %st 0 (Linux top utility) . Still I am always getting $st =0 at the guest top utility. What kernel version does the host run? It must include c9aaa8957f203b. -- 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 1/3]use int64 when compare two time
On 6 January 2012 07:37, Zhang, Yang Z yang.z.zh...@intel.com wrote: use int64 when compare two time int32 only represent only 136 years when comparing two times based on second. It would be better to use int64. int32, int32_t and 'int' which happens to be 32 bit are all different types; your changelog message is confusing them. Anyway, maybe we should be using time_t here? The functions use that internally anyway so is there a reason not to just use it in the API too? -- 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
[PATCH] KVM: MMU: unnecessary NX state assignment
From: Davidlohr Bueso d...@gnu.org
We can remove the first -nx state assignment since it is assigned afterwards
anyways.
Signed-off-by: Davidlohr Bueso d...@gnu.org
---
arch/x86/kvm/mmu.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index f1b36cf..efc0dd2 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -3320,7 +3320,6 @@ static int init_kvm_tdp_mmu(struct kvm_vcpu *vcpu)
context-get_cr3 = get_cr3;
context-get_pdptr = kvm_pdptr_read;
context-inject_page_fault = kvm_inject_page_fault;
- context-nx = is_nx(vcpu);
if (!is_paging(vcpu)) {
context-nx = false;
--
1.7.4.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: [PATCH v3] kvm tool: Change kvm-ram_size to real mapped size.
On Fri, Jan 6, 2012 at 4:06 AM, zanghongy...@huawei.com wrote: From: Hongyong Zang zanghongy...@huawei.com If a guest's ram_size exceeds KVM_32BIT_GAP_START, the corresponding kvm tool's virtual address size should be (ram_size + KVM_32BIT_GAP_SIZE), rather than ram_size. Use macro define KVM_32BIT_MAX_MEM_SIZE instead of magic number 0x1ULL. Signed-off-by: Hongyong Zang zanghongy...@huawei.com Applied, thanks! P.S. Please use my penb...@kernel.org email address for future patches, not the gmail one. -- 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: PCI passthrough in nested kvm
On Thu, 2012-01-05 at 23:50 -0500, Tian Fang wrote: Hi, Nested kvm is supported. Wondering if a PCI device is able to be passed through into the nested kvm. Could some experts share some insides? No, there's no iommu exposed to the L1 guest, so there's no way to program the iommu for the L2 guest. You would also be bouncing interrupts from the host to the L1 guest to the L2 guest, so you could expect a performance hit with each level you add. 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
[PATCH v2.1] KVM: SVM: Add support for AMD's OSVW feature in guests
From: Boris Ostrovsky boris.ostrov...@amd.com
In some cases guests should not provide workarounds for errata even when the
physical processor is affected. For example, because of erratum 400 on family
10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
going to idle in order to avoid getting stuck in a non-C0 state. This is not
necessary: HLT and IO instructions are intercepted and therefore there is no
reason for erratum 400 workaround in the guest.
This patch allows us to present a guest with certain errata as fixed,
regardless of the state of actual hardware.
Signed-off-by: Boris Ostrovsky boris.ostrov...@amd.com
---
arch/x86/include/asm/kvm_host.h |6
arch/x86/kvm/svm.c | 59 +++
arch/x86/kvm/x86.c | 30 +++-
3 files changed, 94 insertions(+), 1 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index b4973f4..9ef9215 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -452,6 +452,12 @@ struct kvm_vcpu_arch {
u32 id;
bool send_user_only;
} apf;
+
+ /* OSVW MSRs (AMD only) */
+ struct {
+ u64 length;
+ u64 status;
+ } osvw;
};
struct kvm_arch {
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index e32243e..da24706 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -110,6 +110,12 @@ struct nested_state {
#define MSRPM_OFFSETS 16
static u32 msrpm_offsets[MSRPM_OFFSETS] __read_mostly;
+/*
+ * Set osvw_len to higher value when updated Revision Guides
+ * are published and we know what the new status bits are
+ */
+static uint64_t osvw_len = 4, osvw_status;
+
struct vcpu_svm {
struct kvm_vcpu vcpu;
struct vmcb *vmcb;
@@ -556,6 +562,27 @@ static void svm_init_erratum_383(void)
erratum_383_found = true;
}
+static void svm_init_osvw(struct kvm_vcpu *vcpu)
+{
+ /*
+* Guests should see errata 400 and 415 as fixed (assuming that
+* HLT and IO instructions are intercepted).
+*/
+ vcpu-arch.osvw.length = (osvw_len = 3) ? (osvw_len) : 3;
+ vcpu-arch.osvw.status = osvw_status ~(6ULL);
+
+ /*
+* By increasing VCPU's osvw.length to 3 we are telling the guest that
+* all osvw.status bits inside that length, including bit 0 (which is
+* reserved for erratum 298), are valid. However, if host processor's
+* osvw_len is 0 then osvw_status[0] carries no information. We need to
+* be conservative here and therefore we tell the guest that erratum 298
+* is present (because we really don't know).
+*/
+ if (osvw_len == 0 boot_cpu_data.x86 == 0x10)
+ vcpu-arch.osvw.status |= 1;
+}
+
static int has_svm(void)
{
const char *msg;
@@ -620,6 +647,36 @@ static int svm_hardware_enable(void *garbage)
__get_cpu_var(current_tsc_ratio) = TSC_RATIO_DEFAULT;
}
+
+ /*
+* Get OSVW bits.
+*
+* Note that it is possible to have a system with mixed processor
+* revisions and therefore different OSVW bits. If bits are not the same
+* on different processors then choose the worst case (i.e. if erratum
+* is present on one processor and not on another then assume that the
+* erratum is present everywhere).
+*/
+ if (cpu_has(boot_cpu_data, X86_FEATURE_OSVW)) {
+ uint64_t len, status;
+ int err;
+
+ len = native_read_msr_safe(MSR_AMD64_OSVW_ID_LENGTH, err);
+ if (!err)
+ status = native_read_msr_safe(MSR_AMD64_OSVW_STATUS,
+ err);
+
+ if (err)
+ osvw_status = osvw_len = 0;
+ else {
+ if (len osvw_len)
+ osvw_len = len;
+ osvw_status |= status;
+ osvw_status = (1ULL osvw_len) - 1;
+ }
+ } else
+ osvw_status = osvw_len = 0;
+
svm_init_erratum_383();
return 0;
@@ -1185,6 +1242,8 @@ static struct kvm_vcpu *svm_create_vcpu(struct kvm *kvm,
unsigned int id)
if (kvm_vcpu_is_bsp(svm-vcpu))
svm-vcpu.arch.apic_base |= MSR_IA32_APICBASE_BSP;
+ svm_init_osvw(svm-vcpu);
+
return svm-vcpu;
free_page4:
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c38efd7..373c017 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -598,6 +598,14 @@ static bool guest_cpuid_has_fsgsbase(struct kvm_vcpu *vcpu)
return best (best-ebx bit(X86_FEATURE_FSGSBASE));
}
+static bool guest_cpuid_has_osvw(struct kvm_vcpu *vcpu)
+{
+ struct kvm_cpuid_entry2 *best;
+
+ best = kvm_find_cpuid_entry(vcpu, 0x8001, 0);
+
Re: [Qemu-devel] [PATCH 0/3] remove the periodic RTC update timer
Next time please thread your patch series together so that they can easily be reviewed and tested. git-send-email usually ensures that. Thanks, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- 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 3/3] stop the periodic RTC update timer
On 2012-01-06 05:37, Zhang, Yang Z wrote: change the RTC update logic to use host time with offset to calculate RTC clock. There have no need to use two periodic timers to maintain an internal timer for RTC clock update and alarm check. Instead, we calculate the real RTC time by the host time with an offset. For alarm and updated-end interrupt, if guest enabled it, then we setup a timer, or else, stop it. Signed-off-by: Yang Zhang yang.z.zh...@intel.com I appreciate this effort! However, not having looked at details yet, two things jumped at me: - You cannot simply change the vmstate format without caring about migration from older qemu versions. Ideally, if possible the existing format is kept and translated to new internal representations on save/load. - Please respect the coding style. It's documented, and we also have a checker. Thanks, Jab signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 1/3]use int64 when compare two time
Am 06.01.2012 08:37, schrieb Zhang, Yang Z:
use int64 when compare two time
int32 only represent only 136 years when comparing two times based on second.
It would be better to use int64.
int32 and int64 are softfloat types and should not be used here.
Do you have an actual use case that breaks with int / int32_t?
Signed-off-by: Yang Zhang yang.z.zh...@intel.com
diff --git a/vl.c b/vl.c
index 640e3ca..01c5a9d 100644
--- a/vl.c
+++ b/vl.c
@@ -454,7 +454,7 @@ void qemu_get_timedate(struct tm *tm, int offset)
memcpy(tm, ret, sizeof(struct tm));
}
-int qemu_timedate_diff(struct tm *tm)
+int64_t qemu_timedate_diff(struct tm *tm)
{
time_t seconds;
@@ -476,7 +476,7 @@ void rtc_change_mon_event(struct tm *tm)
{
QObject *data;
-data = qobject_from_jsonf({ 'offset': %d }, qemu_timedate_diff(tm));
+data = qobject_from_jsonf({ 'offset': %ld }, qemu_timedate_diff(tm));
That's wrong, %ld is for long. For int64_t you need to use PRId64.
Andreas
monitor_protocol_event(QEVENT_RTC_CHANGE, data);
qobject_decref(data);
}
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
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 2/3] KVM: PPC: Add support for explicit HIOR setting
On 01/05/2012 09:59 PM, Alexander Graf wrote:
diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index 25964ee..7e9e24d 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -327,4 +327,6 @@ struct kvm_book3e_206_tlb_params {
__u32 reserved[8];
};
+#define KVM_REG_PPC_HIOR KVM_REG_PPC | KVM_REG_SIZE_U64 | 0x1
Parentheses around macro definition
-Scott
--
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: PPC: Add generic single register ioctls
On 01/05/2012 10:15 PM, Alexander Graf wrote: Right now we transfer a static struct every time we want to get or set registers. Unfortunately, over time we realize that there are more of these than we thought of before and the extensibility and flexibility of transferring a full struct every time is limited. So this is a new approach to the problem. With these new ioctls, we can get and set a single register that is identified by an ID. This allows for very precise and limited transmittal of data. When we later realize that it's a better idea to shove over multiple registers at once, we can reuse most of the infrastructure and simply implement a GET_MANY_REGS / SET_MANY_REGS interface. The only downpoint I see to this one is that it needs to pad to 1024 bits (hardware is already on 512 bit registers, so I wanted to leave some room) which is slightly too much for transmitting only 64 bits. But if that's all the tradeoff we have to do for getting an extensible interface, I'd say go for it nevertheless. The comment about padding is no longer relevant. +/* + * Architecture specific registers are to be defined in arch headers and + * ORed with the arch identifier. + */ +#define KVM_REG_PPC 0x1000ULL +#define KVM_REG_X86 0x2000ULL +#define KVM_REG_IA64 0x3000ULL +#define KVM_REG_ARM 0x4000ULL +#define KVM_REG_S390 0x5000ULL + +#define KVM_REG_SIZE_SHIFT 52 +#define KVM_REG_SIZE_MASK0x00f0ULL +#define KVM_REG_SIZE_U8 0xULL +#define KVM_REG_SIZE_U16 0x0010ULL +#define KVM_REG_SIZE_U32 0x0020ULL +#define KVM_REG_SIZE_U64 0x0030ULL +#define KVM_REG_SIZE_U1280x0040ULL +#define KVM_REG_SIZE_U2560x0050ULL +#define KVM_REG_SIZE_U5120x0060ULL +#define KVM_REG_SIZE_U1024 0x0070ULL Why not just encode directly as number of bytes? -Scott -- 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: [Autotest PATCH v2 0/4] Network performance regression
On 01/05/2012 01:05 AM, Amos Kong wrote: This patchset adds a new network perf testcase for Windows, refactors old netperf test, and support numa resource control. Process the raw results to a 'standard format' at the end of test, then we can analyze them with general module, compute average and compare with old results. User can configure test time/repeat times for getting stable results. Welcome to give feedback, thanks in advance! I've made a first review of the series, with comments on your pull request: https://github.com/autotest/autotest/pull/126 Let me know what you think about my findings. Cheers, Lucas Changes from v1: - refactor analysis module - add new features in analysis code - shape those two tests - fix some script bugs - add autoio script for ntttcp test --- Amos Kong (4): virt-test: add NTttcp subtests virt-test: Refactor netperf test and add analysis module netperf: pin guest vcpus/memory/vhost thread to numa node virt: Introduce regression testing infrastructure client/tests/kvm/control|7 + client/tests/kvm/perf.conf | 23 +++ client/virt/scripts/ntttcp.au3 | 41 + client/virt/subtests.cfg.sample | 59 ++- client/virt/tests/analyzer.py | 172 ++ client/virt/tests/netperf.py| 312 --- client/virt/tests/ntttcp.py | 183 +++ client/virt/tests/regression.py | 34 8 files changed, 733 insertions(+), 98 deletions(-) create mode 100644 client/tests/kvm/perf.conf create mode 100755 client/virt/scripts/ntttcp.au3 create mode 100644 client/virt/tests/analyzer.py create mode 100644 client/virt/tests/ntttcp.py create mode 100644 client/virt/tests/regression.py -- 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 08/50] KVM: PPC: Add support for explicit HIOR setting
On 01/05/2012 08:35 PM, Alexander Graf wrote: Also we're already using KVM_REG for MMIO register identifiers. But I guess we can just reuse the namespace as long as we're careful to not overlap them later. #define KVM_REG_MASK0x001f #define KVM_REG_EXT_MASK0xffe0 #define KVM_REG_GPR 0x #define KVM_REG_FPR 0x0020 #define KVM_REG_QPR 0x0040 #define KVM_REG_FQPR0x0060 It looks like these are only used internally, despite being in the public header -- so renaming these is an option as well if it'd be confusing otherwise. -Scott -- 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
[KVM-autotest]Cpuflags test
Pull-Request: https://github.com/autotest/autotest/pull/133 -- 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
[KVM-autotest][PATCH 1/2] Virt test:Add new instruction sets
fma4, sse4a, xop
Signed-off-by: Jiří Župka jzu...@redhat.com
---
client/virt/deps/test_cpu_flags/Makefile| 83 +++
client/virt/deps/test_cpu_flags/aes.c | 13 +++-
client/virt/deps/test_cpu_flags/avx.c | 30 +
client/virt/deps/test_cpu_flags/cpuflags-test.c | 57 +++-
client/virt/deps/test_cpu_flags/fma4.c | 31 +
client/virt/deps/test_cpu_flags/pclmul.c| 10 ++-
client/virt/deps/test_cpu_flags/rdrand.c|6 +-
client/virt/deps/test_cpu_flags/sse3.c | 12 +++-
client/virt/deps/test_cpu_flags/sse4.c | 25 ++--
client/virt/deps/test_cpu_flags/sse4a.c | 37 ++
client/virt/deps/test_cpu_flags/ssse3.c | 14 +++-
client/virt/deps/test_cpu_flags/stress.c|6 ++
client/virt/deps/test_cpu_flags/tests.h | 38 --
client/virt/deps/test_cpu_flags/xop.c | 48 +
14 files changed, 309 insertions(+), 101 deletions(-)
create mode 100644 client/virt/deps/test_cpu_flags/fma4.c
create mode 100644 client/virt/deps/test_cpu_flags/sse4a.c
create mode 100644 client/virt/deps/test_cpu_flags/xop.c
diff --git a/client/virt/deps/test_cpu_flags/Makefile
b/client/virt/deps/test_cpu_flags/Makefile
index 5b77740..b95c36e 100644
--- a/client/virt/deps/test_cpu_flags/Makefile
+++ b/client/virt/deps/test_cpu_flags/Makefile
@@ -3,57 +3,42 @@ MKDIR = mkdir -p
OPTFLAGS=-O3
CFLAGS= -m64 ${OPTFLAGS} -std=c99 -pipe \
- -ftree-vectorize -ftree-vectorizer-verbose=0 \
+ -ftree-vectorize \
-ffast-math \
-fopenmp \
-CFLAGSAVX= -m64 ${OPTFLAGS} -std=c99 -pipe \
- -ftree-vectorize -ftree-vectorizer-verbose=0 \
- -ffast-math \
- -mavx \
- -fopenmp \
+CFLAGSAVX= ${CFLAGS} \
+ -mavx \
-CFLAGSSSE4= -m64 ${OPTFLAGS} -std=c99 -pipe \
- -ftree-vectorize -ftree-vectorizer-verbose=0 \
- -ffast-math \
+CFLAGSFMA4= ${CFLAGS} \
+ -mfma4 \
+
+CFLAGSSSE4A= ${CFLAGS} \
+ -msse4a \
+
+CFLAGSSSE4= ${CFLAGS} \
-msse4 -msse4.1 -msse4.2 \
- -fopenmp \
-CFLAGE3= -m64 ${OPTFLAGS} -std=c99 -pipe \
- -ftree-vectorize -ftree-vectorizer-verbose=0 \
- -ffast-math \
+CFLAGE3= ${CFLAGS} \
-mssse3 \
- -fopenmp \
-CFLAGSSSE3= -m64 ${OPTFLAGS} -std=c99 -pipe \
- -ftree-vectorize -ftree-vectorizer-verbose=0 \
- -ffast-math \
+CFLAGSSSE3= ${CFLAGS} \
-msse3 \
- -fopenmp \
-CFLAGSAES= -m64 ${OPTFLAGS} -std=c99 -pipe \
- -ftree-vectorize -ftree-vectorizer-verbose=0 \
- -ffast-math \
+CFLAGSAES= ${CFLAGS} \
-maes \
- -fopenmp \
-CFLAGSPCLMUL= -m64 ${OPTFLAGS} -std=c99 -pipe \
- -ftree-vectorize -ftree-vectorizer-verbose=0 \
- -ffast-math \
+CFLAGSPCLMUL= ${CFLAGS} \
-mpclmul \
- -fopenmp \
-CFLAGSRDRAND= -m64 ${OPTFLAGS} -std=c99 -pipe \
- -ftree-vectorize -ftree-vectorizer-verbose=0 \
- -ffast-math \
+CFLAGSRDRAND= ${CFLAGS} \
-mrdrnd \
- -fopenmp \
-CFLAGSSTRESS= -m64 ${OPTFLAGS} -std=c99 -pipe \
- -ftree-vectorize -ftree-vectorizer-verbose=0 \
- -ffast-math \
+CFLAGSXOP= ${CFLAGS} \
+ -mxop \
+
+CFLAGSSTRESS= ${CFLAGS} \
$(EXTRA_FLAGS) \
- -fopenmp \
CXX=g++
CC=gcc
@@ -66,39 +51,51 @@ default:cpuflags-test
all:cpuflags-test
-cpuflags-test: avx.o sse4.o ssse3.o sse3.o aes.o pclmul.o rdrand.o stress.o
+cpuflags-test: avx.o fma4.o xop.o sse4a.o sse4.o ssse3.o sse3.o aes.o pclmul.o
rdrand.o stress.o
$(CC) $(CFLAGS) $(LIBS) cpuflags-test.c -o cpuflags-test \
aes.o \
pclmul.o \
rdrand.o \
avx.o \
+ fma4.o \
+ xop.o \
+ sse4a.o \
sse4.o \
ssse3.o \
sse3.o \
stress.o \
-aes.o: aes.c
+aes.o: aes.c tests.h
$(CC) $(CFLAGSAES) $(LIBS) -c aes.c
-pclmul.o: pclmul.c
+pclmul.o: pclmul.c tests.h
$(CC) $(CFLAGSPCLMUL) $(LIBS) -c pclmul.c
-rdrand.o: rdrand.c
+rdrand.o: rdrand.c tests.h
$(CC) $(CFLAGSRDRAND) $(LIBS) -c rdrand.c
-avx.o: avx.c
+fma4.o: fma4.c tests.h
+ $(CC) $(CFLAGSFMA4) $(LIBS) -c fma4.c
+
+xop.o: xop.c tests.h
+ $(CC) $(CFLAGSXOP) $(LIBS) -c xop.c
+
+avx.o: avx.c tests.h
$(CC) $(CFLAGSAVX) $(LIBS) -c avx.c
-sse4.o: sse4.c
+sse4a.o: sse4a.c tests.h
+ $(CC) $(CFLAGSSSE4A) $(LIBS) -c sse4a.c
+
+sse4.o: sse4.c tests.h
$(CC) $(CFLAGSSSE4) $(LIBS) -c sse4.c
-ssse3.o: ssse3.c
+ssse3.o: ssse3.c tests.h
$(CC) $(CFLAGE3) $(LIBS) -c ssse3.c
-sse3.o: sse3.c
+sse3.o: sse3.c tests.h
$(CC) $(CFLAGSSSE3) $(LIBS) -c sse3.c
-stress.o: stress.c
+stress.o: stress.c tests.h
$(CC) $(CFLAGSSTRESS) $(LIBS) -c stress.c
ARCHIVE= cpuflags-test
diff --git a/client/virt/deps/test_cpu_flags/aes.c
[KVM-autotest][PATCH 2/2] Kvm test: Split cpuflags test to variants.
Clean up cpuflags-test code. Repair some minor bugs which were been created by merging to upstream. Signed-off-by: Jiří Župka jzu...@redhat.com --- client/tests/kvm/tests/cpuflags.py | 71 +++ client/virt/deps/test_cpu_flags/cpuflags-test.c |2 - client/virt/deps/test_cpu_flags/stress.c|6 +-- client/virt/subtests.cfg.sample |9 +++- client/virt/virt_utils.py |3 + 5 files changed, 58 insertions(+), 33 deletions(-) diff --git a/client/tests/kvm/tests/cpuflags.py b/client/tests/kvm/tests/cpuflags.py index 643e782..9409ae9 100644 --- a/client/tests/kvm/tests/cpuflags.py +++ b/client/tests/kvm/tests/cpuflags.py @@ -249,7 +249,8 @@ def run_cpuflags(test, params, env): for f in flags: try: for tc in virt_utils.kvm_map_flags_to_test[f]: -session.cmd(%s/cpuflags-test --%s % (path, tc)) +session.cmd(%s/cpuflags-test --%s % +(os.path.join(path,test_cpu_flags), tc)) pass_Flags.append(f) except aexpect.ShellCmdError: not_working.append(f) @@ -348,15 +349,17 @@ def run_cpuflags(test, params, env): test_qemu_dump() test_qemu_cpuid() +class test_temp(Subtest): +def clean(self): +logging.info(cleanup) +if (hasattr(self, vm)): +self.vm.destroy(gracefully=False) -def test_qemu_guest(): +def test_boot_guest(): 1) boot with cpu_model 2) migrate with flags 3) qemu-kvm-cmd -cpu model_name,+Flag -4) fail boot unsupported flags -5) check guest flags under load cpu, system (dd) -6) online/offline CPU cpu_models = params.get(cpu_models,).split() if not cpu_models: @@ -364,10 +367,10 @@ def run_cpuflags(test, params, env): logging.debug(CPU models found: %s, str(cpu_models)) # 1) boot with cpu_model -class test_boot_cpu_model(Subtest): +class test_boot_cpu_model(test_temp): def test(self, cpu_model): logging.debug(Run tests with cpu model %s, cpu_model) -flags = HgFlags(cpu_model, extra_flags) +flags = HgFlags(cpu_model) (self.vm, session) = start_guest_with_cpuflags(cpu_model) not_enable_flags = (check_cpuflags(cpu_model, session) - flags.hw_flags) @@ -375,13 +378,9 @@ def run_cpuflags(test, params, env): raise error.TestFail(Flags defined on host but not found on guest: %s % (not_enable_flags)) -def clean(self): -logging.info(cleanup) -self.vm.destroy(gracefully=False) - # 2) success boot with supported flags -class test_boot_cpu_model_and_additional_flags(test_boot_cpu_model): +class test_boot_cpu_model_and_additional_flags(test_temp): def test(self, cpu_model, extra_flags): flags = HgFlags(cpu_model, extra_flags) @@ -409,7 +408,7 @@ def run_cpuflags(test, params, env): not_enable_flags = (check_cpuflags(cpuf_model, session) - flags.hw_flags) if not_enable_flags != set([]): -logging.error(Model unsupported flags: %s, +logging.info(Model unsupported flags: %s, str(flags.cpumodel_unsupport_flags)) logging.error(Flags defined on host but not on found on guest: %s, str(not_enable_flags)) @@ -461,10 +460,31 @@ def run_cpuflags(test, params, env): if fwarn_flags: raise error.TestFail(Qemu did not warn the use of flags %s % str(fwarn_flags)) +for cpu_model in cpu_models: +try: +(cpu_model, extra_flags) = cpu_model.split(:) +extra_flags = set(map(virt_utils.Flag, extra_flags.split(,))) +except ValueError: +cpu_model = cpu_model +extra_flags = set([]) +test_fail_boot_with_host_unsupported_flags(cpu_model, extra_flags) +test_boot_cpu_model(cpu_model) +test_boot_cpu_model_and_additional_flags(cpu_model, extra_flags) +def test_stress_guest(): + +4) fail boot unsupported flags +5) check guest flags under load cpu, system (dd) +6) online/offline CPU + +cpu_models = params.get(cpu_models,).split() +if not cpu_models: +cpu_models = get_cpu_models() +logging.debug(CPU models found: %s, str(cpu_models)) + # 4) check guest flags under load cpu, stress and system (dd) -class
Re: [PATCH] KVM: PPC: Add generic single register ioctls
On 06.01.2012, at 20:32, Scott Wood scottw...@freescale.com wrote: On 01/05/2012 10:15 PM, Alexander Graf wrote: Right now we transfer a static struct every time we want to get or set registers. Unfortunately, over time we realize that there are more of these than we thought of before and the extensibility and flexibility of transferring a full struct every time is limited. So this is a new approach to the problem. With these new ioctls, we can get and set a single register that is identified by an ID. This allows for very precise and limited transmittal of data. When we later realize that it's a better idea to shove over multiple registers at once, we can reuse most of the infrastructure and simply implement a GET_MANY_REGS / SET_MANY_REGS interface. The only downpoint I see to this one is that it needs to pad to 1024 bits (hardware is already on 512 bit registers, so I wanted to leave some room) which is slightly too much for transmitting only 64 bits. But if that's all the tradeoff we have to do for getting an extensible interface, I'd say go for it nevertheless. The comment about padding is no longer relevant. +/* + * Architecture specific registers are to be defined in arch headers and + * ORed with the arch identifier. + */ +#define KVM_REG_PPC0x1000ULL +#define KVM_REG_X860x2000ULL +#define KVM_REG_IA640x3000ULL +#define KVM_REG_ARM0x4000ULL +#define KVM_REG_S3900x5000ULL + +#define KVM_REG_SIZE_SHIFT52 +#define KVM_REG_SIZE_MASK0x00f0ULL +#define KVM_REG_SIZE_U80xULL +#define KVM_REG_SIZE_U160x0010ULL +#define KVM_REG_SIZE_U320x0020ULL +#define KVM_REG_SIZE_U640x0030ULL +#define KVM_REG_SIZE_U1280x0040ULL +#define KVM_REG_SIZE_U2560x0050ULL +#define KVM_REG_SIZE_U5120x0060ULL +#define KVM_REG_SIZE_U10240x0070ULL Why not just encode directly as number of bytes? Because this is 1 n bytes :) Alex -Scott -- 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 08/50] KVM: PPC: Add support for explicit HIOR setting
On 06.01.2012, at 22:12, Scott Wood wrote: On 01/05/2012 08:35 PM, Alexander Graf wrote: Also we're already using KVM_REG for MMIO register identifiers. But I guess we can just reuse the namespace as long as we're careful to not overlap them later. #define KVM_REG_MASK0x001f #define KVM_REG_EXT_MASK0xffe0 #define KVM_REG_GPR 0x #define KVM_REG_FPR 0x0020 #define KVM_REG_QPR 0x0040 #define KVM_REG_FQPR0x0060 It looks like these are only used internally, despite being in the public header -- so renaming these is an option as well if it'd be confusing otherwise. Yup, let's rename them while we can! 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
[PATCH 0/4] GET/SET_ONE_REG and HIOR patches v3
This is a revised version of the ONE_REG interface. The main difference to v1 is that we now encode the register size in the constant, making it very unambiguous what size it is. That way we can just take a pointer from user space to write it to. Thanks a lot to Scott for reviewing the previous patches and pointing out some design issues before it actually lands upstream. v1 - v2: - do paranthesis - add patch to rename internal old KVM_REG constants - fix comments Alex Alexander Graf (3): KVM: PPC: Add generic single register ioctls KVM: PPC: Add support for explicit HIOR setting KVM: PPC: Rename MMIO register identifiers Paul Mackerras (1): KVM: PPC: Move kvm_vcpu_ioctl_[gs]et_one_reg down to platform-specific code Documentation/virtual/kvm/api.txt| 41 ++ arch/powerpc/include/asm/kvm.h | 14 ++ arch/powerpc/include/asm/kvm_book3s.h|2 + arch/powerpc/include/asm/kvm_ppc.h |3 ++ arch/powerpc/kvm/book3s_hv.c | 36 ++ arch/powerpc/kvm/book3s_paired_singles.c |9 -- arch/powerpc/kvm/book3s_pr.c | 38 ++- arch/powerpc/kvm/booke.c | 10 +++ arch/powerpc/kvm/powerpc.c | 34 ++-- include/linux/kvm.h | 36 ++ 10 files changed, 203 insertions(+), 20 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
[PATCH 1/4] KVM: PPC: Add generic single register ioctls
Right now we transfer a static struct every time we want to get or set
registers. Unfortunately, over time we realize that there are more of
these than we thought of before and the extensibility and flexibility of
transferring a full struct every time is limited.
So this is a new approach to the problem. With these new ioctls, we can
get and set a single register that is identified by an ID. This allows for
very precise and limited transmittal of data. When we later realize that
it's a better idea to shove over multiple registers at once, we can reuse
most of the infrastructure and simply implement a GET_MANY_REGS / SET_MANY_REGS
interface.
Signed-off-by: Alexander Graf ag...@suse.de
---
v1 - v2:
- rename KVM_ONE_REG to KVM_REG
- change semantics to include size in constant
and a user pointer to write/read to/from
- update documentation respectively
v2 - v3:
- make GET_ONE_REG ioctl write-only
---
Documentation/virtual/kvm/api.txt | 40
arch/powerpc/kvm/powerpc.c| 41 +
include/linux/kvm.h | 35 +++
3 files changed, 116 insertions(+), 0 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index a4d7b4d..8494214 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1523,6 +1523,46 @@ following algorithm:
Some guests configure the LINT1 NMI input to cause a panic, aiding in
debugging.
+4.65 KVM_SET_ONE_REG
+
+Capability: KVM_CAP_ONE_REG
+Architectures: all
+Type: vcpu ioctl
+Parameters: struct kvm_one_reg (in)
+Returns: 0 on success, negative value on failure
+
+struct kvm_one_reg {
+ __u64 id;
+ __u64 addr;
+};
+
+Using this ioctl, a single vcpu register can be set to a specific value
+defined by user space with the passed in struct kvm_one_reg, where id
+refers to the register identifier as described below and addr is a pointer
+to a variable with the respective size. There can be architecture agnostic
+and architecture specific registers. Each have their own range of operation
+and their own constants and width. To keep track of the implemented
+registers, find a list below:
+
+ Arch | Register| Width (bits)
+| |
+
+4.66 KVM_GET_ONE_REG
+
+Capability: KVM_CAP_ONE_REG
+Architectures: all
+Type: vcpu ioctl
+Parameters: struct kvm_one_reg (in and out)
+Returns: 0 on success, negative value on failure
+
+This ioctl allows to receive the value of a single register implemented
+in a vcpu. The register to read is indicated by the id field of the
+kvm_one_reg struct passed in. On success, the register value can be found
+at the memory location pointed to by addr.
+
+The list of registers accessible using this interface is identical to the
+list in 4.64.
+
5. The kvm_run structure
Application code obtains a pointer to the kvm_run structure by
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 76993eb..8bdd75b 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -214,6 +214,7 @@ int kvm_dev_ioctl_check_extension(long ext)
case KVM_CAP_PPC_UNSET_IRQ:
case KVM_CAP_PPC_IRQ_LEVEL:
case KVM_CAP_ENABLE_CAP:
+ case KVM_CAP_ONE_REG:
r = 1;
break;
#ifndef CONFIG_KVM_BOOK3S_64_HV
@@ -642,6 +643,32 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,
return r;
}
+static int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu,
+ struct kvm_one_reg *reg)
+{
+ int r = -EINVAL;
+
+ switch (reg-id) {
+ default:
+ break;
+ }
+
+ return r;
+}
+
+static int kvm_vcpu_ioctl_set_one_reg(struct kvm_vcpu *vcpu,
+ struct kvm_one_reg *reg)
+{
+ int r = -EINVAL;
+
+ switch (reg-id) {
+ default:
+ break;
+ }
+
+ return r;
+}
+
int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu,
struct kvm_mp_state *mp_state)
{
@@ -681,6 +708,20 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
break;
}
+ case KVM_SET_ONE_REG:
+ case KVM_GET_ONE_REG:
+ {
+ struct kvm_one_reg reg;
+ r = -EFAULT;
+ if (copy_from_user(reg, argp, sizeof(reg)))
+ goto out;
+ if (ioctl == KVM_SET_ONE_REG)
+ r = kvm_vcpu_ioctl_set_one_reg(vcpu, reg);
+ else
+ r = kvm_vcpu_ioctl_get_one_reg(vcpu, reg);
+ break;
+ }
+
#ifdef CONFIG_KVM_E500
case KVM_DIRTY_TLB: {
struct kvm_dirty_tlb dirty;
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 8d40db7..4b63ec1 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -557,6 +557,7 @@
[PATCH 2/4] KVM: PPC: Add support for explicit HIOR setting
Until now, we always set HIOR based on the PVR, but this is just wrong.
Instead, we should be setting HIOR explicitly, so user space can decide
what the initial HIOR value is - just like on real hardware.
We keep the old PVR based way around for backwards compatibility, but
once user space uses the SET_ONE_REG based method, we drop the PVR logic.
Signed-off-by: Alexander Graf ag...@suse.de
---
v1 - v2:
- rename KVM_ONE_REG to KVM_REG
- add size information to HIOR
- change HIOR number to 1, indicating that numbers are consecutive
v2 - v3:
- paranthesis around macro
---
Documentation/virtual/kvm/api.txt |1 +
arch/powerpc/include/asm/kvm.h|2 ++
arch/powerpc/include/asm/kvm_book3s.h |2 ++
arch/powerpc/kvm/book3s_pr.c |6 --
arch/powerpc/kvm/powerpc.c| 13 +
include/linux/kvm.h |1 +
6 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index 8494214..d73b8ea 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1546,6 +1546,7 @@ registers, find a list below:
Arch | Register| Width (bits)
| |
+ PPC | KVM_REG_PPC_HIOR | 64
4.66 KVM_GET_ONE_REG
diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index 25964ee..dea2156 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -327,4 +327,6 @@ struct kvm_book3e_206_tlb_params {
__u32 reserved[8];
};
+#define KVM_REG_PPC_HIOR (KVM_REG_PPC | KVM_REG_SIZE_U64 | 0x1)
+
#endif /* __LINUX_KVM_POWERPC_H */
diff --git a/arch/powerpc/include/asm/kvm_book3s.h
b/arch/powerpc/include/asm/kvm_book3s.h
index 3c3edee..aa795cc 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -90,6 +90,8 @@ struct kvmppc_vcpu_book3s {
#endif
int context_id[SID_CONTEXTS];
+ bool hior_explicit; /* HIOR is set by ioctl, not PVR */
+
struct hlist_head hpte_hash_pte[HPTEG_HASH_NUM_PTE];
struct hlist_head hpte_hash_pte_long[HPTEG_HASH_NUM_PTE_LONG];
struct hlist_head hpte_hash_vpte[HPTEG_HASH_NUM_VPTE];
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index c193625..00efda6 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -157,14 +157,16 @@ void kvmppc_set_pvr(struct kvm_vcpu *vcpu, u32 pvr)
#ifdef CONFIG_PPC_BOOK3S_64
if ((pvr = 0x33) (pvr 0x7033)) {
kvmppc_mmu_book3s_64_init(vcpu);
- to_book3s(vcpu)-hior = 0xfff0;
+ if (!to_book3s(vcpu)-hior_explicit)
+ to_book3s(vcpu)-hior = 0xfff0;
to_book3s(vcpu)-msr_mask = 0xULL;
vcpu-arch.cpu_type = KVM_CPU_3S_64;
} else
#endif
{
kvmppc_mmu_book3s_32_init(vcpu);
- to_book3s(vcpu)-hior = 0;
+ if (!to_book3s(vcpu)-hior_explicit)
+ to_book3s(vcpu)-hior = 0;
to_book3s(vcpu)-msr_mask = 0xULL;
vcpu-arch.cpu_type = KVM_CPU_3S_32;
}
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 8bdd75b..3dc9e99 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -209,6 +209,7 @@ int kvm_dev_ioctl_check_extension(long ext)
case KVM_CAP_PPC_BOOKE_SREGS:
#else
case KVM_CAP_PPC_SEGSTATE:
+ case KVM_CAP_PPC_HIOR:
case KVM_CAP_PPC_PAPR:
#endif
case KVM_CAP_PPC_UNSET_IRQ:
@@ -649,6 +650,11 @@ static int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu
*vcpu,
int r = -EINVAL;
switch (reg-id) {
+#ifdef CONFIG_PPC_BOOK3S
+ case KVM_REG_PPC_HIOR:
+ r = put_user(to_book3s(vcpu)-hior, (u64 __user *)reg-addr);
+ break;
+#endif
default:
break;
}
@@ -662,6 +668,13 @@ static int kvm_vcpu_ioctl_set_one_reg(struct kvm_vcpu
*vcpu,
int r = -EINVAL;
switch (reg-id) {
+#ifdef CONFIG_PPC_BOOK3S
+ case KVM_ONE_REG_PPC_HIOR:
+ r = get_user(to_book3s(vcpu)-hior, (u64 __user *)reg-addr);
+ if (!r)
+ to_book3s(vcpu)-hior_explicit = true;
+ break;
+#endif
default:
break;
}
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 4b63ec1..2c66df8 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -555,6 +555,7 @@ struct kvm_ppc_pvinfo {
#define KVM_CAP_PPC_SMT 64
#define KVM_CAP_PPC_RMA65
#define KVM_CAP_MAX_VCPUS 66 /* returns max vcpus per vm */
+#define KVM_CAP_PPC_HIOR 67
#define KVM_CAP_PPC_PAPR 68
#define KVM_CAP_SW_TLB 69
#define KVM_CAP_ONE_REG 70
--
1.6.0.2
--
To unsubscribe from this list: send the line
[PATCH 3/4] KVM: PPC: Move kvm_vcpu_ioctl_[gs]et_one_reg down to platform-specific code
From: Paul Mackerras pau...@samba.org
This moves the get/set_one_reg implementation down from powerpc.c into
booke.c, book3s_pr.c and book3s_hv.c. This avoids #ifdefs in C code,
but more importantly, it fixes a bug on Book3s HV where we were
accessing beyond the end of the kvm_vcpu struct (via the to_book3s()
macro) and corrupting memory, causing random crashes and file corruption.
On Book3s HV we only accept setting the HIOR to zero, since the guest
runs in supervisor mode and its vectors are never offset from zero.
Signed-off-by: Paul Mackerras pau...@samba.org
Signed-off-by: Alexander Graf ag...@suse.de
[agraf update to apply on top of changed ONE_REG patches]
---
arch/powerpc/include/asm/kvm_ppc.h |3 ++
arch/powerpc/kvm/book3s_hv.c | 36 ++
arch/powerpc/kvm/book3s_pr.c | 32 ++
arch/powerpc/kvm/booke.c | 10 +
arch/powerpc/kvm/powerpc.c | 38
5 files changed, 81 insertions(+), 38 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index fb70414..a61b5b5 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -176,6 +176,9 @@ int kvmppc_core_set_sregs(struct kvm_vcpu *vcpu, struct
kvm_sregs *sregs);
void kvmppc_get_sregs_ivor(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
int kvmppc_set_sregs_ivor(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
+int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg);
+int kvm_vcpu_ioctl_set_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg);
+
void kvmppc_set_pid(struct kvm_vcpu *vcpu, u32 pid);
#ifdef CONFIG_KVM_BOOK3S_64_HV
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index fdc804c..3580db8 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -398,6 +398,42 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
return 0;
}
+int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg)
+{
+ int r = -EINVAL;
+
+ switch (reg-id) {
+ case KVM_REG_PPC_HIOR:
+ r = put_user(0, (u64 __user *)reg-addr);
+ break;
+ default:
+ break;
+ }
+
+ return r;
+}
+
+int kvm_vcpu_ioctl_set_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg)
+{
+ int r = -EINVAL;
+
+ switch (reg-id) {
+ case KVM_REG_PPC_HIOR:
+ {
+ u64 hior;
+ /* Only allow this to be set to zero */
+ r = get_user(hior, (u64 __user *)reg-addr);
+ if (!r (hior != 0))
+ r = -EINVAL;
+ break;
+ }
+ default:
+ break;
+ }
+
+ return r;
+}
+
int kvmppc_core_check_processor_compat(void)
{
if (cpu_has_feature(CPU_FTR_HVMODE))
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index 00efda6..ee222ec 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -874,6 +874,38 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
return 0;
}
+int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg)
+{
+ int r = -EINVAL;
+
+ switch (reg-id) {
+ case KVM_REG_PPC_HIOR:
+ r = put_user(to_book3s(vcpu)-hior, (u64 __user *)reg-addr);
+ break;
+ default:
+ break;
+ }
+
+ return r;
+}
+
+int kvm_vcpu_ioctl_set_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg)
+{
+ int r = -EINVAL;
+
+ switch (reg-id) {
+ case KVM_REG_PPC_HIOR:
+ r = get_user(to_book3s(vcpu)-hior, (u64 __user *)reg-addr);
+ if (!r)
+ to_book3s(vcpu)-hior_explicit = true;
+ break;
+ default:
+ break;
+ }
+
+ return r;
+}
+
int kvmppc_core_check_processor_compat(void)
{
return 0;
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 9e41f45..ee9e1ee 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -887,6 +887,16 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
return kvmppc_core_set_sregs(vcpu, sregs);
}
+int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg)
+{
+ return -EINVAL;
+}
+
+int kvm_vcpu_ioctl_set_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg)
+{
+ return -EINVAL;
+}
+
int kvm_arch_vcpu_ioctl_get_fpu(struct kvm_vcpu *vcpu, struct kvm_fpu *fpu)
{
return -ENOTSUPP;
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 3dc9e99..d02cfe5 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -644,44 +644,6 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,
return r;
}
-static int
[PATCH 4/4] KVM: PPC: Rename MMIO register identifiers
We need the KVM_REG namespace for generic register settings now, so
let's rename the existing users to something different, enabling
us to reuse the namespace for more visible interfaces.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/include/asm/kvm.h | 12 ++--
arch/powerpc/kvm/book3s_paired_singles.c |9 ++---
arch/powerpc/kvm/powerpc.c | 18 +-
3 files changed, 21 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index dea2156..b56bf5f 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -265,12 +265,12 @@ struct kvm_debug_exit_arch {
struct kvm_guest_debug_arch {
};
-#define KVM_REG_MASK 0x001f
-#define KVM_REG_EXT_MASK 0xffe0
-#define KVM_REG_GPR0x
-#define KVM_REG_FPR0x0020
-#define KVM_REG_QPR0x0040
-#define KVM_REG_FQPR 0x0060
+#define KVM_MMIO_REG_MASK 0x001f
+#define KVM_MMIO_REG_EXT_MASK 0xffe0
+#define KVM_MMIO_REG_GPR 0x
+#define KVM_MMIO_REG_FPR 0x0020
+#define KVM_MMIO_REG_QPR 0x0040
+#define KVM_MMIO_REG_FQPR 0x0060
#define KVM_INTERRUPT_SET -1U
#define KVM_INTERRUPT_UNSET-2U
diff --git a/arch/powerpc/kvm/book3s_paired_singles.c
b/arch/powerpc/kvm/book3s_paired_singles.c
index 7b0ee96..e70ef2d 100644
--- a/arch/powerpc/kvm/book3s_paired_singles.c
+++ b/arch/powerpc/kvm/book3s_paired_singles.c
@@ -196,7 +196,8 @@ static int kvmppc_emulate_fpr_load(struct kvm_run *run,
struct kvm_vcpu *vcpu,
kvmppc_inject_pf(vcpu, addr, false);
goto done_load;
} else if (r == EMULATE_DO_MMIO) {
- emulated = kvmppc_handle_load(run, vcpu, KVM_REG_FPR | rs, len,
1);
+ emulated = kvmppc_handle_load(run, vcpu, KVM_MMIO_REG_FPR | rs,
+ len, 1);
goto done_load;
}
@@ -286,11 +287,13 @@ static int kvmppc_emulate_psq_load(struct kvm_run *run,
struct kvm_vcpu *vcpu,
kvmppc_inject_pf(vcpu, addr, false);
goto done_load;
} else if ((r == EMULATE_DO_MMIO) w) {
- emulated = kvmppc_handle_load(run, vcpu, KVM_REG_FPR | rs, 4,
1);
+ emulated = kvmppc_handle_load(run, vcpu, KVM_MMIO_REG_FPR | rs,
+ 4, 1);
vcpu-arch.qpr[rs] = tmp[1];
goto done_load;
} else if (r == EMULATE_DO_MMIO) {
- emulated = kvmppc_handle_load(run, vcpu, KVM_REG_FQPR | rs, 8,
1);
+ emulated = kvmppc_handle_load(run, vcpu, KVM_MMIO_REG_FQPR | rs,
+ 8, 1);
goto done_load;
}
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index d02cfe5..cd4ea18 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -445,20 +445,20 @@ static void kvmppc_complete_mmio_load(struct kvm_vcpu
*vcpu,
kvmppc_set_gpr(vcpu, vcpu-arch.io_gpr, gpr);
- switch (vcpu-arch.io_gpr KVM_REG_EXT_MASK) {
- case KVM_REG_GPR:
+ switch (vcpu-arch.io_gpr KVM_MMIO_REG_EXT_MASK) {
+ case KVM_MMIO_REG_GPR:
kvmppc_set_gpr(vcpu, vcpu-arch.io_gpr, gpr);
break;
- case KVM_REG_FPR:
- vcpu-arch.fpr[vcpu-arch.io_gpr KVM_REG_MASK] = gpr;
+ case KVM_MMIO_REG_FPR:
+ vcpu-arch.fpr[vcpu-arch.io_gpr KVM_MMIO_REG_MASK] = gpr;
break;
#ifdef CONFIG_PPC_BOOK3S
- case KVM_REG_QPR:
- vcpu-arch.qpr[vcpu-arch.io_gpr KVM_REG_MASK] = gpr;
+ case KVM_MMIO_REG_QPR:
+ vcpu-arch.qpr[vcpu-arch.io_gpr KVM_MMIO_REG_MASK] = gpr;
break;
- case KVM_REG_FQPR:
- vcpu-arch.fpr[vcpu-arch.io_gpr KVM_REG_MASK] = gpr;
- vcpu-arch.qpr[vcpu-arch.io_gpr KVM_REG_MASK] = gpr;
+ case KVM_MMIO_REG_FQPR:
+ vcpu-arch.fpr[vcpu-arch.io_gpr KVM_MMIO_REG_MASK] = gpr;
+ vcpu-arch.qpr[vcpu-arch.io_gpr KVM_MMIO_REG_MASK] = gpr;
break;
#endif
default:
--
1.6.0.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: Device pass-through
On 01/06/2012 01:31 AM, André Weidemann wrote:
On 06.01.2012 08:25, Gordon Messmer wrote:
Well, I finally figured out that I have to enable the reading of roms
from the device by writing 1 to the rom node in /sys/. Now the
problem is that the rom is 64k, and only 32k are making it into the
guest. I saw a reference to this problem here:
Do you have the ROM as a file on your HDD perhaps? If so, you can try
the following: -device pci-assign,host=05:00.0,romfile=${ROMFILE}.
This used to work fine for me even with ROM file of around 130k.
I do, and I'm actually using that. I'm using a shell script wrapper to
fix the argument for the PCI video card, since libvirt XML doesn't
seem to provide an option for rom files. The command that gets run is
included below.
I've learned that I was actually incorrect about the problem. The card
in the guest *does* have a 32K rom, but it's not a truncated version of
the ATI rom. Instead, it's the Plex86/Bochs VGABios (PCI). I've
tried starting the guest with no graphics or video hardware specified in
the libvirt XML, but qemu-kvm just eats a bunch of CPU time. I don't
see any serial console output (I do see grub and kernel output on the
serial console when I have virtual video hardware specified), so I'm
pretty sure the guest isn't actually starting.
/usr/libexec/qemu-kvm -S -M rhel6.2.0 -enable-kvm -m 4096 -smp
4,sockets=4,cores=1,threads=1 -name herald -uuid
556638be-ee50-e2f6-1d22-37b98b63b8d1 -nodefconfig -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/herald.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=readline -rtc base=utc -drive
file=/dev/mapper/VolGroup-lv_vm_herald,if=none,id=drive-virtio-disk0,format=raw,cache=none,aio=native
-device
virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
-device
virtio-net-pci,vlan=0,id=net0,mac=52:54:00:21:e7:9e,bus=pci.0,addr=0x3
-net tap,fd=25,vlan=0,name=hostnet0 -chardev pty,id=charserial0 -device
isa-serial,chardev=charserial0,id=serial0 -usb -device
usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga cirrus -device
pci-assign,host=00:14.2,id=hostdev0,configfd=26,bus=pci.0,addr=0x5
-device
pci-assign,host=05:00.0,id=hostdev1,configfd=27,bus=pci.0,addr=0x7,romfile=/var/lib/libvirt/images/Radeon3470.rom
-device usb-host,hostbus=5,hostaddr=3,id=hostdev2 -device
usb-host,hostbus=7,hostaddr=3,id=hostdev3 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6
--
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 v7] kvm: make vcpu life cycle separated from kvm instance
From: Liu Ping Fan pingf...@linux.vnet.ibm.com
Currently, vcpu will be destructed only after kvm instance is
destroyed. This result to vcpu keep idle in kernel, but can not
be freed when it is unplugged in guest.
Change this to vcpu's destruction before kvm instance, so vcpu MUST
and CAN be destroyed before kvm instance. By this way, we can remove
vcpu when guest does not need it any longer.
TODO: push changes to other archs besides x86.
Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com
---
Changelog: v6-v7
-Remove kvm-srcu_vcpus, and resort to kvm-srcu for it is helpless
to perfermence after measurement.
-Rename kvm_vcpu_zap to kvm_vcpu_destruct and so on.
arch/x86/kvm/i8254.c | 10 +++--
arch/x86/kvm/i8259.c | 17 +--
arch/x86/kvm/x86.c | 53 +++
include/linux/kvm_host.h | 19 +++-
virt/kvm/irq_comm.c |6 ++-
virt/kvm/kvm_main.c | 105 ++---
6 files changed, 134 insertions(+), 76 deletions(-)
diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c
index d68f99d..a737fb6 100644
--- a/arch/x86/kvm/i8254.c
+++ b/arch/x86/kvm/i8254.c
@@ -289,9 +289,8 @@ static void pit_do_work(struct work_struct *work)
struct kvm_pit *pit = container_of(work, struct kvm_pit, expired);
struct kvm *kvm = pit-kvm;
struct kvm_vcpu *vcpu;
- int i;
struct kvm_kpit_state *ps = pit-pit_state;
- int inject = 0;
+ int idx, inject = 0;
/* Try to inject pending interrupts when
* last one has been acked.
@@ -315,9 +314,12 @@ static void pit_do_work(struct work_struct *work)
* LVT0 to NMI delivery. Other PIC interrupts are just sent to
* VCPU0, and only if its LVT0 is in EXTINT mode.
*/
- if (kvm-arch.vapics_in_nmi_mode 0)
- kvm_for_each_vcpu(i, vcpu, kvm)
+ if (kvm-arch.vapics_in_nmi_mode 0) {
+ idx = srcu_read_lock(kvm-srcu);
+ kvm_for_each_vcpu(vcpu, kvm)
kvm_apic_nmi_wd_deliver(vcpu);
+ srcu_read_unlock(kvm-srcu, idx);
+ }
}
}
diff --git a/arch/x86/kvm/i8259.c b/arch/x86/kvm/i8259.c
index b6a7353..fc0fd76 100644
--- a/arch/x86/kvm/i8259.c
+++ b/arch/x86/kvm/i8259.c
@@ -50,25 +50,29 @@ static void pic_unlock(struct kvm_pic *s)
{
bool wakeup = s-wakeup_needed;
struct kvm_vcpu *vcpu, *found = NULL;
- int i;
+ struct kvm *kvm = s-kvm;
+ int idx;
s-wakeup_needed = false;
spin_unlock(s-lock);
if (wakeup) {
- kvm_for_each_vcpu(i, vcpu, s-kvm) {
+ idx = srcu_read_lock(kvm-srcu);
+ kvm_for_each_vcpu(vcpu, kvm)
if (kvm_apic_accept_pic_intr(vcpu)) {
found = vcpu;
break;
}
- }
- if (!found)
+ if (!found) {
+ srcu_read_unlock(kvm-srcu, idx);
return;
+ }
kvm_make_request(KVM_REQ_EVENT, found);
kvm_vcpu_kick(found);
+ srcu_read_unlock(kvm-srcu, idx);
}
}
@@ -265,6 +269,7 @@ void kvm_pic_reset(struct kvm_kpic_state *s)
int irq, i;
struct kvm_vcpu *vcpu;
u8 irr = s-irr, isr = s-imr;
+ struct kvm *kvm = s-pics_state-kvm;
bool found = false;
s-last_irr = 0;
@@ -282,11 +287,13 @@ void kvm_pic_reset(struct kvm_kpic_state *s)
s-special_fully_nested_mode = 0;
s-init4 = 0;
- kvm_for_each_vcpu(i, vcpu, s-pics_state-kvm)
+ i = srcu_read_lock(kvm-srcu);
+ kvm_for_each_vcpu(vcpu, kvm)
if (kvm_apic_accept_pic_intr(vcpu)) {
found = true;
break;
}
+ srcu_read_unlock(kvm-srcu, i);
if (!found)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 1171def..c14892f 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1786,14 +1786,20 @@ static int get_msr_hyperv_pw(struct kvm_vcpu *vcpu, u32
msr, u64 *pdata)
static int get_msr_hyperv(struct kvm_vcpu *vcpu, u32 msr, u64 *pdata)
{
u64 data = 0;
+ int idx;
switch (msr) {
case HV_X64_MSR_VP_INDEX: {
- int r;
+ int r = 0;
struct kvm_vcpu *v;
- kvm_for_each_vcpu(r, v, vcpu-kvm)
+ struct kvm *kvm = vcpu-kvm;
+ idx = srcu_read_lock(kvm-srcu);
+ kvm_for_each_vcpu(v, vcpu-kvm) {
if (v == vcpu)
data = r;
+ r++;
+ }
+ srcu_read_unlock(kvm-srcu, idx);
break;
}
case HV_X64_MSR_EOI:
@@
Re: [PATCH] KVM: PPC: Add generic single register ioctls
On 01/05/2012 10:15 PM, Alexander Graf wrote: Right now we transfer a static struct every time we want to get or set registers. Unfortunately, over time we realize that there are more of these than we thought of before and the extensibility and flexibility of transferring a full struct every time is limited. So this is a new approach to the problem. With these new ioctls, we can get and set a single register that is identified by an ID. This allows for very precise and limited transmittal of data. When we later realize that it's a better idea to shove over multiple registers at once, we can reuse most of the infrastructure and simply implement a GET_MANY_REGS / SET_MANY_REGS interface. The only downpoint I see to this one is that it needs to pad to 1024 bits (hardware is already on 512 bit registers, so I wanted to leave some room) which is slightly too much for transmitting only 64 bits. But if that's all the tradeoff we have to do for getting an extensible interface, I'd say go for it nevertheless. The comment about padding is no longer relevant. +/* + * Architecture specific registers are to be defined in arch headers and + * ORed with the arch identifier. + */ +#define KVM_REG_PPC 0x1000ULL +#define KVM_REG_X86 0x2000ULL +#define KVM_REG_IA64 0x3000ULL +#define KVM_REG_ARM 0x4000ULL +#define KVM_REG_S390 0x5000ULL + +#define KVM_REG_SIZE_SHIFT 52 +#define KVM_REG_SIZE_MASK0x00f0ULL +#define KVM_REG_SIZE_U8 0xULL +#define KVM_REG_SIZE_U16 0x0010ULL +#define KVM_REG_SIZE_U32 0x0020ULL +#define KVM_REG_SIZE_U64 0x0030ULL +#define KVM_REG_SIZE_U1280x0040ULL +#define KVM_REG_SIZE_U2560x0050ULL +#define KVM_REG_SIZE_U5120x0060ULL +#define KVM_REG_SIZE_U1024 0x0070ULL Why not just encode directly as number of bytes? -Scott -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/50] KVM: PPC: Add support for explicit HIOR setting
On 01/05/2012 08:35 PM, Alexander Graf wrote: Also we're already using KVM_REG for MMIO register identifiers. But I guess we can just reuse the namespace as long as we're careful to not overlap them later. #define KVM_REG_MASK0x001f #define KVM_REG_EXT_MASK0xffe0 #define KVM_REG_GPR 0x #define KVM_REG_FPR 0x0020 #define KVM_REG_QPR 0x0040 #define KVM_REG_FQPR0x0060 It looks like these are only used internally, despite being in the public header -- so renaming these is an option as well if it'd be confusing otherwise. -Scott -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] GET/SET_ONE_REG and HIOR patches v3
This is a revised version of the ONE_REG interface. The main difference to v1 is that we now encode the register size in the constant, making it very unambiguous what size it is. That way we can just take a pointer from user space to write it to. Thanks a lot to Scott for reviewing the previous patches and pointing out some design issues before it actually lands upstream. v1 - v2: - do paranthesis - add patch to rename internal old KVM_REG constants - fix comments Alex Alexander Graf (3): KVM: PPC: Add generic single register ioctls KVM: PPC: Add support for explicit HIOR setting KVM: PPC: Rename MMIO register identifiers Paul Mackerras (1): KVM: PPC: Move kvm_vcpu_ioctl_[gs]et_one_reg down to platform-specific code Documentation/virtual/kvm/api.txt| 41 ++ arch/powerpc/include/asm/kvm.h | 14 ++ arch/powerpc/include/asm/kvm_book3s.h|2 + arch/powerpc/include/asm/kvm_ppc.h |3 ++ arch/powerpc/kvm/book3s_hv.c | 36 ++ arch/powerpc/kvm/book3s_paired_singles.c |9 -- arch/powerpc/kvm/book3s_pr.c | 38 ++- arch/powerpc/kvm/booke.c | 10 +++ arch/powerpc/kvm/powerpc.c | 34 ++-- include/linux/kvm.h | 36 ++ 10 files changed, 203 insertions(+), 20 deletions(-) -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] KVM: PPC: Add generic single register ioctls
Right now we transfer a static struct every time we want to get or set
registers. Unfortunately, over time we realize that there are more of
these than we thought of before and the extensibility and flexibility of
transferring a full struct every time is limited.
So this is a new approach to the problem. With these new ioctls, we can
get and set a single register that is identified by an ID. This allows for
very precise and limited transmittal of data. When we later realize that
it's a better idea to shove over multiple registers at once, we can reuse
most of the infrastructure and simply implement a GET_MANY_REGS / SET_MANY_REGS
interface.
Signed-off-by: Alexander Graf ag...@suse.de
---
v1 - v2:
- rename KVM_ONE_REG to KVM_REG
- change semantics to include size in constant
and a user pointer to write/read to/from
- update documentation respectively
v2 - v3:
- make GET_ONE_REG ioctl write-only
---
Documentation/virtual/kvm/api.txt | 40
arch/powerpc/kvm/powerpc.c| 41 +
include/linux/kvm.h | 35 +++
3 files changed, 116 insertions(+), 0 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index a4d7b4d..8494214 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1523,6 +1523,46 @@ following algorithm:
Some guests configure the LINT1 NMI input to cause a panic, aiding in
debugging.
+4.65 KVM_SET_ONE_REG
+
+Capability: KVM_CAP_ONE_REG
+Architectures: all
+Type: vcpu ioctl
+Parameters: struct kvm_one_reg (in)
+Returns: 0 on success, negative value on failure
+
+struct kvm_one_reg {
+ __u64 id;
+ __u64 addr;
+};
+
+Using this ioctl, a single vcpu register can be set to a specific value
+defined by user space with the passed in struct kvm_one_reg, where id
+refers to the register identifier as described below and addr is a pointer
+to a variable with the respective size. There can be architecture agnostic
+and architecture specific registers. Each have their own range of operation
+and their own constants and width. To keep track of the implemented
+registers, find a list below:
+
+ Arch | Register| Width (bits)
+| |
+
+4.66 KVM_GET_ONE_REG
+
+Capability: KVM_CAP_ONE_REG
+Architectures: all
+Type: vcpu ioctl
+Parameters: struct kvm_one_reg (in and out)
+Returns: 0 on success, negative value on failure
+
+This ioctl allows to receive the value of a single register implemented
+in a vcpu. The register to read is indicated by the id field of the
+kvm_one_reg struct passed in. On success, the register value can be found
+at the memory location pointed to by addr.
+
+The list of registers accessible using this interface is identical to the
+list in 4.64.
+
5. The kvm_run structure
Application code obtains a pointer to the kvm_run structure by
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 76993eb..8bdd75b 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -214,6 +214,7 @@ int kvm_dev_ioctl_check_extension(long ext)
case KVM_CAP_PPC_UNSET_IRQ:
case KVM_CAP_PPC_IRQ_LEVEL:
case KVM_CAP_ENABLE_CAP:
+ case KVM_CAP_ONE_REG:
r = 1;
break;
#ifndef CONFIG_KVM_BOOK3S_64_HV
@@ -642,6 +643,32 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,
return r;
}
+static int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu,
+ struct kvm_one_reg *reg)
+{
+ int r = -EINVAL;
+
+ switch (reg-id) {
+ default:
+ break;
+ }
+
+ return r;
+}
+
+static int kvm_vcpu_ioctl_set_one_reg(struct kvm_vcpu *vcpu,
+ struct kvm_one_reg *reg)
+{
+ int r = -EINVAL;
+
+ switch (reg-id) {
+ default:
+ break;
+ }
+
+ return r;
+}
+
int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu,
struct kvm_mp_state *mp_state)
{
@@ -681,6 +708,20 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
break;
}
+ case KVM_SET_ONE_REG:
+ case KVM_GET_ONE_REG:
+ {
+ struct kvm_one_reg reg;
+ r = -EFAULT;
+ if (copy_from_user(reg, argp, sizeof(reg)))
+ goto out;
+ if (ioctl == KVM_SET_ONE_REG)
+ r = kvm_vcpu_ioctl_set_one_reg(vcpu, reg);
+ else
+ r = kvm_vcpu_ioctl_get_one_reg(vcpu, reg);
+ break;
+ }
+
#ifdef CONFIG_KVM_E500
case KVM_DIRTY_TLB: {
struct kvm_dirty_tlb dirty;
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 8d40db7..4b63ec1 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -557,6 +557,7 @@
[PATCH 4/4] KVM: PPC: Rename MMIO register identifiers
We need the KVM_REG namespace for generic register settings now, so
let's rename the existing users to something different, enabling
us to reuse the namespace for more visible interfaces.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/include/asm/kvm.h | 12 ++--
arch/powerpc/kvm/book3s_paired_singles.c |9 ++---
arch/powerpc/kvm/powerpc.c | 18 +-
3 files changed, 21 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index dea2156..b56bf5f 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -265,12 +265,12 @@ struct kvm_debug_exit_arch {
struct kvm_guest_debug_arch {
};
-#define KVM_REG_MASK 0x001f
-#define KVM_REG_EXT_MASK 0xffe0
-#define KVM_REG_GPR0x
-#define KVM_REG_FPR0x0020
-#define KVM_REG_QPR0x0040
-#define KVM_REG_FQPR 0x0060
+#define KVM_MMIO_REG_MASK 0x001f
+#define KVM_MMIO_REG_EXT_MASK 0xffe0
+#define KVM_MMIO_REG_GPR 0x
+#define KVM_MMIO_REG_FPR 0x0020
+#define KVM_MMIO_REG_QPR 0x0040
+#define KVM_MMIO_REG_FQPR 0x0060
#define KVM_INTERRUPT_SET -1U
#define KVM_INTERRUPT_UNSET-2U
diff --git a/arch/powerpc/kvm/book3s_paired_singles.c
b/arch/powerpc/kvm/book3s_paired_singles.c
index 7b0ee96..e70ef2d 100644
--- a/arch/powerpc/kvm/book3s_paired_singles.c
+++ b/arch/powerpc/kvm/book3s_paired_singles.c
@@ -196,7 +196,8 @@ static int kvmppc_emulate_fpr_load(struct kvm_run *run,
struct kvm_vcpu *vcpu,
kvmppc_inject_pf(vcpu, addr, false);
goto done_load;
} else if (r == EMULATE_DO_MMIO) {
- emulated = kvmppc_handle_load(run, vcpu, KVM_REG_FPR | rs, len,
1);
+ emulated = kvmppc_handle_load(run, vcpu, KVM_MMIO_REG_FPR | rs,
+ len, 1);
goto done_load;
}
@@ -286,11 +287,13 @@ static int kvmppc_emulate_psq_load(struct kvm_run *run,
struct kvm_vcpu *vcpu,
kvmppc_inject_pf(vcpu, addr, false);
goto done_load;
} else if ((r == EMULATE_DO_MMIO) w) {
- emulated = kvmppc_handle_load(run, vcpu, KVM_REG_FPR | rs, 4,
1);
+ emulated = kvmppc_handle_load(run, vcpu, KVM_MMIO_REG_FPR | rs,
+ 4, 1);
vcpu-arch.qpr[rs] = tmp[1];
goto done_load;
} else if (r == EMULATE_DO_MMIO) {
- emulated = kvmppc_handle_load(run, vcpu, KVM_REG_FQPR | rs, 8,
1);
+ emulated = kvmppc_handle_load(run, vcpu, KVM_MMIO_REG_FQPR | rs,
+ 8, 1);
goto done_load;
}
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index d02cfe5..cd4ea18 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -445,20 +445,20 @@ static void kvmppc_complete_mmio_load(struct kvm_vcpu
*vcpu,
kvmppc_set_gpr(vcpu, vcpu-arch.io_gpr, gpr);
- switch (vcpu-arch.io_gpr KVM_REG_EXT_MASK) {
- case KVM_REG_GPR:
+ switch (vcpu-arch.io_gpr KVM_MMIO_REG_EXT_MASK) {
+ case KVM_MMIO_REG_GPR:
kvmppc_set_gpr(vcpu, vcpu-arch.io_gpr, gpr);
break;
- case KVM_REG_FPR:
- vcpu-arch.fpr[vcpu-arch.io_gpr KVM_REG_MASK] = gpr;
+ case KVM_MMIO_REG_FPR:
+ vcpu-arch.fpr[vcpu-arch.io_gpr KVM_MMIO_REG_MASK] = gpr;
break;
#ifdef CONFIG_PPC_BOOK3S
- case KVM_REG_QPR:
- vcpu-arch.qpr[vcpu-arch.io_gpr KVM_REG_MASK] = gpr;
+ case KVM_MMIO_REG_QPR:
+ vcpu-arch.qpr[vcpu-arch.io_gpr KVM_MMIO_REG_MASK] = gpr;
break;
- case KVM_REG_FQPR:
- vcpu-arch.fpr[vcpu-arch.io_gpr KVM_REG_MASK] = gpr;
- vcpu-arch.qpr[vcpu-arch.io_gpr KVM_REG_MASK] = gpr;
+ case KVM_MMIO_REG_FQPR:
+ vcpu-arch.fpr[vcpu-arch.io_gpr KVM_MMIO_REG_MASK] = gpr;
+ vcpu-arch.qpr[vcpu-arch.io_gpr KVM_MMIO_REG_MASK] = gpr;
break;
#endif
default:
--
1.6.0.2
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
