On Wed, 2007-05-16 at 14:10 -0500, Anthony Liguori wrote:
> For the host, you can probably stay entirely within QEMU. Interguest
> communication would be a bit tricky but guest->host communication is
> real simple.
guest->host is always simple. But it'd be great if it didn't matter to
the gues
Hello,
I have the same problem with Linux which is using isolinux,
such as Ubuntu. I checked the BIOS in the latest KVM and
I found that it seemed to be missing the following change.
http://bochs.cvs.sourceforge.net/bochs/bochs/bios/rombios.c?view=log#rev1.172
I can boot isolinux on the latest
Hi Avi,
I was playing with KVM while booting SuSE Linux 10.1 on it. And I found
it was bailing out with #SS fault. I root caused it to the address size
override opcode (0x67) from a mov instruction from the boot loader.
The attached patch handles the #SS(0) fault with emulation, letting
guest ca
On Wed, 16 May 2007, Avi Kivity wrote:
> IMO doing eventfd_fget() asap is best. I much prefer refcounted pointers to
> handles in the kernel: it's easier to see what things point to, and there is
> to context needed for dereferencing.
There are concerns (from Al and Christoph) about file lifetim
On 5/16/07, Anthony Liguori <[EMAIL PROTECTED]> wrote:
> Eric Van Hensbergen wrote:
> >
> > From a functional standpoint I don't have a huge problem with it,
> > particularly if its more of a pure socket and not something that tries
> > to look like a TCP/IP endpoint -- I would prefer something clo
Gregory Haskins wrote:
On Wed, May 16, 2007 at 2:39 PM, in message <[EMAIL PROTECTED]>,
> Anthony Liguori <[EMAIL PROTECTED]> wrote:
>
>> Gregory Haskins wrote:
>>
>> On Wed, May 16, 2007 at 1:28 PM, in message <[EMAIL PROTECTED]>,
>>
>>
>>> On Wed, May 16, 2007 at 2:39 PM, in message <[EMAIL PROTECTED]>,
Anthony Liguori <[EMAIL PROTECTED]> wrote:
> Gregory Haskins wrote:
> On Wed, May 16, 2007 at 1:28 PM, in message <[EMAIL PROTECTED]>,
>
>> Anthony Liguori <[EMAIL PROTECTED]> wrote:
>>
>>> What do you thin
Hi,
I'm using a somewhat "old" kernel with KVM (KVM included in the kernel).
I think it may be KVM-17 or something like that. Anyway, I got an OOPS
in the module while attempting to install Windows Server 2003 Standard
Edition 32-bit.
I just started it with
kvm -no-acpi -cdrom w2k3.iso w2k3.img
An updated specification (Rev 1.0 update) of Intel(r) virtualization
technology for Directed I/O is now available on Intel web site:
http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Di
rect_IO.pdf
The specification update includes DMA remapping capability, Interrupt
remappi
Eric Van Hensbergen wrote:
> On 5/16/07, Anthony Liguori <[EMAIL PROTECTED]> wrote:
>>
>> What do you think about a socket interface? I'm not sure how discovery
>> would work yet, but there are a few PV socket implementations for Xen at
>> the moment.
>>
>
> From a functional standpoint I don't ha
Gregory Haskins wrote:
On Wed, May 16, 2007 at 1:28 PM, in message <[EMAIL PROTECTED]>,
> Anthony Liguori <[EMAIL PROTECTED]> wrote:
>
>> What do you think about a socket interface? I'm not sure how discovery
>> would work yet, but there are a few PV socket implementations
>>> On Wed, May 16, 2007 at 1:28 PM, in message <[EMAIL PROTECTED]>,
Anthony Liguori <[EMAIL PROTECTED]> wrote:
>
> What do you think about a socket interface? I'm not sure how discovery
> would work yet, but there are a few PV socket implementations for Xen at
> the moment.
FYI: The work I
On 5/16/07, Anthony Liguori <[EMAIL PROTECTED]> wrote:
>
> What do you think about a socket interface? I'm not sure how discovery
> would work yet, but there are a few PV socket implementations for Xen at
> the moment.
>
>From a functional standpoint I don't have a huge problem with it,
particula
On Wed, May 16, 2007 at 12:28:00PM -0500, Anthony Liguori wrote:
> Eric Van Hensbergen wrote:
> > On 5/11/07, Anthony Liguori <[EMAIL PROTECTED]> wrote:
> >>
> >> There's definitely a conversation to have here. There are going to be a
> >> lot of small devices that would benefit from a common tran
Eric Van Hensbergen wrote:
> On 5/11/07, Anthony Liguori <[EMAIL PROTECTED]> wrote:
>>
>> There's definitely a conversation to have here. There are going to be a
>> lot of small devices that would benefit from a common transport
>> mechanism. Someone mentioned a PV entropy device on LKML. A
>> h
Dong, Eddie wrote:
> Avi Kivity wrote:
>
>> This looks nicer, however I get an oops on fxrstor in
>> kvm_load_guest_fpu(), when running user/test/vmexit.flat compiled for
>> i386, on an x86_64 host.
>>
>>
> Avi:
> Per your guideline, I did following under kvm-userspace/user:
>
Avi Kivity wrote:
> Gregory Haskins wrote:
>>> As of May 1st I could boot 64 bit SLED. As of yesterday, it
>>> exceptions immediately in the bootloader. This happens both with
>>> and without my APIC patches applied.
>>>
>>> Any idea of what checkin was the cause? At least,
Avi Kivity wrote:
>
> This looks nicer, however I get an oops on fxrstor in
> kvm_load_guest_fpu(), when running user/test/vmexit.flat compiled for
> i386, on an x86_64 host.
>
Avi:
Per your guideline, I did following under kvm-userspace/user:
1: make test/bootstrap
2: ma
On Wed, 16 May 2007 15:51:27 +0200,
Carsten Otte <[EMAIL PROTECTED]> wrote:
> +static int priv_chsc(struct zlcpu *cpu)
> +{
> +
> + debug("cpu %d: channel subsystem call at %lx", cpu->cpuno,
> cl_get_psw(cpu).addr);
> + setcc(cpu, 3);
Actually, while this works for a Linux guest, this is
Gregory Haskins wrote:
>>> diff -- git a/qemu/qemu- kvm.c b/qemu/qemu- kvm.c
>>> index 59e79bf..6096f21 100644
>>> --- a/qemu/qemu- kvm.c
>>> +++ b/qemu/qemu- kvm.c
>>> @@ - 697,6 +697,25 @@ int kvm_qemu_init()
>>> int kvm_qemu_create_context(void)
>>> {
>>> int i;
>>> +uint64_t ext;
>>
Subject: [PATCH/RFC 3/5] s390 zlive diagnose functions
From: Carsten Otte <[EMAIL PROTECTED]>
From: Christian Borntraeger <[EMAIL PROTECTED]>
This patch contains everything related to our diagnose instruction
o infrastructure for handling diagnose codes
o handlers for basic diagnoses, which are n
Subject: [PATCH/RFC 2/5] s390 zlive privileged instructions
From: Carsten Otte <[EMAIL PROTECTED]>
From: Christian Borntraeger <[EMAIL PROTECTED]>
This patch adds two things to the base code:
o infrastructure for handling priviledged operations
o handlers for basic priv ops, which are necessary t
Subject: [PATCH/RFC 5/5] s390 zlive device drivers
From: Carsten Otte <[EMAIL PROTECTED]>
From: Christian Borntraeger <[EMAIL PROTECTED]>
From: Martin Peschke <[EMAIL PROTECTED]>
This patch contains the userland parts that connect to the set of paravirtual
device drivers posted last week
o zlick
Subject: [PATCH/RFC 4/5] s390 zlive service processor calls
From: Carsten Otte <[EMAIL PROTECTED]>
From: Martin Peschke <[EMAIL PROTECTED]>
This patch adds support for calls to our service processor
o infrastructure that handles sclp calls
o infrastructure for sclp events
o sclp handlers
This is
Subject: [PATCH/RFC 0/5] s390 zlive
This set of patches contains our prototype userspace called zlive. We've used
this for initial development starting in 2005. This code tree is doomed to die
in months to come, as various code in here will head towards our kernel module
and kvm/qemu userspace. I
>>> On Wed, May 16, 2007 at 7:51 AM, in message <[EMAIL PROTECTED]>,
Avi Kivity <[EMAIL PROTECTED]> wrote:
> Gregory Haskins wrote:
>> @@ - 1045,7 +1054,7 @@ static CPUWriteMemoryFunc *ioapic_mem_write[3] = {
>> ioapic_mem_writel,
>> };
>>
>> - IOAPICState *ioapic_init(void)
>> +IOAPICSta
>>> On Wed, May 16, 2007 at 7:47 AM, in message <[EMAIL PROTECTED]>,
Avi Kivity <[EMAIL PROTECTED]> wrote:
> Gregory Haskins wrote:
>> Newer userspace may run on an older kernel. Therefore we need a way to
>> check the capabilities of the kernel so that we can downgrade userspace
>> dynamically
Gregory Haskins wrote:
On Wed, May 16, 2007 at 6:05 AM, in message <[EMAIL PROTECTED]>,
> Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>> Gregory Haskins wrote:
>>
>>>
>>>
Later we'll have vcpu and thread_info point to each other and then you
can do that
>>> On Wed, May 16, 2007 at 6:05 AM, in message <[EMAIL PROTECTED]>,
Avi Kivity <[EMAIL PROTECTED]> wrote:
> Gregory Haskins wrote:
>>
>>> Later we'll have vcpu and thread_info point to each other and then you
>>> can do that kind of optimization.
>>>
>>
>> I am not familiar with thread_i
Gregory Haskins wrote:
> Changelog:
>
> 1) Incorporated Anthony's feedback regarding the missed use_kernel_apic()
> 2) Added a new patch to allow new userspace on old kernels
>
>
All good.
--
error compiling committee.c: too many arguments to function
--
Davide Libenzi wrote:
> On Tue, 15 May 2007, Christoph Hellwig wrote:
>
>
>> On Tue, May 15, 2007 at 12:18:17PM -0400, Gregory Haskins wrote:
>>
>> On Tue, May 15, 2007 at 11:40 AM, in message
>>
>>> <[EMAIL PROTECTED]>, Davide Libenzi
>>> <[EMAIL PROTECTED]> wrote:
>>
Anthony Liguori wrote:
> Gregory Haskins wrote:
>
>>> While KVM will inevitably start requiring newer kernel versions, do we
>>> really need to do it right now? Perhaps we could add dummy eventfd_*
>>> functions to the module compat header? Then at least older kernels will
>>> continue to w
Gregory Haskins wrote:
> @@ -1045,7 +1054,7 @@ static CPUWriteMemoryFunc *ioapic_mem_write[3] = {
> ioapic_mem_writel,
> };
>
> -IOAPICState *ioapic_init(void)
> +IOAPICState *ioapic_init(CPUState *env)
> {
> IOAPICState *s;
> int io_memory;
> @@ -1054,6 +1063,7 @@ IOAPICState *i
Gregory Haskins wrote:
> Newer userspace may run on an older kernel. Therefore we need a way to
> check the capabilities of the kernel so that we can downgrade userspace
> dynamically if necessary
>
> Signed-off-by: Gregory Haskins <[EMAIL PROTECTED]>
> ---
>
> qemu/qemu-kvm.c | 19 +++
Davide Libenzi wrote:
> On Tue, 15 May 2007, Gregory Haskins wrote:
>
>
> On Tue, May 15, 2007 at 3:45 AM, in message <[EMAIL PROTECTED]>,
>
>> Avi Kivity <[EMAIL PROTECTED]> wrote:
>>
>>> Gregory Haskins wrote:
>>>
Signed- off- by: Gregory Haskins <[EMAIL P
Gregory Haskins wrote:
On Tue, May 15, 2007 at 3:45 AM, in message <[EMAIL PROTECTED]>,
> Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>> Gregory Haskins wrote:
>>
>>> Signed- off- by: Gregory Haskins <[EMAIL PROTECTED]>
>>> ---
>>>
>>> drivers/kvm/kvm.h |1 +
>>>
Gregory Haskins wrote:
>
>> Later we'll have vcpu and thread_info point to each other and then you
>> can do that kind of optimization.
>>
>
> I am not familiar with thread_info, but if it solves the dangling pointer
> problem, that sounds great.
It's fairly tricky, but it's the right way
Carsten Otte wrote:
>
>>> System call latency adds to the in-kernel approach here.
>> I don't understand this.
> What I meant to state was: If the host side of the block driver runs
> in userspace, we have the extra latency to leave the kernel system
> call context, compute on behalf of the user
Dong, Eddie wrote:
> Alternative to swaping host/guest MSR entry array to avoid MSR bitmap.
> More suggestions?
>
This looks nicer, however I get an oops on fxrstor in
kvm_load_guest_fpu(), when running user/test/vmexit.flat compiled for
i386, on an x86_64 host.
Additionally:
- please includ
39 matches
Mail list logo
