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, t
(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 PROT
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 me
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
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 mecha
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)
>
> s
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,
>
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 th
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
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 ena
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)?
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 laten
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
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 us
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.
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 ab
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 --
高*级*文*秘*职*业*化*训*练
中 国 ・上 海・ 2007 年 09 月 8-9 日
中 国 ・北 京・ 2007 年 09 月 1-2 日
中 国 ・深 圳・ 2007 年 10 月 20-21 日
━━━
● 授 课 对 象
企业中层行政管理干部和文秘工作人员，包括办公室主任、行政部经理、董事长秘书、
总经理秘书、行政助理、行政主管、行政部门文员等
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:
(k
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
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
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
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 th
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 hand
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
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)
=
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 virti
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 sp
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_CHA
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
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
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 c
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] =
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 ab
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
+ b
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.bin
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. Th
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
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,
>
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.
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 indistinguishabl
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 id
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 repla
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
inde
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 u
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
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 defin
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 gre
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
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
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 wo
51 matches
Mail list logo
