Re: [kvm-devel] KVM Test result, kernel 3959211b.. , userspace 5bf06ab9..
Zhang, Jingke wrote: > 1. Could not create kvm guest with memory >=2040 > http://otc-qa.sh.intel.com/kvm/bugzilla/show_bug.cgi?id=6 > https://sourceforge.net/tracker/index.php?func=detail&aid=1736307&group_ > id=180599&atid=893831 > This is only on an i386 host, right? In x86_64 this should work. There are no plans to extend the limit on i386, if people want large memory guests they should use a 64-bit hypervisor. It's 2007 now, not 1999. Xen needs to support large memory guests on a 32bit dom0 because paravirtualized 64-bit dom0 is slow; kvm has no such issue. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Vista 32 Premium 32 bit gets blue screen on boot
Haydn Solomon wrote: > Ok. I've tested the list of bios images for booting vista premium 32 > bit. The results are as follows: > Sorry, I regenerated the bios images incorrectly, so some of these images are stale. Unfortunately, this includes the images at the working->nonworking crossover. I've regenerated the images with a 'make clean' and a forced recompilation of the ACPI tables (and eliminated some duplicates). Can you retest? Location is the same at http://people.qumranet.com/avi/bios-images. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC][PATCH 5/6][KVM VIRTIO] Add the network device code
Am Samstag, 25. August 2007 schrieb Dor Laor: > + * Permission is hereby granted, free of charge, to any person > obtaining a copy Hi Dor, some of your patch lines seem line-wrapped. Is there place where I can download the whole series? Thanks Christian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Vista 32 Premium 32 bit gets blue screen on boot
This problem is already reported here: http://sourceforge.net/tracker/index.php?func=detail&aid=1780032&group_id=180599&atid=893831 -- -Alexey Eremenko "Technologov" - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/4] [HYPERCALL] Add hypercalls functions
Am Samstag, 25. August 2007 schrieb Dor Laor:
> + asm (" call hypercall_addr\n"
Hi Dor,
This cannot work, because hypercall_addr is currently not defined in todays
kvm.git:
# grep -R hypercall_addr *
drivers/kvm/kvm.h:unsigned char *hypercall_addr);
#
IIRC there was a definition of hypercall_addr in the older paravirt drivers
from the rt-kernel. It seems it did not make it into this patch set.
Christian
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/4] [HYPERCALL] Add hypercalls functions
Am Samstag, 25. August 2007 schrieb Dor Laor:
> +static inline int
> +__hypercall2(unsigned int nr, unsigned long p1, unsigned long p2)
> +{
> + int ret;
> + asm (" call hypercall_addr\n"
[...]
> + return ret;
Hello Dor,
Linux system calls return long. I think hypercalls should behave in a similar
manner and return long as well, no?
Christian
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Userspace hypercalls?
I've never really thought much about them until now. What's the case for supporting userspace hypercalls? The current way the code works is a little scary. Hypercalls that aren't handled by kernelspace are deferred to userspace. Of course, kernelspace has no idea whether userspace is actually using a given hypercall so if kernelspace needs another one, the two may clash. AFAICT, the primary reason to use hypercalls is performance. A vmcall is a few hundred cycles faster than a PIO exit. In the light-weight exit path, this may make a significant different. However, when going to userspace, it's not only a heavy-weight exit but it's also paying the cost of a ring transition. The few hundred cycle savings is small in comparison to the total cost so I don't think performance is a real benefit here. The hypercall namespace is much smaller than the PIO namespace, and there's no "plug-and-play" like mechanism to resolve conflict. PIO/MMIO has this via PCI and it seems like any userspace device ought to be either a PCI device or use a static PIO port. Plus, paravirtual devices that use PCI/PIO/MMIO are much more likely to be reusable by other VMMs (Xen, QEMU, even VMware). In the future, if we decide a certain hypercall could be done better in userspace, and we have guests using those hypercalls, it makes sense to plumb the hypercalls down. My question is, should we support userspace hypercalls until that point? Regards, Anthony Liguori - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 1/3] Implement emulator_write_phys()
Since a hypercall may span two pages and is a gva, we need a function to write
to a gva that may span multiple pages. emulator_write_phys() seems like the
logical choice for this.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index d154487..ebcc5c9 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -962,8 +962,35 @@ static int emulator_write_std(unsigned long addr,
unsigned int bytes,
struct kvm_vcpu *vcpu)
{
- pr_unimpl(vcpu, "emulator_write_std: addr %lx n %d\n", addr, bytes);
- return X86EMUL_UNHANDLEABLE;
+ const void *data = val;
+
+ while (bytes) {
+ gpa_t gpa = vcpu->mmu.gva_to_gpa(vcpu, addr);
+ unsigned offset = addr & (PAGE_SIZE-1);
+ unsigned tocopy = min(bytes, (unsigned)PAGE_SIZE - offset);
+ unsigned long pfn;
+ struct page *page;
+ void *page_virt;
+
+ if (gpa == UNMAPPED_GVA)
+ return X86EMUL_PROPAGATE_FAULT;
+ pfn = gpa >> PAGE_SHIFT;
+ page = gfn_to_page(vcpu->kvm, pfn);
+ if (!page)
+ return X86EMUL_UNHANDLEABLE;
+ page_virt = kmap_atomic(page, KM_USER0);
+
+ memcpy(page_virt + offset, data, tocopy);
+
+ kunmap_atomic(page_virt, KM_USER0);
+ mark_page_dirty(vcpu->kvm, addr >> PAGE_SHIFT);
+
+ bytes -= tocopy;
+ data += tocopy;
+ addr += tocopy;
+ }
+
+ return X86EMUL_CONTINUE;
}
static struct kvm_io_device *vcpu_find_mmio_dev(struct kvm_vcpu *vcpu,
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 2/3] Refactor hypercall infrastructure
Anthony Liguori wrote:
> This patch refactors the current hypercall infrastructure to better support
> live
> migration and SMP. It eliminates the hypercall page by trapping the UD
> exception that would occur if you used the wrong hypercall instruction for the
> underlying architecture and replacing it with the right one lazily.
>
> It also introduces the infrastructure to probe for hypercall available via
> CPUID leaves 0x4002 and 0x4003.
>
> A fall-out of this patch is that the unhandled hypercalls no longer trap to
> userspace. There is very little reason though to use a hypercall to
> communicate
> with userspace as PIO or MMIO can be used. There is no code in tree that uses
> userspace hypercalls.
>
>
Allowing userspace to handle hypercalls means that we can have block and
net drivers in the kernel or userspace, reflecting user privileges and
performance/flxibility tradeoffs. I think that's an important feature
to have.
> void kvm_emulate_cpuid(struct kvm_vcpu *vcpu)
> {
> int i;
> @@ -1632,6 +1575,12 @@ void kvm_emulate_cpuid(struct kvm_vcpu *vcpu)
> vcpu->regs[VCPU_REGS_RBX] = 0;
> vcpu->regs[VCPU_REGS_RCX] = 0;
> vcpu->regs[VCPU_REGS_RDX] = 0;
> +
> + if ((function & 0x) == 0x4000) {
> + emulate_paravirt_cpuid(vcpu, function);
> + goto out;
> + }
> +
>
Hmm. Suppose we expose kvm capabilities to host userspace instead, and
let the host userspace decide which features to expose to the guest via
the regular cpuid emulation? That allows the qemu command line to
control the feature set.
>
> +static int ud_interception(struct vcpu_svm *svm, struct kvm_run *kvm_run)
> +{
> + int er;
> +
> + er = emulate_instruction(&svm->vcpu, kvm_run, 0, 0);
> +
> + /* we should only succeed here in the case of hypercalls which
> +cannot generate an MMIO event. MMIO means that the emulator
> +is mistakenly allowing an instruction that should generate
> +a UD fault so it's a bug. */
> + BUG_ON(er == EMULATE_DO_MMIO);
>
It's a guest-triggerable bug; one vcpu can be issuing ud2-in-a-loop
while the other replaces the instruction with something that does mmio.
> +
> +#define KVM_ENOSYS ENOSYS
>
A real number (well, an integer, not a real) here please. I know that
ENOSYS isn't going to change soon, but this file defines the kvm abi and
I'd like it to be as independent as possible.
Let's start it at 1000 so that spurious "return 1"s or "return -1"s
don't get translated into valid error numbers.
I really like the simplification to the guest/host interface that this
patch brings.
--
Any sufficiently difficult bug is indistinguishable from a feature.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Userspace hypercalls?
Anthony Liguori wrote: > I've never really thought much about them until now. What's the case > for supporting userspace hypercalls? > > The current way the code works is a little scary. Hypercalls that > aren't handled by kernelspace are deferred to userspace. Of course, > kernelspace has no idea whether userspace is actually using a given > hypercall so if kernelspace needs another one, the two may clash. > > AFAICT, the primary reason to use hypercalls is performance. A vmcall > is a few hundred cycles faster than a PIO exit. In the light-weight > exit path, this may make a significant different. However, when going > to userspace, it's not only a heavy-weight exit but it's also paying the > cost of a ring transition. The few hundred cycle savings is small in > comparison to the total cost so I don't think performance is a real > benefit here. > Actually the heavyweight exit is much more expensive than the ring transition. > The hypercall namespace is much smaller than the PIO namespace, and > there's no "plug-and-play" like mechanism to resolve conflict. PIO/MMIO > has this via PCI and it seems like any userspace device ought to be > either a PCI device or use a static PIO port. Plus, paravirtual devices > that use PCI/PIO/MMIO are much more likely to be reusable by other VMMs > (Xen, QEMU, even VMware). > > In the future, if we decide a certain hypercall could be done better in > userspace, and we have guests using those hypercalls, it makes sense to > plumb the hypercalls down. > > My question is, should we support userspace hypercalls until that point? > I've already mentioned this but I'll repeat it for google: allowing hypercalls to fallback to userspace gives you flexibility to have either a kernel implementation or a userspace implementation for the same functionality. This means a pvnet driver can be used either directly with a virtual interface on the host, or having some userspace processing in qemu. Similarly, pvblock can be processed in the kernel for real block devices, or in userspace for qcow format files, without the need to teach the kernel about the qcow format somehow. Dor's initial pv devices are implemented in qemu with a view to having a faster implementation in the kernel, so userspace hypercalls are on the table now. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Userspace hypercalls?
Avi Kivity wrote: > This means a pvnet driver can be used either directly > with a virtual interface on the host, or having some userspace > processing in qemu. Also, 'qmu -net user -net model=pv' if you're unlucky enough not to have root. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 2/3] Refactor hypercall infrastructure
This patch refactors the current hypercall infrastructure to better support live
migration and SMP. It eliminates the hypercall page by trapping the UD
exception that would occur if you used the wrong hypercall instruction for the
underlying architecture and replacing it with the right one lazily.
It also introduces the infrastructure to probe for hypercall available via
CPUID leaves 0x4002 and 0x4003.
A fall-out of this patch is that the unhandled hypercalls no longer trap to
userspace. There is very little reason though to use a hypercall to communicate
with userspace as PIO or MMIO can be used. There is no code in tree that uses
userspace hypercalls.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index a42a6f3..38c0eaf 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -46,6 +46,7 @@
#define KVM_MAX_CPUID_ENTRIES 40
#define DE_VECTOR 0
+#define UD_VECTOR 6
#define NM_VECTOR 7
#define DF_VECTOR 8
#define TS_VECTOR 10
@@ -316,9 +317,6 @@ struct kvm_vcpu {
unsigned long cr0;
unsigned long cr2;
unsigned long cr3;
- gpa_t para_state_gpa;
- struct page *para_state_page;
- gpa_t hypercall_gpa;
unsigned long cr4;
unsigned long cr8;
u64 pdptrs[4]; /* pae */
@@ -587,7 +585,9 @@ void __kvm_mmu_free_some_pages(struct kvm_vcpu *vcpu);
int kvm_mmu_load(struct kvm_vcpu *vcpu);
void kvm_mmu_unload(struct kvm_vcpu *vcpu);
-int kvm_hypercall(struct kvm_vcpu *vcpu, struct kvm_run *run);
+int kvm_emulate_hypercall(struct kvm_vcpu *vcpu);
+
+int kvm_fix_hypercall(struct kvm_vcpu *vcpu);
static inline int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t gva,
u32 error_code)
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index ebcc5c9..996d0ee 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -1294,51 +1294,49 @@ int kvm_emulate_halt(struct kvm_vcpu *vcpu)
}
EXPORT_SYMBOL_GPL(kvm_emulate_halt);
-int kvm_hypercall(struct kvm_vcpu *vcpu, struct kvm_run *run)
+int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
{
- unsigned long nr, a0, a1, a2, a3, a4, a5, ret;
+ unsigned long nr, a0, a1, a2, a3, ret;
kvm_arch_ops->cache_regs(vcpu);
- ret = -KVM_EINVAL;
-#ifdef CONFIG_X86_64
- if (is_long_mode(vcpu)) {
- nr = vcpu->regs[VCPU_REGS_RAX];
- a0 = vcpu->regs[VCPU_REGS_RDI];
- a1 = vcpu->regs[VCPU_REGS_RSI];
- a2 = vcpu->regs[VCPU_REGS_RDX];
- a3 = vcpu->regs[VCPU_REGS_RCX];
- a4 = vcpu->regs[VCPU_REGS_R8];
- a5 = vcpu->regs[VCPU_REGS_R9];
- } else
-#endif
- {
- nr = vcpu->regs[VCPU_REGS_RBX] & -1u;
- a0 = vcpu->regs[VCPU_REGS_RAX] & -1u;
- a1 = vcpu->regs[VCPU_REGS_RCX] & -1u;
- a2 = vcpu->regs[VCPU_REGS_RDX] & -1u;
- a3 = vcpu->regs[VCPU_REGS_RSI] & -1u;
- a4 = vcpu->regs[VCPU_REGS_RDI] & -1u;
- a5 = vcpu->regs[VCPU_REGS_RBP] & -1u;
+
+ nr = vcpu->regs[VCPU_REGS_RAX];
+ a0 = vcpu->regs[VCPU_REGS_RBX];
+ a1 = vcpu->regs[VCPU_REGS_RCX];
+ a2 = vcpu->regs[VCPU_REGS_RDX];
+ a3 = vcpu->regs[VCPU_REGS_RSI];
+
+ if (!is_long_mode(vcpu)) {
+ nr &= ~1u;
+ a0 &= ~1u;
+ a1 &= ~1u;
+ a2 &= ~1u;
+ a3 &= ~1u;
}
+
switch (nr) {
default:
- run->hypercall.nr = nr;
- run->hypercall.args[0] = a0;
- run->hypercall.args[1] = a1;
- run->hypercall.args[2] = a2;
- run->hypercall.args[3] = a3;
- run->hypercall.args[4] = a4;
- run->hypercall.args[5] = a5;
- run->hypercall.ret = ret;
- run->hypercall.longmode = is_long_mode(vcpu);
- kvm_arch_ops->decache_regs(vcpu);
- return 0;
+ ret = -KVM_ENOSYS;
+ break;
}
vcpu->regs[VCPU_REGS_RAX] = ret;
kvm_arch_ops->decache_regs(vcpu);
- return 1;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(kvm_emulate_hypercall);
+
+int kvm_fix_hypercall(struct kvm_vcpu *vcpu)
+{
+ char instruction[3];
+
+ kvm_arch_ops->cache_regs(vcpu);
+ kvm_arch_ops->patch_hypercall(vcpu, instruction);
+ if (emulator_write_std(vcpu->rip, instruction, 3, vcpu)
+ != X86EMUL_CONTINUE)
+ return -EFAULT;
+
+ return 0;
}
-EXPORT_SYMBOL_GPL(kvm_hypercall);
static u64 mk_cr_64(u64 curr_cr, u32 new_val)
{
@@ -1406,75 +1404,6 @@ void realmode_set_cr(struct kvm_vcpu *vcpu, int cr,
unsigned long val,
}
}
-/*
- * Register the para guest with the host:
- */
-static int vcpu_register_para(struct kvm_vcpu *vcpu, gpa_t para_state_gpa)
-{
- struct kvm_vcpu_para_state *para_state;
- hpa_t para_s
Re: [kvm-devel] [PATCH 1/3] Implement emulator_write_phys()
Anthony Liguori wrote: > Since a hypercall may span two pages and is a gva, we need a function to write > to a gva that may span multiple pages. emulator_write_phys() seems like the > logical choice for this. > > @@ -962,8 +962,35 @@ static int emulator_write_std(unsigned long addr, > unsigned int bytes, > struct kvm_vcpu *vcpu I think that emulator_write_emulated(), except for being awkwardly named, should do the job. We have enough APIs. But! We may not overwrite the hypercall instruction while a vcpu may be executing, since there's no atomicity guarantee for code fetch. We have to to be out of guest mode while writing that insn. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Userspace hypercalls?
Avi Kivity wrote: > Anthony Liguori wrote: >> I've never really thought much about them until now. What's the case >> for supporting userspace hypercalls? >> >> The current way the code works is a little scary. Hypercalls that >> aren't handled by kernelspace are deferred to userspace. Of course, >> kernelspace has no idea whether userspace is actually using a given >> hypercall so if kernelspace needs another one, the two may clash. >> >> AFAICT, the primary reason to use hypercalls is performance. A vmcall >> is a few hundred cycles faster than a PIO exit. In the light-weight >> exit path, this may make a significant different. However, when going >> to userspace, it's not only a heavy-weight exit but it's also paying the >> cost of a ring transition. The few hundred cycle savings is small in >> comparison to the total cost so I don't think performance is a real >> benefit here. >> > > Actually the heavyweight exit is much more expensive than the ring > transition. > >> The hypercall namespace is much smaller than the PIO namespace, and >> there's no "plug-and-play" like mechanism to resolve conflict. PIO/MMIO >> has this via PCI and it seems like any userspace device ought to be >> either a PCI device or use a static PIO port. Plus, paravirtual devices >> that use PCI/PIO/MMIO are much more likely to be reusable by other VMMs >> (Xen, QEMU, even VMware). >> >> In the future, if we decide a certain hypercall could be done better in >> userspace, and we have guests using those hypercalls, it makes sense to >> plumb the hypercalls down. >> >> My question is, should we support userspace hypercalls until that point? >> > > I've already mentioned this but I'll repeat it for google: allowing > hypercalls to fallback to userspace gives you flexibility to have > either a kernel implementation or a userspace implementation for the > same functionality. This means a pvnet driver can be used either > directly with a virtual interface on the host, or having some > userspace processing in qemu. Similarly, pvblock can be processed in > the kernel for real block devices, or in userspace for qcow format > files, without the need to teach the kernel about the qcow format > somehow. > > Dor's initial pv devices are implemented in qemu with a view to having > a faster implementation in the kernel, so userspace hypercalls are on > the table now. > Thinking a little more about this, it isn't about handling hypercalls in userspace, but about handling a virtio sync() in userspace. So how about having a KVM_HC_WAKE_CHANNEL hypercall (similar to Xen's event channel, but assymetric) that has a channel parameter. The kernel handler for that hypercall dispatches calls to either a kernel handler or a userspace handler. That means we don't need a separate ETH_SEND, ETH_RECEIVE, or BLOCK_SEND hypercalls. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Userspace hypercalls?
Avi Kivity wrote: > > Thinking a little more about this, it isn't about handling hypercalls > in userspace, but about handling a virtio sync() in userspace. > > So how about having a KVM_HC_WAKE_CHANNEL hypercall (similar to Xen's > event channel, but assymetric) that has a channel parameter. The > kernel handler for that hypercall dispatches calls to either a kernel > handler or a userspace handler. That means we don't need a separate > ETH_SEND, ETH_RECEIVE, or BLOCK_SEND hypercalls. And thinking a tiny little bit more about this, we can have the kernel (optionally) fire an eventfd, so a separate userspace thread or process can be woken up to service the device, without a heavyweight exit. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Vista 32 Premium 32 bit gets blue screen on boot
No problem, glad I can contribute to this wonderful project in any way I can. I've retested the bios images and below shows results. Please bear in mind that I only tested for successful boot and didn't complete the install. bios-kvm-35-3-g599a0fb.binblue screen bios-kvm-35-4-gb70bff2.binblue screen bios-kvm-35-5-g43e23df.binboots ok bios-kvm-35-6-gf989ba8.binboots ok bios-kvm-35-19-g8d8b9c4.binboots ok bios-kvm-35-22-ga718321.binboots ok bios-kvm-35-23-gcb98751.binboots ok bios-kvm-35-24-ga7b3e17.binblue screen bios-kvm-35-26-g1bc8d4a.binblue screen bios-kvm-35-33-g21ea5f8.binblue screen Regards Haydn On 8/27/07, Avi Kivity <[EMAIL PROTECTED]> wrote: > > Haydn Solomon wrote: > > Ok. I've tested the list of bios images for booting vista premium 32 > > bit. The results are as follows: > > > > Sorry, I regenerated the bios images incorrectly, so some of these > images are stale. Unfortunately, this includes the images at the > working->nonworking crossover. > > I've regenerated the images with a 'make clean' and a forced > recompilation of the ACPI tables (and eliminated some duplicates). Can > you retest? Location is the same at > http://people.qumranet.com/avi/bios-images. > > -- > Any sufficiently difficult bug is indistinguishable from a feature. > > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 3/3] KVM paravirt-ops implementation
diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig
index f952493..ceacc66 100644
--- a/arch/i386/Kconfig
+++ b/arch/i386/Kconfig
@@ -237,6 +237,13 @@ config VMI
at the moment), by linking the kernel to a GPL-ed ROM module
provided by the hypervisor.
+config KVM_GUEST
+ bool "KVM paravirt-ops support"
+ depends on PARAVIRT
+ help
+ This option enables various optimizations for running under the KVM
+ hypervisor.
+
config ACPI_SRAT
bool
default y
diff --git a/arch/i386/kernel/Makefile b/arch/i386/kernel/Makefile
index 9d33b00..6308fcf 100644
--- a/arch/i386/kernel/Makefile
+++ b/arch/i386/kernel/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_K8_NB) += k8.o
obj-$(CONFIG_MGEODE_LX)+= geode.o
obj-$(CONFIG_VMI) += vmi.o vmiclock.o
+obj-$(CONFIG_KVM_GUEST)+= kvm.o
obj-$(CONFIG_PARAVIRT) += paravirt.o
obj-y += pcspeaker.o
diff --git a/arch/i386/kernel/kvm.c b/arch/i386/kernel/kvm.c
new file mode 100644
index 000..26585a4
--- /dev/null
+++ b/arch/i386/kernel/kvm.c
@@ -0,0 +1,46 @@
+/*
+ * KVM paravirt_ops implementation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * Copyright IBM Corporation, 2007
+ * Authors: Anthony Liguori <[EMAIL PROTECTED]>
+ */
+
+#include
+#include
+
+/*
+ * No need for any "IO delay" on KVM
+ */
+static void kvm_io_delay(void)
+{
+}
+
+static __init void paravirt_setup(void)
+{
+ paravirt_ops.name = "KVM";
+
+ if (kvm_para_has_feature(KVM_PARA_FEATURE_NOP_IO_DELAY))
+ paravirt_ops.io_delay = kvm_io_delay;
+
+ paravirt_ops.paravirt_enabled = 1;
+}
+
+void __init kvm_guest_init(void)
+{
+ if (kvm_para_available())
+ paravirt_setup();
+}
diff --git a/include/linux/kvm_para.h b/include/linux/kvm_para.h
index e92ea3e..16e51a1 100644
--- a/include/linux/kvm_para.h
+++ b/include/linux/kvm_para.h
@@ -3,6 +3,14 @@
#include
+#ifdef CONFIG_KVM_GUEST
+void __init kvm_guest_init(void);
+#else
+static inline void kvm_guest_init(void)
+{
+}
+#endif
+
#define KVM_HYPERCALL ".byte 0x0f,0x01,0xc1"
static inline long kvm_hypercall0(unsigned int nr)
diff --git a/init/main.c b/init/main.c
index d3bcb3b..b224905 100644
--- a/init/main.c
+++ b/init/main.c
@@ -55,6 +55,7 @@
#include
#include
#include
+#include
#include
#include
@@ -569,6 +570,7 @@ asmlinkage void __init start_kernel(void)
}
sort_main_extable();
trap_init();
+ kvm_guest_init();
rcu_init();
init_IRQ();
pidhash_init();
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 0/3] KVM paravirtualization framework
This patchset refactors KVM's paravirtualization support to better support guest SMP and cross platform migration. It also introduces a bare-bones KVM paravirt_ops implementation. I've tested this on VT and it works nicely. I'm having trouble getting a bzImage to boot on SVM so I haven't been able to test on SVM yet. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 2/3] Refactor hypercall infrastructure
On Mon, 2007-08-27 at 19:06 +0300, Avi Kivity wrote:
> Anthony Liguori wrote:
> > void kvm_emulate_cpuid(struct kvm_vcpu *vcpu)
> > {
> > int i;
> > @@ -1632,6 +1575,12 @@ void kvm_emulate_cpuid(struct kvm_vcpu *vcpu)
> > vcpu->regs[VCPU_REGS_RBX] = 0;
> > vcpu->regs[VCPU_REGS_RCX] = 0;
> > vcpu->regs[VCPU_REGS_RDX] = 0;
> > +
> > + if ((function & 0x) == 0x4000) {
> > + emulate_paravirt_cpuid(vcpu, function);
> > + goto out;
> > + }
> > +
> >
>
> Hmm. Suppose we expose kvm capabilities to host userspace instead, and
> let the host userspace decide which features to expose to the guest via
> the regular cpuid emulation? That allows the qemu command line to
> control the feature set.
That's a little awkward with something like NPT. Some CPUID features
should be masked by the availability of NPT support in hardware and
whether kernelspace supports NPT. To set these feature bits in
userspace, you would have to query kernelspace anyway.
It would be nice to be consistent with the other cpuid flags though.
There is somewhat of a similar issue with migration here. If we have an
initial set of PV features and down the road, add more, it may be
desirable to enable those features depending on what your network looks
like. Yeah, I think I agree that userspace is the right place to set
these bits.
> >
> > +static int ud_interception(struct vcpu_svm *svm, struct kvm_run *kvm_run)
> > +{
> > + int er;
> > +
> > + er = emulate_instruction(&svm->vcpu, kvm_run, 0, 0);
> > +
> > + /* we should only succeed here in the case of hypercalls which
> > + cannot generate an MMIO event. MMIO means that the emulator
> > + is mistakenly allowing an instruction that should generate
> > + a UD fault so it's a bug. */
> > + BUG_ON(er == EMULATE_DO_MMIO);
> >
>
> It's a guest-triggerable bug; one vcpu can be issuing ud2-in-a-loop
> while the other replaces the instruction with something that does mmio.
Good catch! I'll update.
> > +
> > +#define KVM_ENOSYS ENOSYS
> >
>
> A real number (well, an integer, not a real) here please. I know that
> ENOSYS isn't going to change soon, but this file defines the kvm abi and
> I'd like it to be as independent as possible.
>
> Let's start it at 1000 so that spurious "return 1"s or "return -1"s
> don't get translated into valid error numbers.
Okay.
> I really like the simplification to the guest/host interface that this
> patch brings.
Thanks.
Regards,
Anthony Liguori
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/3] Implement emulator_write_phys()
Anthony Liguori wrote: > On Mon, 2007-08-27 at 18:45 +0300, Avi Kivity wrote: > >> Anthony Liguori wrote: >> >>> Since a hypercall may span two pages and is a gva, we need a function to >>> write >>> to a gva that may span multiple pages. emulator_write_phys() seems like the >>> logical choice for this. >>> >>> @@ -962,8 +962,35 @@ static int emulator_write_std(unsigned long addr, >>> unsigned int bytes, >>> struct kvm_vcpu *vcpu >>> >> I think that emulator_write_emulated(), except for being awkwardly >> named, should do the job. We have enough APIs. >> >> But! We may not overwrite the hypercall instruction while a vcpu may be >> executing, since there's no atomicity guarantee for code fetch. We have >> to to be out of guest mode while writing that insn. >> > > > Hrm, good catch. > > How can we get out of guest mode given SMP guest support? > > kvm_flush_remote_tlbs() is something that can be generalized. Basically, you set a bit in each vcpu and send an IPI to take them out. But that's deadlock prone and complex. Maybe you can just take kvm->lock, zap the mmu and the flush tlbs, and patch the instruction at your leisure, as no vcpu will be able to map memory until the lock is released. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Vista 32 Premium 32 bit gets blue screen on boot
Haydn Solomon wrote: > > bios-kvm-35-24-ga7b3e17.binblue screen Thanks. This is > commit a7b3e1705b99677365050aae6dc1da0279fc42a2 > Author: Igor Lvovsky <[EMAIL PROTECTED]> > Date: Sun Aug 19 15:00:12 2007 +0300 > > kvm: bios: update FACP revision to 2 > > Windows requires ACPI ref 1.0b, which in turn specifies FACP > revision 2. > Igor, any insight? -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Userspace hypercalls?
On Mon, 2007-08-27 at 19:47 +0300, Avi Kivity wrote: > Avi Kivity wrote: > > > > Thinking a little more about this, it isn't about handling hypercalls > > in userspace, but about handling a virtio sync() in userspace. > > > > So how about having a KVM_HC_WAKE_CHANNEL hypercall (similar to Xen's > > event channel, but assymetric) that has a channel parameter. The > > kernel handler for that hypercall dispatches calls to either a kernel > > handler or a userspace handler. That means we don't need a separate > > ETH_SEND, ETH_RECEIVE, or BLOCK_SEND hypercalls. > > And thinking a tiny little bit more about this, we can have the kernel > (optionally) fire an eventfd, so a separate userspace thread or process > can be woken up to service the device, without a heavyweight exit. Yes, I think this is much nicer. By "calls to ... a userspace handler" I presume you mean generating an exit to userspace with a new exit type similar to how hypercalls work today? Regards, Anthony Liguori - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Userspace hypercalls?
Anthony Liguori wrote: > On Mon, 2007-08-27 at 19:47 +0300, Avi Kivity wrote: > >> Avi Kivity wrote: >> >>> Thinking a little more about this, it isn't about handling hypercalls >>> in userspace, but about handling a virtio sync() in userspace. >>> >>> So how about having a KVM_HC_WAKE_CHANNEL hypercall (similar to Xen's >>> event channel, but assymetric) that has a channel parameter. The >>> kernel handler for that hypercall dispatches calls to either a kernel >>> handler or a userspace handler. That means we don't need a separate >>> ETH_SEND, ETH_RECEIVE, or BLOCK_SEND hypercalls. >>> >> And thinking a tiny little bit more about this, we can have the kernel >> (optionally) fire an eventfd, so a separate userspace thread or process >> can be woken up to service the device, without a heavyweight exit. >> > > > Yes, I think this is much nicer. By "calls to ... a userspace handler" > I presume you mean generating an exit to userspace with a new exit type > similar to how hypercalls work today? > > There are two options: - hypercall handler sets some fields in vcpu->run and exits to userspace - hypercall handler triggers an eventfd and returns to guest Maybe we can unify the two by only allowing eventfd; userspace can attach a signal to the eventfd if it wants a synchronous exit (does eventfd allow fcntl(F_SETOWN)?) -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/3] Implement emulator_write_phys()
On Mon, 2007-08-27 at 20:26 +0300, Avi Kivity wrote: > Anthony Liguori wrote: > > On Mon, 2007-08-27 at 18:45 +0300, Avi Kivity wrote: > > > >> Anthony Liguori wrote: > >> > >>> Since a hypercall may span two pages and is a gva, we need a function to > >>> write > >>> to a gva that may span multiple pages. emulator_write_phys() seems like > >>> the > >>> logical choice for this. > >>> > >>> @@ -962,8 +962,35 @@ static int emulator_write_std(unsigned long addr, > >>> unsigned int bytes, > >>> struct kvm_vcpu *vcpu > >>> > >> I think that emulator_write_emulated(), except for being awkwardly > >> named, should do the job. We have enough APIs. > >> > >> But! We may not overwrite the hypercall instruction while a vcpu may be > >> executing, since there's no atomicity guarantee for code fetch. We have > >> to to be out of guest mode while writing that insn. > >> > > > > > > Hrm, good catch. > > > > How can we get out of guest mode given SMP guest support? > > > > > > kvm_flush_remote_tlbs() is something that can be generalized. > Basically, you set a bit in each vcpu and send an IPI to take them out. > > But that's deadlock prone and complex. Maybe you can just take > kvm->lock, zap the mmu and the flush tlbs, and patch the instruction at > your leisure, as no vcpu will be able to map memory until the lock is > released. This works for shadow paging but not necessarily with NPT. Do code fetches really not respect atomic writes? We could switch to a 32-bit atomic operation and that should result in no worse than the code being patched twice. Regards, Anthony Liguori - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Userspace hypercalls?
On Mon, 2007-08-27 at 20:36 +0300, Avi Kivity wrote: > Anthony Liguori wrote: > > On Mon, 2007-08-27 at 19:47 +0300, Avi Kivity wrote: > > > >> Avi Kivity wrote: > >> > >>> Thinking a little more about this, it isn't about handling hypercalls > >>> in userspace, but about handling a virtio sync() in userspace. > >>> > >>> So how about having a KVM_HC_WAKE_CHANNEL hypercall (similar to Xen's > >>> event channel, but assymetric) that has a channel parameter. The > >>> kernel handler for that hypercall dispatches calls to either a kernel > >>> handler or a userspace handler. That means we don't need a separate > >>> ETH_SEND, ETH_RECEIVE, or BLOCK_SEND hypercalls. > >>> > >> And thinking a tiny little bit more about this, we can have the kernel > >> (optionally) fire an eventfd, so a separate userspace thread or process > >> can be woken up to service the device, without a heavyweight exit. > >> > > > > > > Yes, I think this is much nicer. By "calls to ... a userspace handler" > > I presume you mean generating an exit to userspace with a new exit type > > similar to how hypercalls work today? > > > > > > There are two options: > - hypercall handler sets some fields in vcpu->run and exits to userspace > - hypercall handler triggers an eventfd and returns to guest > > Maybe we can unify the two by only allowing eventfd; Yes, that would be better except that the latency may be unacceptable. > userspace can > attach a signal to the eventfd if it wants a synchronous exit (does > eventfd allow fcntl(F_SETOWN)?) Which would address the latency issue nicely. Looking at the fs code, it looks like eventfd shouldn't have to do anything special for it. Regards, Anthony Liguori > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 0/3] KVM paravirtualization framework
Anthony Liguori wrote: >I've tested this on VT and it works nicely. Excuse me, but you said several months ago something about "kvm-xen", which doesn't requires VT CPUs. Will you publish or merge that technology ? (as I don't have VT-capable CPU at Home) = Anyways, I'm very happy to hear about KVM adding paravirtualization to the portfolio. Now the features are close to Xen. Namely, Xen has: Linux host 32/64-bit Guests 32/64-bit Full Virtualization requires VT (Guests: any) Para-Virtualization works on any x86 processor (Guests: Linux) Host/Guest SMP KVM will also have all of above now, with your patch. But will it be able to work on non-VT CPUs ? -- -Alexey Eremenko "Technologov" - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/3] Implement emulator_write_phys()
Anthony Liguori wrote: > On Mon, 2007-08-27 at 20:26 +0300, Avi Kivity wrote: > >> Anthony Liguori wrote: >> >>> On Mon, 2007-08-27 at 18:45 +0300, Avi Kivity wrote: >>> >>> Anthony Liguori wrote: > Since a hypercall may span two pages and is a gva, we need a function to > write > to a gva that may span multiple pages. emulator_write_phys() seems like > the > logical choice for this. > > @@ -962,8 +962,35 @@ static int emulator_write_std(unsigned long addr, > unsigned int bytes, > struct kvm_vcpu *vcpu > > I think that emulator_write_emulated(), except for being awkwardly named, should do the job. We have enough APIs. But! We may not overwrite the hypercall instruction while a vcpu may be executing, since there's no atomicity guarantee for code fetch. We have to to be out of guest mode while writing that insn. >>> Hrm, good catch. >>> >>> How can we get out of guest mode given SMP guest support? >>> >>> >>> >> kvm_flush_remote_tlbs() is something that can be generalized. >> Basically, you set a bit in each vcpu and send an IPI to take them out. >> >> But that's deadlock prone and complex. Maybe you can just take >> kvm->lock, zap the mmu and the flush tlbs, and patch the instruction at >> your leisure, as no vcpu will be able to map memory until the lock is >> released. >> > > This works for shadow paging but not necessarily with NPT. NPT will have tlb and 2nd level pagetable flushing (to support memory unplug, ballooning, guest swapping, and the like) so it's safe to assume that it will continue to work. > Do code > fetches really not respect atomic writes? We could switch to a 32-bit > atomic operation and that should result in no worse than the code being > patched twice. > I think they don't respect it (the data cache and insn cache and fetch pipeline are very separated for performance reasons, so it's not unexpected). I think the Intel manual has some guidelines on self-modifying code. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Userspace hypercalls?
Anthony Liguori wrote: > On Mon, 2007-08-27 at 20:36 +0300, Avi Kivity wrote: > >> Anthony Liguori wrote: >> >>> On Mon, 2007-08-27 at 19:47 +0300, Avi Kivity wrote: >>> >>> Avi Kivity wrote: > Thinking a little more about this, it isn't about handling hypercalls > in userspace, but about handling a virtio sync() in userspace. > > So how about having a KVM_HC_WAKE_CHANNEL hypercall (similar to Xen's > event channel, but assymetric) that has a channel parameter. The > kernel handler for that hypercall dispatches calls to either a kernel > handler or a userspace handler. That means we don't need a separate > ETH_SEND, ETH_RECEIVE, or BLOCK_SEND hypercalls. > > And thinking a tiny little bit more about this, we can have the kernel (optionally) fire an eventfd, so a separate userspace thread or process can be woken up to service the device, without a heavyweight exit. >>> Yes, I think this is much nicer. By "calls to ... a userspace handler" >>> I presume you mean generating an exit to userspace with a new exit type >>> similar to how hypercalls work today? >>> >>> >>> >> There are two options: >> - hypercall handler sets some fields in vcpu->run and exits to userspace >> - hypercall handler triggers an eventfd and returns to guest >> >> Maybe we can unify the two by only allowing eventfd; >> > > Yes, that would be better except that the latency may be unacceptable. > > Hmm. Good point. I keep saying kvm can have great I/O because the scheduler is not involved in ordinary I/O. Let's not break that. >> userspace can >> attach a signal to the eventfd if it wants a synchronous exit (does >> eventfd allow fcntl(F_SETOWN)?) >> > > Which would address the latency issue nicely. Looking at the fs code, > it looks like eventfd shouldn't have to do anything special for it. > I'm not sure now. Which thread will be selected for accepting the signal? if it isn't guaranteed to be the current thread, we're back with scheduler involvement, and possibly cacheline bouncing. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Userspace hypercalls?
On Mon, 2007-08-27 at 20:51 +0300, Avi Kivity wrote: > Anthony Liguori wrote: > > On Mon, 2007-08-27 at 20:36 +0300, Avi Kivity wrote: > > > > Yes, that would be better except that the latency may be unacceptable. > > > > > > Hmm. Good point. I keep saying kvm can have great I/O because the > scheduler is not involved in ordinary I/O. Let's not break that. Most definitely! > >> userspace can > >> attach a signal to the eventfd if it wants a synchronous exit (does > >> eventfd allow fcntl(F_SETOWN)?) > >> > > > > Which would address the latency issue nicely. Looking at the fs code, > > it looks like eventfd shouldn't have to do anything special for it. > > > > I'm not sure now. Which thread will be selected for accepting the > signal? if it isn't guaranteed to be the current thread, we're back > with scheduler involvement, and possibly cacheline bouncing. I don't know enough about this in the kernel but I agree on principle, we need to be able to guarantee that the current thread receives the signal or we have to go back to doing an exit. Regards, Anthony Liguori - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/3] Implement emulator_write_phys()
On Mon, 2007-08-27 at 18:45 +0300, Avi Kivity wrote: > Anthony Liguori wrote: > > Since a hypercall may span two pages and is a gva, we need a function to > > write > > to a gva that may span multiple pages. emulator_write_phys() seems like the > > logical choice for this. > > > > @@ -962,8 +962,35 @@ static int emulator_write_std(unsigned long addr, > > unsigned int bytes, > > struct kvm_vcpu *vcpu > > I think that emulator_write_emulated(), except for being awkwardly > named, should do the job. We have enough APIs. I'll drop this patch. My mistakenly thought emulator_write_emulated() took a GPA. Thanks! Regards, Anthony Liguori > But! We may not overwrite the hypercall instruction while a vcpu may be > executing, since there's no atomicity guarantee for code fetch. We have > to to be out of guest mode while writing that insn. > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/3] Implement emulator_write_phys()
On Mon, 2007-08-27 at 18:45 +0300, Avi Kivity wrote: > Anthony Liguori wrote: > > Since a hypercall may span two pages and is a gva, we need a function to > > write > > to a gva that may span multiple pages. emulator_write_phys() seems like the > > logical choice for this. > > > > @@ -962,8 +962,35 @@ static int emulator_write_std(unsigned long addr, > > unsigned int bytes, > > struct kvm_vcpu *vcpu > > I think that emulator_write_emulated(), except for being awkwardly > named, should do the job. We have enough APIs. > > But! We may not overwrite the hypercall instruction while a vcpu may be > executing, since there's no atomicity guarantee for code fetch. We have > to to be out of guest mode while writing that insn. Hrm, good catch. How can we get out of guest mode given SMP guest support? Regards, Anthony Liguori > > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Hello Kvm-devel
Those who deny freedom to others, deserve it not for themselves. The happiest conversation is that of which nothing is distinctly remembered but a general effect of pleasing impression. Can anything be so elegant as to have few wants, and to serve them one's self? Love is a state in which a man sees things most decidedly as the are not. You have your way. I have my way. As for the right way, the correct way, and the only way, it does not exist. Everything in the world we want to do or get done, we must do with and through people. Time And health are two precious assets that we don't recognize and appreciate until they have been depleted. When you doubt, abstain. We cannot really love anybody with whom we never laugh. A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines. If football taught me anything about business, it is that you win the game one play at a time. The manner of their living is very barbarous, because they do not eat at fixed times, but as often as they please. There are three kinds of death in this world. There's heart death, there's brain death, and there's being off the network. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [BUG] kvm_lock: inconsistent lock state
Hi,
I just got this warning when doing a 'rmmod kvm-intel':
=
[ INFO: inconsistent lock state ]
2.6.23-rc3-libata-g28e8351a-dirty #93
-
inconsistent {hardirq-on-W} -> {in-hardirq-W} usage.
udevd/2800 [HC1[1]:SC0[0]:HE0:SE1] takes:
(kvm_lock){+-..}, at: [] hardware_disable+0x31/0xbc [kvm]
{hardirq-on-W} state was registered at:
[] __lock_acquire+0x487/0xbcc
[] debug_check_no_locks_freed+0x110/0x11a
[] __next_cpu+0x12/0x21
[] is_module_address+0x35/0x92
[] lock_acquire+0x68/0x80
[] kvm_dev_ioctl+0xb5/0x1c8 [kvm]
[] _spin_lock+0x36/0x5f
[] kvm_dev_ioctl+0xb5/0x1c8 [kvm]
[] kvm_dev_ioctl+0xb5/0x1c8 [kvm]
[] do_page_fault+0x30d/0x734
[] kvm_dev_ioctl+0x0/0x1c8 [kvm]
[] do_ioctl+0x1f/0x62
[] vfs_ioctl+0x237/0x249
[] trace_hardirqs_on+0x11a/0x13d
[] sys_ioctl+0x33/0x4d
[] syscall_call+0x7/0xb
[] 0x
irq event stamp: 682504
hardirqs last enabled at (682503): []
get_page_from_freelist+0x18c/0x35c
hardirqs last disabled at (682504): []
call_function_interrupt+0x29/0x38
softirqs last enabled at (679024): [] do_softirq+0x61/0xd1
softirqs last disabled at (679017): [] do_softirq+0x61/0xd1
other info that might help us debug this:
1 lock held by udevd/2800:
#0: (&inode->i_mutex){--..}, at: [] shmem_file_write+0x7e/0x2a6
stack backtrace:
[] print_usage_bug+0x138/0x142
[] mark_lock+0xae/0x44a
[] _spin_unlock+0x25/0x3b
[] __lock_acquire+0x416/0xbcc
[] lock_acquire+0x68/0x80
[] hardware_disable+0x31/0xbc [kvm]
[] _spin_lock+0x36/0x5f
[] hardware_disable+0x31/0xbc [kvm]
[] hardware_disable+0x0/0xbc [kvm]
[] hardware_disable+0x31/0xbc [kvm]
[] lock_release_holdtime+0x3d/0x4a
[] hardware_disable+0x0/0xbc [kvm]
[] smp_call_function_interrupt+0x37/0x52
[] call_function_interrupt+0x33/0x38
[] p4_rearm+0x4/0xf2c
[] get_page_from_freelist+0x295/0x35c
[] __alloc_pages+0x5f/0x295
[] put_lock_stats+0xa/0x1e
[] shmem_getpage+0x38c/0x59a
[] __mutex_lock_slowpath+0x290/0x298
[] shmem_file_write+0x12b/0x2a6
[] shmem_file_write+0x0/0x2a6
[] vfs_write+0x8a/0x10c
[] sys_write+0x41/0x67
[] syscall_call+0x7/0xb
===
(this is kvm-36, but the bug was there in previous versions too)
kvm_lock is taken in kvm_create_vm with interrupts enabled. Later - at
rmmod time - it's used in decache_vcpus_on_cpu (hardware_disable) with
interrupts disabled (due to on_each_cpu). In theory it should be
harmless since the refcount on /dev/kvm prevents the deadlock.
Switching to irq-safe spin_lock_* seems fine, do you want a patch?
Luca
--
"Vorrei morire ucciso dagli agi. Vorrei che di me si dicesse: ``Com'�
morto?'' ``Gli � scoppiato il portafogli''" -- Marcello Marchesi
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] 33高t级t文t秘t职t业t化t训t练33
高*级*文*秘*职*业*化*训*练 中 国 ・上 海・ 2007 年 09 月 8-9 日 中 国 ・北 京・ 2007 年 09 月 1-2 日 中 国 ・深 圳・ 2007 年 10 月 20-21 日 ━━━ ● 授 课 对 象 企业中层行政管理干部和文秘工作人员，包括办公室主任、行政部经理、董事长秘书、 总经理秘书、行政助理、行政主管、行政部门文员等 ⊙主 办单位：众 人 行 管 理 咨 询 ⊙培 训价格： 1 8 0 0元 / 人 深 圳 总 部 电 话：0755/260-75265 260-75429 260-75365 上 海 办 事 处 电 话：021/518-75149 北 京 办 事 处 电 话：010/512-93353 传 真： 0755-613-51396 联 系人：凌 小姐 曾 小姐 ● 背 景 对高级文秘来说，没有受到过系统训练，将无法从战略性全方位角度认知秘书与助理 的工作；在所从事的工作中感觉缺乏理论支持；工作中总是被动行事，不能主动掌握工作 节奏；想给公司节省费用，但却不知从何处下手，如何节省；行使对外界社会的管理职能 时没有感觉到有很多事物的“黑洞”…… 诸如以上的问题，都是每个文秘人员所面对与困惑的，如何把握正确方向从而迅速提 升自身职业素养，成了我们必须面对与解决的课题。 ● 课 程 收 获 → 掌握高级行政文秘所具备的基本技能、技巧 → 善于处理工作中的难点，掌握待人接物的技巧，实现有效的时间管理 → 实现现代文秘工作和档案管理工作的规范衔接 → 善于上传下达，掌握有效沟通的技巧 → 学习掌握规范的商务写作技巧，提高公文写作水平 → 学习掌握会议的组织思路及高效率的组织方法。 → 掌握基本的商务活动礼仪，使您适应日常商务场合的礼仪要求 → 掌握拜访客户的必备礼节，从细微之处体现您对他人的尊重 → 了解接待客户的礼仪细节，让您的每一位客人宾至如归 ━━━ 课 程 大 纲 一、企业行政文秘职业特性与素质要求 ◇ 文秘人员的职业价值和作用 → 案例：秘书岗位的评价 ◇ 企业文秘工作的基本特征 ◇ 文秘人员的职责与主要工作内容 → 案例：文秘人员的职位说明书样板 ◇ 文秘人员的自我角色定位 ◇ 优秀文秘人员的胜任素质 → 案例分析： ◇ 文秘的职业发展前景与实现路径 二、公文写作与处理实务 ◇ 公文分类 ◇ 公文的结构 ◇ 秘书文字支持应达到的要求 ◇ 公文写作基本要领 ◇ 13种常用公文模版 ◇ 常用公函 ◇ 请示与报告、批复的写作与范例 ◇ SMART原则与SWOT方法 ◇ 计划撰写注意事项 三、会务组织与管理 ◇ 会务分类－组织思路 ◇ 组织阶段：会前准备、会中协助、会后整理 ◇ 组织方法 ◇ 例会的组织 ◇ 大型会议、展会的组织 ◇ 如何担任会议主持人 ◇ 如何当好会议秘书？ ◇ 全景案例：某公司年度大型庆典活动策划始末 → 案例：大型会议及活动策划案 ◇ 如何避免陷于会议忙碌之中？ 四、文件资料管理与运用 ◇ 文档分类标准 ◇ 档案管理的原则 ◇ 文档的索引 ◇ 电子文档的保管 ◇ 名片系统管理 ◇ 印章的管理 → 研讨：如何利用档案为公司业务服务？ 五、信息档案管理 ◇ 信息管理基本流程 ◇ 信息的收集整理 ◇ 信息的传递 ◇ 信息的储存与保密 ◇ 保密意识与保密规则 ◇ 秘书的基本职业道德 六、人际沟通与工作协调技巧 ◇ 沟通对于秘书的意义 ◇ 秘书常用沟通方式之比较 ◇ 秘书人员的沟通技巧 → 案例：如何听懂老板的“没有说出来的意思”？ ◇ 秘书让领导刮目相看、获得信任？ ◇ 如何与你的上司协调而不帮倒忙？ ◇ 秘书人员如何与各种上司相处？ ◇ 问题：我的上级调走了怎么办？ → 案例：领导让我难为情，我该怎么办？ → 案例：如何与同事或下级相处？ → 案例：有人在你面前抱怨你的领导该怎么办？ ◇ 讨论：秘书应当如何发挥自身优势起好协调作用？ 七、办公室5S及办公用品管理 ◇ 整理、整顿、清扫、清洁、修养 ◇ 文件处理流程化 ◇ 办公用品申购、领用 ◇ 维护各类办公设备的正常使用 八、时间管理及工作统筹技巧 ◇ 时间管理的误区 ◇ 时间管理的原则 √目标管理与80/20法则 √缓急轻重的优先管理 √个人时间与领导工作时间计划与安排 ◇ 秘书时间管理小窍门 ◇ 宾客接待与电话处理 ◇ 自我情绪控制与压力管理 九、访客接待 ◇ 接待客人流程 ◇ 接待重要客户的注意事项 ◇ 来访电话对策 → 案例分析一、二、三 十、如何成为上司得力助手 ◇ 优秀秘书的核心竞争力 ◇ 知己知彼：分析上司的特点 ◇ 如何对待不同类型的上司 ◇ 站在下级的位置上思考上级的事 ◇ 与上级相处三大注意事项 ◇ 上司的行程安排 十一、商务礼仪与职业形象塑造 1、个人形象塑造及礼仪 ◇ 着装的TPO原则 ◇ 女士着装的要点 ◇ 男士着装的规范 ◇ 仪容礼仪规范 ◇ 化妆的礼仪 ◇ 站、坐、行的礼仪规范 ◇ 恰当的肢体语言 2、 基本社交礼仪 ◇ 见面介绍的礼仪 ◇ 问候的礼仪 ◇ 名片的使用 ◇ 日常商务活动中的礼仪规范 ◇ 与工作有关的文体活动中的礼仪规范 3、 商务宴请礼仪 ◇ 中餐礼仪 ◇ 西餐礼仪 ◇ 自助餐礼仪 ◇ 餐饮礼仪禁忌 4、 电话礼仪 ◇ 接听电话的基本原则 ◇ 接听电话的几项注意 ◇ 拨打电话的几大要点 ━━━ 讲 师 介 绍：李 革 增 深圳管理咨询行业协会成员；深圳外商投资协会讲师、香港光华管理学院客座教授； 十多年从事企业管理与咨询工作的经验，在德隆集团、深高速、深南招商集团等大型集团 公司及管理顾问公司历任市场经理、行政总监、培训总监等职位。对沟通技巧、客户服务、 行政统筹、企业文化等方面具有良好的培训与辅导经验；具有深厚的理论知识与丰富的实 践操作能力；注重对企业实际问题的分析和解决、讲求实效性和适用性。 擅长课程：《职业经理人资格认证》、《领导力训练》、《企业中层管理技能培训》 《时间管理》、《目标管理》、《企业文化》、《沟通技巧》、《高级文秘职业素质修 养》等。 培训特色：以互动、情景式培训见长，注重受训人员的感悟及参与，通过各种实际 案例及管理游戏等方式充分调动参训人员的培训热情。 曾培训或咨询过的企业有：中国电信、青岛中化集团、中石油、桑菲通讯、华侨城 集团、奥林巴斯、金碟软件（中国）有限公司、厦门航空、苏州三星电子、广东移动通 信、蛇口南顺面粉、深南招商集团、深高速、深圳中汽租赁有限公司、深圳恒波通讯、 深圳华展国际、三洋机电等。 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 2/3] KVM paravirt-ops implementation (v2)
A very simple paravirt_ops implementation for KVM. Future patches will add
more sophisticated optimizations. The goal of having this presenting this now
is to validate the new hypercall infrastructure and to make my patch queue
smaller.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig
index f952493..ceacc66 100644
--- a/arch/i386/Kconfig
+++ b/arch/i386/Kconfig
@@ -237,6 +237,13 @@ config VMI
at the moment), by linking the kernel to a GPL-ed ROM module
provided by the hypervisor.
+config KVM_GUEST
+ bool "KVM paravirt-ops support"
+ depends on PARAVIRT
+ help
+ This option enables various optimizations for running under the KVM
+ hypervisor.
+
config ACPI_SRAT
bool
default y
diff --git a/arch/i386/kernel/Makefile b/arch/i386/kernel/Makefile
index 9d33b00..6308fcf 100644
--- a/arch/i386/kernel/Makefile
+++ b/arch/i386/kernel/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_K8_NB) += k8.o
obj-$(CONFIG_MGEODE_LX)+= geode.o
obj-$(CONFIG_VMI) += vmi.o vmiclock.o
+obj-$(CONFIG_KVM_GUEST)+= kvm.o
obj-$(CONFIG_PARAVIRT) += paravirt.o
obj-y += pcspeaker.o
diff --git a/arch/i386/kernel/kvm.c b/arch/i386/kernel/kvm.c
new file mode 100644
index 000..26585a4
--- /dev/null
+++ b/arch/i386/kernel/kvm.c
@@ -0,0 +1,46 @@
+/*
+ * KVM paravirt_ops implementation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * Copyright IBM Corporation, 2007
+ * Authors: Anthony Liguori <[EMAIL PROTECTED]>
+ */
+
+#include
+#include
+
+/*
+ * No need for any "IO delay" on KVM
+ */
+static void kvm_io_delay(void)
+{
+}
+
+static __init void paravirt_setup(void)
+{
+ paravirt_ops.name = "KVM";
+
+ if (kvm_para_has_feature(KVM_PARA_FEATURE_NOP_IO_DELAY))
+ paravirt_ops.io_delay = kvm_io_delay;
+
+ paravirt_ops.paravirt_enabled = 1;
+}
+
+void __init kvm_guest_init(void)
+{
+ if (kvm_para_available())
+ paravirt_setup();
+}
diff --git a/include/linux/kvm_para.h b/include/linux/kvm_para.h
index 0f94138..10b2e7a 100644
--- a/include/linux/kvm_para.h
+++ b/include/linux/kvm_para.h
@@ -4,6 +4,14 @@
#ifdef __KERNEL__
#include
+#ifdef CONFIG_KVM_GUEST
+void __init kvm_guest_init(void);
+#else
+static inline void kvm_guest_init(void)
+{
+}
+#endif
+
#define KVM_HYPERCALL ".byte 0x0f,0x01,0xc1"
static inline long kvm_hypercall0(unsigned int nr)
diff --git a/init/main.c b/init/main.c
index d3bcb3b..b224905 100644
--- a/init/main.c
+++ b/init/main.c
@@ -55,6 +55,7 @@
#include
#include
#include
+#include
#include
#include
@@ -569,6 +570,7 @@ asmlinkage void __init start_kernel(void)
}
sort_main_extable();
trap_init();
+ kvm_guest_init();
rcu_init();
init_IRQ();
pidhash_init();
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 0/3] KVM paravirtualization framework (v2)
This patchset refactors KVM's paravirtualization support to better support guest SMP and cross platform migration. It also introduces a bare-bones KVM paravirt_ops implementation. I've tested this on VT and it works nicely. I'm having trouble getting a bzImage to boot on SVM so I haven't been able to test on SVM yet. I've incorporated all of the feedback into this series from posting the last series. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 1/3] Refactor hypercall infrastructure (v2)
This patch refactors the current hypercall infrastructure to better support live
migration and SMP. It eliminates the hypercall page by trapping the UD
exception that would occur if you used the wrong hypercall instruction for the
underlying architecture and replacing it with the right one lazily.
It also introduces the infrastructure to probe for hypercall available via
CPUID leaves 0x4002. CPUID leaf 0x4003 should be filled out by
userspace.
A fall-out of this patch is that the unhandled hypercalls no longer trap to
userspace. There is very little reason though to use a hypercall to communicate
with userspace as PIO or MMIO can be used. There is no code in tree that uses
userspace hypercalls.
Since v1, we now use emulator_write_emulated() and zap the MMU while holding
kvm->lock to ensure atomicity on SMP. We also switch the KVM errnos to be
integer based and make kvm_para.h #include-able from userspace.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index a42a6f3..38c0eaf 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -46,6 +46,7 @@
#define KVM_MAX_CPUID_ENTRIES 40
#define DE_VECTOR 0
+#define UD_VECTOR 6
#define NM_VECTOR 7
#define DF_VECTOR 8
#define TS_VECTOR 10
@@ -316,9 +317,6 @@ struct kvm_vcpu {
unsigned long cr0;
unsigned long cr2;
unsigned long cr3;
- gpa_t para_state_gpa;
- struct page *para_state_page;
- gpa_t hypercall_gpa;
unsigned long cr4;
unsigned long cr8;
u64 pdptrs[4]; /* pae */
@@ -587,7 +585,9 @@ void __kvm_mmu_free_some_pages(struct kvm_vcpu *vcpu);
int kvm_mmu_load(struct kvm_vcpu *vcpu);
void kvm_mmu_unload(struct kvm_vcpu *vcpu);
-int kvm_hypercall(struct kvm_vcpu *vcpu, struct kvm_run *run);
+int kvm_emulate_hypercall(struct kvm_vcpu *vcpu);
+
+int kvm_fix_hypercall(struct kvm_vcpu *vcpu);
static inline int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t gva,
u32 error_code)
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index d154487..177cba1 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -1267,51 +1267,61 @@ int kvm_emulate_halt(struct kvm_vcpu *vcpu)
}
EXPORT_SYMBOL_GPL(kvm_emulate_halt);
-int kvm_hypercall(struct kvm_vcpu *vcpu, struct kvm_run *run)
+int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
{
- unsigned long nr, a0, a1, a2, a3, a4, a5, ret;
+ unsigned long nr, a0, a1, a2, a3, ret;
kvm_arch_ops->cache_regs(vcpu);
- ret = -KVM_EINVAL;
-#ifdef CONFIG_X86_64
- if (is_long_mode(vcpu)) {
- nr = vcpu->regs[VCPU_REGS_RAX];
- a0 = vcpu->regs[VCPU_REGS_RDI];
- a1 = vcpu->regs[VCPU_REGS_RSI];
- a2 = vcpu->regs[VCPU_REGS_RDX];
- a3 = vcpu->regs[VCPU_REGS_RCX];
- a4 = vcpu->regs[VCPU_REGS_R8];
- a5 = vcpu->regs[VCPU_REGS_R9];
- } else
-#endif
- {
- nr = vcpu->regs[VCPU_REGS_RBX] & -1u;
- a0 = vcpu->regs[VCPU_REGS_RAX] & -1u;
- a1 = vcpu->regs[VCPU_REGS_RCX] & -1u;
- a2 = vcpu->regs[VCPU_REGS_RDX] & -1u;
- a3 = vcpu->regs[VCPU_REGS_RSI] & -1u;
- a4 = vcpu->regs[VCPU_REGS_RDI] & -1u;
- a5 = vcpu->regs[VCPU_REGS_RBP] & -1u;
+
+ nr = vcpu->regs[VCPU_REGS_RAX];
+ a0 = vcpu->regs[VCPU_REGS_RBX];
+ a1 = vcpu->regs[VCPU_REGS_RCX];
+ a2 = vcpu->regs[VCPU_REGS_RDX];
+ a3 = vcpu->regs[VCPU_REGS_RSI];
+
+ if (!is_long_mode(vcpu)) {
+ nr &= ~1u;
+ a0 &= ~1u;
+ a1 &= ~1u;
+ a2 &= ~1u;
+ a3 &= ~1u;
}
+
switch (nr) {
default:
- run->hypercall.nr = nr;
- run->hypercall.args[0] = a0;
- run->hypercall.args[1] = a1;
- run->hypercall.args[2] = a2;
- run->hypercall.args[3] = a3;
- run->hypercall.args[4] = a4;
- run->hypercall.args[5] = a5;
- run->hypercall.ret = ret;
- run->hypercall.longmode = is_long_mode(vcpu);
- kvm_arch_ops->decache_regs(vcpu);
- return 0;
+ ret = -KVM_ENOSYS;
+ break;
}
vcpu->regs[VCPU_REGS_RAX] = ret;
kvm_arch_ops->decache_regs(vcpu);
- return 1;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(kvm_emulate_hypercall);
+
+int kvm_fix_hypercall(struct kvm_vcpu *vcpu)
+{
+ char instruction[3];
+ int ret = 0;
+
+ mutex_lock(&vcpu->kvm->lock);
+
+ /*
+* Blow out the MMU to ensure that no other VCPU has an active mapping
+* to ensure that the updated hypercall appears atomically across all
+* VCPUs.
+*/
+ kvm_mmu_zap_all(vcpu->kvm);
+
+ kvm_arch_ops->cache_regs(vcpu);
+ kvm_arch_ops->patch_hypercall(vcpu, instr
[kvm-devel] [PATCH 3/3] Add the paravirtualization CPUID entry to QEMU (v2)
This adds a CPUID entry for the paravirtualization feature bitmap. We can do
this unconditionally because the guest requires that both the feature CPUID
entry and the signature CPUID entry exists to enable paravirtualization.
This means that guest will never enable paravirtualization if either userspace
or kernelspace doesn't support paravirtualization.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index 491c32c..1c93388 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -1103,12 +1103,18 @@ static void do_cpuid_ent(struct kvm_cpuid_entry *e,
uint32_t function,
int kvm_qemu_init_env(CPUState *cenv)
{
struct kvm_cpuid_entry cpuid_ent[100];
+struct kvm_cpuid_entry *pv_features;
int cpuid_nent = 0;
CPUState copy;
uint32_t i, limit;
copy = *cenv;
+pv_features = &cpuid_ent[cpuid_nent++];
+memset(pv_features, 0, sizeof(*pv_features));
+pv_features->function = 0x4003;
+pv_features->eax = (1 << KVM_PARA_FEATURE_NOP_IO_DELAY);
+
copy.regs[R_EAX] = 0;
qemu_kvm_cpuid_on_env(©);
limit = copy.regs[R_EAX];
diff --git a/user/kvmctl.h b/user/kvmctl.h
index ff0bca6..16b4e28 100644
--- a/user/kvmctl.h
+++ b/user/kvmctl.h
@@ -10,6 +10,7 @@
#endif
#include
+#include
#include
#include
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/3] Add the paravirtualization CPUID entry to QEMU (v2)
Anthony Liguori wrote:
> This adds a CPUID entry for the paravirtualization feature bitmap. We can do
> this unconditionally because the guest requires that both the feature CPUID
> entry and the signature CPUID entry exists to enable paravirtualization.
>
> This means that guest will never enable paravirtualization if either userspace
> or kernelspace doesn't support paravirtualization.
>
> Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
>
> diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
> index 491c32c..1c93388 100644
> --- a/qemu/qemu-kvm.c
> +++ b/qemu/qemu-kvm.c
> @@ -1103,12 +1103,18 @@ static void do_cpuid_ent(struct kvm_cpuid_entry *e,
> uint32_t function,
> int kvm_qemu_init_env(CPUState *cenv)
> {
> struct kvm_cpuid_entry cpuid_ent[100];
> +struct kvm_cpuid_entry *pv_features;
> int cpuid_nent = 0;
> CPUState copy;
> uint32_t i, limit;
>
> copy = *cenv;
>
> +pv_features = &cpuid_ent[cpuid_nent++];
> +memset(pv_features, 0, sizeof(*pv_features));
> +pv_features->function = 0x4003;
> +pv_features->eax = (1 << KVM_PARA_FEATURE_NOP_IO_DELAY);
> +
> copy.regs[R_EAX] = 0;
> qemu_kvm_cpuid_on_env(©);
> limit = copy.regs[R_EAX];
>
Shouldn't we query kvm here to see if the feature is needed?
I imagine I/O delay is never needed unless we passthrough a device,
which this qemu doesn't support, but it would be nice to set a good
example for the future.
--
Any sufficiently difficult bug is indistinguishable from a feature.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Userspace hypercalls?
On 8/27/07, Avi Kivity <[EMAIL PROTECTED]> wrote: > Anthony Liguori wrote: > > On Mon, 2007-08-27 at 20:36 +0300, Avi Kivity wrote: > >> userspace can > >> attach a signal to the eventfd if it wants a synchronous exit (does > >> eventfd allow fcntl(F_SETOWN)?) > > > > Which would address the latency issue nicely. Looking at the fs code, > > it looks like eventfd shouldn't have to do anything special for it. > > I'm not sure now. Which thread will be selected for accepting the > signal? It's not specified. > if it isn't guaranteed to be the current thread, we're back > with scheduler involvement, and possibly cacheline bouncing. It's possible to use pthread_sigmask() to block the signal on all threads but one. But this would require changing the rest of the emulator; why not just select() the fd in a dedicated thread? Luca - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Userspace hypercalls?
Luca wrote: > On 8/27/07, Avi Kivity <[EMAIL PROTECTED]> wrote: > >> Anthony Liguori wrote: >> >>> On Mon, 2007-08-27 at 20:36 +0300, Avi Kivity wrote: >>> userspace can attach a signal to the eventfd if it wants a synchronous exit (does eventfd allow fcntl(F_SETOWN)?) >>> Which would address the latency issue nicely. Looking at the fs code, >>> it looks like eventfd shouldn't have to do anything special for it. >>> >> I'm not sure now. Which thread will be selected for accepting the >> signal? >> > > It's not specified. > > So that option's down. >> if it isn't guaranteed to be the current thread, we're back >> with scheduler involvement, and possibly cacheline bouncing. >> > > It's possible to use pthread_sigmask() to block the signal on all > threads but one. But this would require changing the rest of the > emulator; why not just select() the fd in a dedicated thread? > When the guest issues that hypercall, it really wants the I/O to start. If it's a separate thread, the scheduler could choose to let the guest execute and keep the I/O thread waiting (CFS isn't likely to do that, but it's possible). The scheduler could also choose to run the I/O thread on a different processor, and now all the data structures carefully loaded into cache by the guest need to be bounced to the processor running the I/O thread. I think the best policy here is to cover our asses and allow userspace to choose which method it wants to use; and we should start with the guest exiting to userspace to avoid the costs I mentioned. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/3] Add the paravirtualization CPUID entry to QEMU (v2)
On Mon, 2007-08-27 at 22:54 +0300, Avi Kivity wrote:
> Anthony Liguori wrote:
> > This adds a CPUID entry for the paravirtualization feature bitmap. We can
> > do
> > this unconditionally because the guest requires that both the feature CPUID
> > entry and the signature CPUID entry exists to enable paravirtualization.
> >
> > This means that guest will never enable paravirtualization if either
> > userspace
> > or kernelspace doesn't support paravirtualization.
> >
> > Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
> >
> > diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
> > index 491c32c..1c93388 100644
> > --- a/qemu/qemu-kvm.c
> > +++ b/qemu/qemu-kvm.c
> > @@ -1103,12 +1103,18 @@ static void do_cpuid_ent(struct kvm_cpuid_entry *e,
> > uint32_t function,
> > int kvm_qemu_init_env(CPUState *cenv)
> > {
> > struct kvm_cpuid_entry cpuid_ent[100];
> > +struct kvm_cpuid_entry *pv_features;
> > int cpuid_nent = 0;
> > CPUState copy;
> > uint32_t i, limit;
> >
> > copy = *cenv;
> >
> > +pv_features = &cpuid_ent[cpuid_nent++];
> > +memset(pv_features, 0, sizeof(*pv_features));
> > +pv_features->function = 0x4003;
> > +pv_features->eax = (1 << KVM_PARA_FEATURE_NOP_IO_DELAY);
> > +
> > copy.regs[R_EAX] = 0;
> > qemu_kvm_cpuid_on_env(©);
> > limit = copy.regs[R_EAX];
> >
>
> Shouldn't we query kvm here to see if the feature is needed?
I don't think so. At the moment, PIO goes to QEMU so QEMU is really the
only one that should be making that decision.
> I imagine I/O delay is never needed unless we passthrough a device,
> which this qemu doesn't support, but it would be nice to set a good
> example for the future.
In this particular case, it would be a bad example since the kernel
isn't the one that ought to be making the decision. I suspect PCI
pass-through should be initiated in QEMU anyway so it still will be the
one making the decision.
However, if you apply these patches before my flight levels tomorrow, I
can send out the MMU optimization patches that include a proper example
of how to query kernel-space ;-)
Regards,
Anthony Liguori
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Userspace hypercalls?
On Mon, 2007-08-27 at 23:01 +0300, Avi Kivity wrote: > Luca wrote: > >> if it isn't guaranteed to be the current thread, we're back > >> with scheduler involvement, and possibly cacheline bouncing. > >> > > > > It's possible to use pthread_sigmask() to block the signal on all > > threads but one. But this would require changing the rest of the > > emulator; why not just select() the fd in a dedicated thread? > > > > When the guest issues that hypercall, it really wants the I/O to start. > If it's a separate thread, the scheduler could choose to let the guest > execute and keep the I/O thread waiting (CFS isn't likely to do that, > but it's possible). > > The scheduler could also choose to run the I/O thread on a different > processor, and now all the data structures carefully loaded into cache > by the guest need to be bounced to the processor running the I/O thread. > > I think the best policy here is to cover our asses and allow userspace > to choose which method it wants to use; and we should start with the > guest exiting to userspace to avoid the costs I mentioned. I agree that we should start with an exit and then later add an eventfd mechanism if it is needed. Regards, Anthony Liguori - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Linux guests failing on SVM
Using the KVM git tree on a 32-bit host, I can't boot a kernel with -kernel. a wrmsr() to EFER is resulting in the guest getting a GP. The very curious thing is the call is wrmsr_safe() so I don't think it should be failing. Moreover, if I allow wrmsr to succeed, the guest just hangs. I know the efer MSR stuff changed recently, anyone have any thought on what's wrong? I'll start bisecting if noone has any ideas. Regards, Anthony Liguori - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/4] [HYPERCALL] Add hypercalls functions
On Fri, 2007-08-24 at 16:57 -0700, Dor Laor wrote:
> The hypercalls can be called with various parameters number.
> Both x86_64 and i386 are supported.
>
> Signed-off-by: Dor Laor <[EMAIL PROTECTED]>
> ---
> +static inline int
> +__hypercall6(unsigned int nr, unsigned long p1, unsigned long p2,
> + unsigned long p3, unsigned long p4, unsigned long p5,
> + unsigned long p6)
> +{
> + int ret;
> + asm (" call hypercall_addr\n"
> + : "=a" (ret)
> + : "b" (nr),
> + "a" (p1),
> + "c" (p2),
> + "d" (p3),
> + "S" (p4),
> + "D" (p5),
> + "bp" (p6)
> + : "memory", "cc"
> + );
> + return ret;
> +}
> +
> +#define hypercall(nr_params, args...)\
> +({ \
> + /* __ret is volatile to make sure call to this \
> + * function isn't optimized away by gcc. Just \
> + * having the __hypercallN() functions mention \
> + * memory is clobbered isn't enough \
> + */ \
> + volatile int __ret; \
> + \
> + __ret = __hypercall##nr_params(args); \
> + \
> + __ret; \
> +})
A couple things are different in my patchset. I didn't do this
hypercall macro. I tried it at first but IMHO it was pretty ugly. It
makes things less readable to me. The second thing is I only have up to
4 parameters to a hypercall. That leaves some GP registers on 32-bit
and Xen seems to be happily using 4 registers so I don't think there's
anything we can't express without the extra 2.
Regards,
Anthony Liguori
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/4] HYPERCALL] Update exit reason for vmcall
On Fri, 2007-08-24 at 16:58 -0700, Dor Laor wrote:
> diff --git a/drivers/kvm/svm.c b/drivers/kvm/svm.c
> index cc674bf..9bfd11e 100644
> --- a/drivers/kvm/svm.c
> +++ b/drivers/kvm/svm.c
> @@ -1022,6 +1022,11 @@ static int halt_interception(struct vcpu_svm
> *svm, struct kvm_run *kvm_run)
>
> static int vmmcall_interception(struct vcpu_svm *svm, struct kvm_run
> *kvm_run)
> {
> + if (svm->vmcb->save.cpl != 0) {
> + inject_ud(&svm->vcpu);
> + return 1;
> + }
> +
> svm->next_rip = svm->vmcb->save.rip + 3;
> skip_emulated_instruction(&svm->vcpu);
> return kvm_hypercall(&svm->vcpu, kvm_run);
Can you split this out and submit the patch separately. This is
actually a pretty nasty bug as SVM doesn't check for CPL=0 in hardware.
This patch is independent of your series.
Regards,
Anthony Liguori
> -
> In simplicity there is elegance.
> Dor Laor ;)
>
>
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> ___
> kvm-devel mailing list
> kvm-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/4] Hypercall additions
FWIW, I don't see 2/4 of this series. Regards, Anthony Liguori On Fri, 2007-08-24 at 16:56 -0700, Dor Laor wrote: > The following patch set add some hypercall functionality: > - Improve/ease userspace hypercall handling > - Add hypercall functions for x86_64 and i386. > - Add registration mechanism so KVM kernel modules (additional to > what we have today) can register hypercall handlers. > > The motivation is to allow PV drivers in KVM. The host side of these > drivers > will be optionaly in userspace or the kernel. I intend to implement > both. > > - > In simplicity there is elegance. > Dor Laor ;) > > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 2/4] [HYPERCALL] Enable userspace too include kvm_para.
Ignore my last email about this patch not existing :-)
Regards,
Anthony Liguori
On Fri, 2007-08-24 at 16:58 -0700, Dor Laor wrote:
> Since some hypercalls can be handled in userspace, it needs
> to include kvm_para too. Chande kernel types into user and
> add includes for them and for page_size.
>
> Signed-off-by: Dor Laor <[EMAIL PROTECTED]>
> ---
> include/linux/kvm_para.h | 13 -
> 1 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/kvm_para.h b/include/linux/kvm_para.h
> index 3b29256..754e29d 100644
> --- a/include/linux/kvm_para.h
> +++ b/include/linux/kvm_para.h
> @@ -8,6 +8,9 @@
> * as we make progress.
> */
>
> +#include
> +#include
> +
> /*
> * Per-VCPU descriptor area shared between guest and host. Writable to
> * both guest and host. Registered with the host by the guest when
> @@ -25,17 +28,17 @@ struct kvm_vcpu_para_state {
>* is supposed to work - new host versions will support all old
>* guest API versions.
>*/
> - u32 guest_version;
> - u32 host_version;
> - u32 size;
> - u32 ret;
> + __u32 guest_version;
> + __u32 host_version;
> + __u32 size;
> + __u32 ret;
>
> /*
>* The address of the vm exit instruction (VMCALL or VMMCALL),
>* which the host will patch according to the CPU model the
>* VM runs on:
>*/
> - u64 hypercall_gpa;
> + __u64 hypercall_gpa;
>
> } __attribute__ ((aligned(PAGE_SIZE)));
>
>
> -
> In simplicity there is elegance.
> Dor Laor ;)
>
>
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> ___
> kvm-devel mailing list
> kvm-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 4/4] [Hypercall] Allow modules registeration for hypercalls.
I don't really like the idea of having other modules register
hypercalls. The hypercall address space is fixed and should be
maintained by KVM.
I think things like virtio are rare and important enough, that it
warrants having kvm.ko know enough about them to provide a higher level
registration mechanism. The virtio network driver should register the
fact that it's a virtio device, not which hypercalls it cares about.
I'm not sure you gain anything by doing the virtio infrastructure in a
module either. If anything, a config option in kvm.ko would suffice.
Regards,
Anthony Liguori
On Fri, 2007-08-24 at 16:59 -0700, Dor Laor wrote:
> New kernel modules for KVM are upcoming soon, these module
> will need to use hypercalls. Before calling the hypercall function,
> the kvm_main core module has to make sure it won't get unloaded.
> So hypercall register/unregister are added.
>
> Except that the kernel hypercalls handlers are numberes
> 0-KVM_NR_HYPERCALLS.
> All the userspace handlers are above KVM_NR_HYPERCALLS.
>
> Signed-off-by: Dor Laor <[EMAIL PROTECTED]>
> ---
> drivers/kvm/kvm.h|9 ++
> drivers/kvm/kvm_main.c | 223
> ++
> include/linux/kvm_para.h |4 +-
> 3 files changed, 197 insertions(+), 39 deletions(-)
> mode change 100644 => 100755 drivers/kvm/kvm_main.c
>
> diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
> index a42a6f3..37240cf 100644
> --- a/drivers/kvm/kvm.h
> +++ b/drivers/kvm/kvm.h
> @@ -472,6 +472,12 @@ struct kvm_arch_ops {
> unsigned char *hypercall_addr);
> };
>
> +struct kvm_hypercall {
> + unsigned long (*hypercall)(struct kvm_vcpu*, unsigned long
> args[]);
> + struct module *module;
> + int idx;
> +};
> +
> extern struct kvm_arch_ops *kvm_arch_ops;
>
> /* The guest did something we don't support. */
> @@ -588,6 +594,9 @@ int kvm_mmu_load(struct kvm_vcpu *vcpu);
> void kvm_mmu_unload(struct kvm_vcpu *vcpu);
>
> int kvm_hypercall(struct kvm_vcpu *vcpu, struct kvm_run *run);
> +int kvm_register_hypercall(struct module *module, struct kvm_hypercall
> *hypercall);
> +int kvm_unregister_hypercall(struct kvm_hypercall *hypercall);
> +
>
> static inline int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t gva,
>u32 error_code)
> diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
> old mode 100644
> new mode 100755
> index abd7498..051b47a
> --- a/drivers/kvm/kvm_main.c
> +++ b/drivers/kvm/kvm_main.c
> @@ -20,6 +20,7 @@
> #include "segment_descriptor.h"
>
> #include
> +#include
> #include
> #include
> #include
> @@ -84,6 +85,23 @@ static struct kvm_stats_debugfs_item {
>
> static struct dentry *debugfs_dir;
>
> +static struct kvm_hypercall hypercalls[KVM_KERNEL_NR_HYPERCALLS];
> +
> +static int test_hypercall(struct kvm_vcpu *vcpu, unsigned long args[])
> +{
> + printk(KERN_DEBUG "%s: hypercall invoked\n", __FUNCTION__);
> +
> + return 0;
> +}
> +
> +static struct kvm_hypercall __hypercall_test = {
> + (unsigned long (*)(struct kvm_vcpu*, unsigned long
> args[]))test_hypercall,
> + THIS_MODULE,
> + __NR_hypercall_test,
> +};
> +
> +static atomic_t dev_kvm_open_count = ATOMIC_INIT(0);
> +
> #define MAX_IO_MSRS 256
>
> #define CR0_RESERVED_BITS
> \
> @@ -302,6 +320,24 @@ static struct kvm *kvm_create_vm(void)
> return kvm;
> }
>
> +static int kvm_dev_open(struct inode *inode, struct file *filp)
> +{
> + int ret = 0;
> +
> + if (atomic_inc_return(&dev_kvm_open_count) == 1) {
> + ret = kvm_register_hypercall(THIS_MODULE,
> &__hypercall_test);
> + if (ret < 0) {
> + printk(KERN_DEBUG "%s: kvm_register_hypercall
> error, "
> +"hypercall: %s\n",
> +__FUNCTION__, "test");
> + goto out_test;
> + }
> + }
> +
> +out_test:
> + return ret;
> +}
> +
> /*
> * Free any memory in @free but not in @dont.
> */
> @@ -371,6 +407,20 @@ static void kvm_free_vcpus(struct kvm *kvm)
>
> }
>
> +static int kvm_dev_release(struct inode *inode, struct file *filp)
> +{
> + int ret = 0;
> +
> + atomic_dec(&dev_kvm_open_count);
> + ret = kvm_unregister_hypercall(&__hypercall_test);
> + if (ret < 0) {
> + printk(KERN_DEBUG "%s:kvm_unregister_hypercall error "
> +"hypercall: %s\n", __FUNCTION__,
> "hypercall_test");
> + }
> +
> + return ret;
> +}
> +
> static void kvm_destroy_vm(struct kvm *kvm)
> {
> spin_lock(&kvm_lock);
> @@ -1267,50 +1317,145 @@ int kvm_emulate_halt(struct kvm_vcpu *vcpu)
> }
> EXPORT_SYMBOL_GPL(kvm_emulate_halt);
>
> -int kvm_hypercall(struct kvm_vcpu *vcpu, struct kvm_run *run)
> +int kvm_register_hypercall(struct module* module, struct kvm_hypercall
> *hypercall)
> {
> - unsigned long nr, a0, a1, a2, a3, a4, a5, ret;
> + int r = 0;
>
> - kvm_a
Re: [kvm-devel] Userspace hypercalls?
(Responding from the beach ;) I've already done a good portion of what is being discussed here in my pvio series. Please review it and give me your feedback. For instance, you will see the single hypercall passing the channel id down. -Original Message- From: Avi Kivity <[EMAIL PROTECTED]> Cc: kvm-devel <[EMAIL PROTECTED]> To: Anthony Liguori <[EMAIL PROTECTED]> Sent: 8/27/2007 10:47:22 AM Subject: Re: [kvm-devel] Userspace hypercalls? Avi Kivity wrote: > > Thinking a little more about this, it isn't about handling hypercalls > in userspace, but about handling a virtio sync() in userspace. > > So how about having a KVM_HC_WAKE_CHANNEL hypercall (similar to Xen's > event channel, but assymetric) that has a channel parameter. The > kernel handler for that hypercall dispatches calls to either a kernel > handler or a userspace handler. That means we don't need a separate > ETH_SEND, ETH_RECEIVE, or BLOCK_SEND hypercalls. And thinking a tiny little bit more about this, we can have the kernel (optionally) fire an eventfd, so a separate userspace thread or process can be woken up to service the device, without a heavyweight exit. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Linux guests failing on SVM
Anthony Liguori wrote: > Using the KVM git tree on a 32-bit host, I can't boot a kernel with > -kernel. a wrmsr() to EFER is resulting in the guest getting a GP. The > very curious thing is the call is wrmsr_safe() so I don't think it > should be failing. Moreover, if I allow wrmsr to succeed, the guest > just hangs. > > I know the efer MSR stuff changed recently, anyone have any thought on > what's wrong? > > EFER isn't supported on 32-bits. > I'll start bisecting if noone has any ideas. > My bet is on the switch to qemu-system-x86_64 for i386 hosts. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
