On Tue, 2007-07-17 at 23:49 -0700, Dor Laor wrote:
> >On Tue, 2007-07-17 at 06:31 -0700, Dor Laor wrote:
> >> btw: Rusty - what do you think of virtio for the host?
> >
> >You mean backend? For networking it makes a great deal of sense. For
> >block it makes far less sense (COW, weird formats, et
KVM has independent definitions of these structures, which is bad.
However, the currently (i386-derived) x86-64 ones are suboptimal. The
first step is to clean them up, especially by making desc_struct a
union.
Additional changes:
1) s/ldttss_desc/ldttss_desc_64/ to clearly indicate it's x86-64 o
Remove i386's Xgt_desc_struct definition and use desc_def.h's desc_ptr.
The offsets in asm-offsets.c do not seem to be used anywhere, so I
simply removed them.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r 0b03f449c0b3 arch/i386/kernel/asm-offsets.c
--- a/arch/i386/kernel/asm-offsets.
The main effect is to change the definition of "struct desc_struct" to
a union of more complex types.
I kept the old 32-bit comparisons, but many could be changed to use
the 64-bit "desc->raw".
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r 656f3ff2c9ce arch/i386/kernel/cpu/common.c
--
On Sat, Jul 14, 2007 at 07:06:18PM +0200, Aurelien Jarno wrote:
> Hi,
>
> I have just updated my system from kvm 28 to kvm 29, and a GNU/kFreeBSD
> amd64 system fails to boot with the following error:
>
> Fatal trap 12 with interrupts disabled
>
>
> Fatal trap 12: page fault while in kernel
Rusty Russell wrote:
> You mean backend? For networking it makes a great deal of sense. For
> block it makes far less sense (COW, weird formats, etc).
For block you probably want both: userspace driver which can handle all
sorts of funny image files, and a kernel driver doing a 1:1 mapping to a
Dong, Eddie wrote:
> This patch is to wrap APIC base register and CR8 operation which can
> provide a unique API for user level irqchip and kernel irqchip.
> This is a preparation of merging lapic/ioapic patch.
>
>
Applied and pushed, thanks.
--
Do not meddle in the internals of kernels, for
Rusty Russell wrote:
> On Tue, 2007-07-17 at 23:49 -0700, Dor Laor wrote:
>
>>> On Tue, 2007-07-17 at 06:31 -0700, Dor Laor wrote:
>>>
btw: Rusty - what do you think of virtio for the host?
>>> You mean backend? For networking it makes a great deal of sense. For
>>> b
Dong, Eddie wrote:
> Avi:
> This is the cleaned and branch check-in ready candidate patch
> for lapic based on previous cr8 patch.
> It needs the later ioapic patch to fully function.
>
>
Applied. It misses a description and sign-off line. I invented a
description, but please supp
On Wed, Jul 18, 2007 at 05:22:34PM +1000, Rusty Russell wrote:
> However, the currently (i386-derived) x86-64 ones are suboptimal. The
In what way are they suboptimal?
They seem to work just fine.
-Andi
-
This SF.net ema
Dong, Eddie wrote:
> Missed attachment. Here it is.
>
Applied & pushed, thanks.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
This SF.net email is sponsored by DB2 Express
Down
Dong, Eddie wrote:
> Avi:
> This is the cleaned and branch check-in ready candidate patch
> for lapic based on previous cr8 patch.
> It needs the later ioapic patch to fully function.
>
>
Most of userspace part is missing.
--
Do not meddle in the internals of kernels, for they are
Dong, Eddie wrote:
> Missed attachment. Here it is.
>
The userspace part doesn't apply, it needs the missing lapic userspace
patch.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
Rusty Russell wrote:
> On Tue, 2007-07-17 at 16:25 +0300, Avi Kivity wrote:
>
>> Rusty Russell wrote:
>>
>>> Creating one's own BITMAP macro seems suboptimal: if we use manual
>>> arithmetic in the one place exposed to userspace, we can use standard
>>> macros elsewhere.
>>>
>>> The - 7 + 8
Dong, Eddie wrote:
> Rebased hlt emulation for in kernel APIC/PIC/IOAPIC base on Greg's
> original V09.
>
>
>
Applied the kernel side. Please resend the missing user side patchset.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
--
Rusty Russell wrote:
> On Tue, 2007-07-17 at 18:35 +0200, Arnd Bergmann wrote:
>
>> On Tuesday 17 July 2007, Rusty Russell wrote:
>>
>>> KVM interface is no longer experimental.
>>>
>>> Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
>>>
>>> diff -r 4e57f5c6d4a9 include/linux/kvm.h
>>> ---
Arnd Bergmann wrote:
> The equivalent of the current set of ioctls comes down to roughtly this
> set of syscalls:
>
> int kvm_create_vm(void);
> int kvm_get_msr_index_list(int fd, sttuct kvm_msr_list);
> size_t kvm_get_vcpu_mmap_size(int fd);
> int kvm_set_memory_region(int fd, unsigned slot, unsig
Hi;
18 Tem 2007 Çar tarihinde, Anthony Liguori şunları yazmıştı:
> Can you reproduce without the appArmor patchset?
If needed http://cekirdek.pardus.org.tr/~caglar/kvm/netconsole is the appArmor
patchset included kernel's output captured with netconsole and yes i'll try
to reproduce same with
S.Çağlar Onur wrote:
> Hi;
>
> 18 Tem 2007 Çar tarihinde, Anthony Liguori şunları yazmıştı:
>
>> Can you reproduce without the appArmor patchset?
>>
>
> If needed http://cekirdek.pardus.org.tr/~caglar/kvm/netconsole is the
> appArmor
> patchset included kernel's output captured with netc
Avi Kivity wrote:
> Dong, Eddie wrote:
>> Avi:
>> This is the cleaned and branch check-in ready candidate patch
>> for lapic based on previous cr8 patch.
>> It needs the later ioapic patch to fully function.
>>
>>
>
> Most of userspace part is missing.
>
??? I don't need the user side
Dong, Eddie wrote:
> Avi Kivity wrote:
>
>> Dong, Eddie wrote:
>>
>>> Avi:
>>> This is the cleaned and branch check-in ready candidate patch
>>> for lapic based on previous cr8 patch.
>>> It needs the later ioapic patch to fully function.
>>>
>>>
>>>
>> Most of userspace part
> Well, the ioapic userspace patch removes some nonexistent code that I
> assume the lapic userspace patch should have added.
>
O, this is a temp hack added by in kernel PIC. Maybe the branch
mismatch.
Here is the resent one. The sequence is:
lapic
ioapic
hlt
thx,eddie
Gentlepeople,
We're currently working on PCI device pass-through support for KVM. In this
model all physical hardware access to specific devices will be performed by
the VM, and not by the host.
In particular, this requires interrupt handling to be done by the guest --
The host shouldn't load the
Hi;
18 Tem 2007 Çar tarihinde, Avi Kivity şunları yazmıştı:
> S.Çağlar Onur wrote:
> > Hi;
> >
> > 18 Tem 2007 Çar tarihinde, Anthony Liguori şunları yazmıştı:
> >> Can you reproduce without the appArmor patchset?
> >
> > If needed http://cekirdek.pardus.org.tr/~caglar/kvm/netconsole is the
> > a
Hi;
18 Tem 2007 Çar tarihinde, S.Çağlar Onur şunları yazmıştı:
> http://cekirdek.pardus.org.tr/~caglar/kvm/netconsole_wo_apparmor is the
> vanilla one's netconsole output, by the way without apparmor patchset
> system not hard freezes.
Ahhh netconsole cannot grab whole output, full log from kern
Jeff Dike wrote:
> On Tue, Jul 17, 2007 at 11:12:53AM +0300, Avi Kivity wrote:
>
>> I believe that emulate_instruction will set run->mmio if it returns
>> EMULATE_DO_MMIO.
>>
>
> Righto, forgot to check that. How about this patch instead?
>
> Set exit_reason to KVM_EXIT_MMIO where run->mm
Hi;
18 Tem 2007 Çar tarihinde, Avi Kivity şunları yazmıştı:
> > http://cekirdek.pardus.org.tr/~caglar/kvm/netconsole_wo_apparmor is the
> > vanilla one's netconsole output, by the way without apparmor patchset
> > system not hard freezes.
>
> This trace is certainly a kvm bug. What guest are you
Dong, Eddie wrote:
>> Well, the ioapic userspace patch removes some nonexistent code that I
>> assume the lapic userspace patch should have added.
>>
>>
> O, this is a temp hack added by in kernel PIC. Maybe the branch
> mismatch.
>
> Here is the resent one. The sequence is:
> lapic
>
S.Çağlar Onur wrote:
> Hi;
>
> 18 Tem 2007 Çar tarihinde, Avi Kivity şunları yazmıştı:
>
>> S.Çağlar Onur wrote:
>>
>>> Hi;
>>>
>>> 18 Tem 2007 Çar tarihinde, Anthony Liguori şunları yazmıştı:
>>>
Can you reproduce without the appArmor patchset?
>>> If needed http
> In particular, this requires interrupt handling to be done by the guest --
> The host shouldn't load the corresponding device driver or otherwise access
> the device. Since the host kernel is not aware of the device semantics it
> cannot acknowledge the interrupt at the device level.
Tricky inde
On Wed, 2007-07-18 at 11:03 +0200, Andi Kleen wrote:
> On Wed, Jul 18, 2007 at 05:22:34PM +1000, Rusty Russell wrote:
> > However, the currently (i386-derived) x86-64 ones are suboptimal. The
>
> In what way are they suboptimal?
This was badly worded. They're "suboptimal" for use by i386 (ie.
On Wed, 2007-07-18 at 12:20 +0300, Avi Kivity wrote:
> repository: /home/avi/kvm
> branch: master
> commit a4d8dd22718d59fbdbaddaaed0b0e0c4664f397d
> Author: Avi Kivity <[EMAIL PROTECTED]>
> Date: Wed Jul 18 12:20:41 2007 +0300
>
> Revert "kvm: qemu: initialize ata ports as enabled"
>
>
Gregory Haskins wrote:
> On Wed, 2007-07-18 at 12:20 +0300, Avi Kivity wrote:
>
>> repository: /home/avi/kvm
>> branch: master
>> commit a4d8dd22718d59fbdbaddaaed0b0e0c4664f397d
>> Author: Avi Kivity <[EMAIL PROTECTED]>
>> Date: Wed Jul 18 12:20:41 2007 +0300
>>
>> Revert "kvm: qemu: initi
On Wed, 2007-07-18 at 15:42 +0300, Avi Kivity wrote:
>
>
> Good question. I initially guessed that when the bios turns them on, it
> does other things as well, but that's not the case.
Ah, I was wondering that myself.
I noticed from Dave's diffed dmesg output that you do see the PIIX
driver
Following the invitation below, you can now find the updated agenda for
'kvm developres' forum 2007' at: http://www.qumranet.com/agenda.php.
See you all at Tucson!
Rami
-Original Message-
From: Rami Tamir
Sent: Wednesday, July 04, 2007 10:14 PM
To: kvm-devel@lists.sourceforge.net; '[EMAI
On Wed, Jul 18, 2007 at 12:53:19PM +0300, Or Sagi wrote:
> Gentlepeople,
>
> We're currently working on PCI device pass-through support for KVM. In this
> model all physical hardware access to specific devices will be performed by
> the VM, and not by the host.
>
> In particular, this requires in
Jeff Dike wrote:
> On Tue, Jul 17, 2007 at 09:15:51AM -0500, Anthony Liguori wrote:
>
>> I'm planning on breaking this interface again since the new hypercall
>> API only takes 4 arguments instead of 6.
>>
>
> Is anything written anywhere about this hypercall interface?
>
I've posted p
Rusty Russell wrote:
> The main effect is to change the definition of "struct desc_struct" to
> a union of more complex types.
>
Yay! Someone finally killed it. Every time I tried to kill it, I ended
up off in the weeds chasing some bug.
>
> diff -r 656f3ff2c9ce arch/i386/kernel/process.c
Commit 9d9bbd4d247a674deb43565582151acdc22e90d1 makes CONFIG_CMPXCHG64
dependent on CONFIG_HIGHMEM64G, but KVM guest SMP support now also
requires CMPXCHG64 while not being tied to PAE. So the effect of that patch
is to disable KVM on non-PAE configs.
Untangle those dependencies by:
- having KVM
>> In particular, this requires interrupt handling to be done by the
>guest --
>> The host shouldn't load the corresponding device driver or otherwise
>access
>> the device. Since the host kernel is not aware of the device
semantics
>it
>> cannot acknowledge the interrupt at the device level.
>
>Tr
> What if we will force the specific device to the end of the list. Once
> IRQ_NONE was returned by the other devices, we will mask the irq,
> forward the irq to the guest, issue a timer for 1msec. Motivation:
> 1msec is long enough for the guest to ack the irq + host unmask the irq
It makes no di
Alan Cox wrote:
>> What if we will force the specific device to the end of the list. Once
>> IRQ_NONE was returned by the other devices, we will mask the irq,
>> forward the irq to the guest, issue a timer for 1msec. Motivation:
>> 1msec is long enough for the guest to ack the irq + host unmask the
> IMO the only reasonable solution is to disallow interrupt forwarding
> with shared irqs. If someone later comes up with a bright idea, we can
Which means you are back to ISA bus devices. Even checking if an IRQ is
currently unshared isn't simple as with hotplug this may change.
> implement it.
Alan Cox wrote:
>> IMO the only reasonable solution is to disallow interrupt forwarding
>> with shared irqs. If someone later comes up with a bright idea, we can
>>
>
> Which means you are back to ISA bus devices. Even checking if an IRQ is
> currently unshared isn't simple as with hotplug th
> Hotplug is user-controllable, so if the user refrains from adding pci
> devices after assigning a device to the guest, it should work. I think
> that USB interrupts are assigned to the controller, not the device, so
> USB hotplug can be ruled out.
Cardbus is more problematic.
Alan
---
>Alan Cox wrote:
>>> What if we will force the specific device to the end of the list.
>Once
>>> IRQ_NONE was returned by the other devices, we will mask the irq,
>>> forward the irq to the guest, issue a timer for 1msec. Motivation:
>>> 1msec is long enough for the guest to ack the irq + host unma
> >>Guest0 - blocked on I/O
> >>
> >>IRQ14 from your hardware
> >>Block IRQ14
> >>Sent to guest (guest is blocked)
> >>
> >>IRQ14 from hard disk
> >>Ignored (as blocked)
> >>
>
>
> But now the timer will pop and the hard disk will get its irq
On Wed, Jul 18, 2007 at 11:28:18AM -0500, Anthony Liguori wrote:
> Within the kernel right (VMCALL is only usable in ring 1).
Yup.
> Is it
> terribly important to be able to pass through the syscall arguments in
> registers verses packing them in a data structure and passing a pointer
> to t
Hi Avi;
18 Tem 2007 Çar tarihinde, Avi Kivity şunları yazmıştı:
> This trace is certainly a kvm bug. What guest are you running? If it
> is free (and does not contain private information), can you post it
> somewhere for me to download?
After seeing your "[PATCH] i386: Decouple PAE from CONFIG
S.Çağlar Onur wrote:
> Hi Avi;
>
> 18 Tem 2007 Çar tarihinde, Avi Kivity şunları yazmıştı:
>
>> This trace is certainly a kvm bug. What guest are you running? If it
>> is free (and does not contain private information), can you post it
>> somewhere for me to download?
>>
>
> After seeing
H. Peter Anvin wrote:
> Rusty Russell wrote:
>
>> Intel manual (and KVM definition) say it's TPR is 4 bits wide. Also fix
>> CR8_RESEVED_BITS typo.
>>
>> Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
>>
>
> Indeed it is.
>
> Acked-by: H. Peter Anvin <[EMAIL PROTECTED]>
>
>
Applied-b
On Wed, Jul 18, 2007 at 07:34:47PM +0300, Avi Kivity wrote:
> Commit 9d9bbd4d247a674deb43565582151acdc22e90d1 makes CONFIG_CMPXCHG64
> dependent on CONFIG_HIGHMEM64G, but KVM guest SMP support now also
> requires CMPXCHG64 while not being tied to PAE. So the effect of that patch
> is to disable KV
On Wed, Jul 18, 2007 at 07:46:13PM +0300, Avi Kivity wrote:
> IMO the only reasonable solution is to disallow interrupt forwarding
> with shared irqs. If someone later comes up with a bright idea, we can
> implement it. Otherwise the problem will solve itself with hardware
> moving to msi.
Disal
Jeff Dike wrote:
> On Wed, Jul 18, 2007 at 11:28:18AM -0500, Anthony Liguori wrote:
>
>> Within the kernel right (VMCALL is only usable in ring 1).
>>
>
> Yup.
>
>
>> Is it
>> terribly important to be able to pass through the syscall arguments in
>> registers verses packing them in a
Hello,
Thanks, Anthony.
I tried both #2 and #3.
It does not say any error, but still I cannot access the USB disk on key.
Maybe I miss something ?
Here are few more details.
When I ran:
/usr/local/kvm/bin/qemu-system-x86_64 -usbdevice disk:/dev/sdb
/work/kvm/win2003/vdisk.img -m 384
OR
/usr/loc
Ian Brown wrote:
> Hello,
>
> Thanks, Anthony.
>
> I tried both #2 and #3.
>
> It does not say any error, but still I cannot access the USB disk on key.
> Maybe I miss something ?
> Here are few more details.
>
> When I ran:
> /usr/local/kvm/bin/qemu-system-x86_64 -usbdevice disk:/dev/sdb
> /work/k
On Wed, Jul 18, 2007 at 10:32:06PM +0300, Ian Brown wrote:
> Hello,
>
> Thanks, Anthony.
>
> I tried both #2 and #3.
>
> It does not say any error, but still I cannot access the USB disk on key.
> Maybe I miss something ?
> Here are few more details.
>
> When I ran:
> /usr/local/kvm/bin/qemu-sy
>> >> Guest0 - blocked on I/O
>> >>
>> >> IRQ14 from your hardware
>> >> Block IRQ14
>> >> Sent to guest (guest is blocked)
>> >>
>> >> IRQ14 from hard disk
>> >> Ignored (as blocked)
>> >>
>>
>>
>> But now the timer will pop and the hard disk will get its
> - Make the device the last irqaction in the list
> - Our dummy handler will always return IRQ_HANDLED in case any other
> previous
> irqaction did not return such. It will also issue the timer and mask
> the irq in this case.
Ok
> btw, if I'm not mistaken only after bad 99900/10 the irq
> Hope it should work like the following [Please correct me if I'm
> wrong]:
> - Make the device the last irqaction in the list
> - Our dummy handler will always return IRQ_HANDLED in case any other
> previous
> irqaction did not return such. It will also issue the timer and mask
> the irq in th
On Wed, 2007-07-18 at 09:19 -0700, Zachary Amsden wrote:
> > +#define GET_CONTENTS(desc) (((desc)->raw32.b >> 10) & 3)
> > +#define GET_WRITABLE(desc) (((desc)->raw32.b >> 9) & 1)
>
> You got rid of the duplicate definitions here, but then added new
> duplicates (GET_CONTENTS / WRITABLE). Can y
On Thu, 2007-07-19 at 09:27 +1000, Rusty Russell wrote:
> On Wed, 2007-07-18 at 09:19 -0700, Zachary Amsden wrote:
> > > +#define GET_CONTENTS(desc) (((desc)->raw32.b >> 10) & 3)
> > > +#define GET_WRITABLE(desc) (((desc)->raw32.b >> 9) & 1)
> >
> > You got rid of the duplicate defini
On Wednesday 18 July 2007, Avi Kivity wrote:
>
> Once we're back to using fds, we might as well use ioctls. If anything,
> an ioctl has an explicit mention of the structure it manipulates in its
> definition. I don't care that it came in last in the last 15 annual
> kernel beauty contests.
>
>
On Wednesday 18 July 2007, Gerd Hoffmann wrote:
> Rusty Russell wrote:
> > You mean backend? For networking it makes a great deal of sense. For
> > block it makes far less sense (COW, weird formats, etc).
>
> For block you probably want both: userspace driver which can handle all
> sorts of fun
Arnd Bergmann wrote:
> On Wednesday 18 July 2007, Gerd Hoffmann wrote:
>
>> Rusty Russell wrote:
>>
>>> You mean backend? For networking it makes a great deal of sense. For
>>> block it makes far less sense (COW, weird formats, etc).
>>>
>> For block you probably want both: usersp
From: Paul Turner <[EMAIL PROTECTED]>
Since gcc can't handle [0]-sized arrays without type information we have
to use a generic type and then cast to remove arch dependencies from the
vcpu struct; this patch moves the structures (and the associated
include dependency) from kvm.h into svm/vmx.c
Paul Turner wrote:
> From: Paul Turner <[EMAIL PROTECTED]>
>
> Since gcc can't handle [0]-sized arrays without type information we have
> to use a generic type and then cast to remove arch dependencies from the
> vcpu struct; this patch moves the structures (and the associated
> include dependen
On Thursday 19 July 2007, Anthony Liguori wrote:
> > Interestingly, once you have the kernel driver that maps a block device,
> > you can do most of the useful user scenarios by means of /dev/loop
> > and/or device mapper.
>
> Not quite. Using device mapper to implement something like qcow turns
< fixing avi's email address in headers, woops >
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
Rename KVM_CREATE_PIC to KVM_CREATE_IRQCHIP
KVM_CAP_PIC to KVM_PIC_IRQCHIP since now it is not only PIC.
Signed-off-by: Yaozu (Eddie) Dong <[EMAIL PROTECTED]>
against lapic2 branch.
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index d7e16ba..3ce3e48 10
On Thu, Jul 19, 2007 at 09:27:41AM +1000, Rusty Russell wrote:
> On Wed, 2007-07-18 at 09:19 -0700, Zachary Amsden wrote:
> > > +#define GET_CONTENTS(desc) (((desc)->raw32.b >> 10) & 3)
> > > +#define GET_WRITABLE(desc) (((desc)->raw32.b >> 9) & 1)
> >
> > You got rid of the duplicate
Andi Kleen wrote:
>>
>> No processors that support KVM exist that also do not support CMPXCHG64,
>> so no additional check is necessary. This setup allows for a single kernel
>> that will boot on i486 and also support KVM if available.
>
> The CONFIG should only control the early CPUID checks, wh
Arnd Bergmann wrote:
> On Thursday 19 July 2007, Anthony Liguori wrote:
>
>>> Interestingly, once you have the kernel driver that maps a block device,
>>> you can do most of the useful user scenarios by means of /dev/loop
>>> and/or device mapper.
>>>
>> Not quite. Using device mapper to
On Thu, Jul 19, 2007 at 01:48:21AM +0200, Arnd Bergmann wrote:
> On Wednesday 18 July 2007, Gerd Hoffmann wrote:
> > Rusty Russell wrote:
> > > You mean backend? For networking it makes a great deal of sense. For
> > > block it makes far less sense (COW, weird formats, etc).
> >
> > For block yo
Paul Turner wrote:
>> >> > + struct vmcs *vmcs;
>>
>> + struct kvm_vcpu vcpu;
>>
>
> In this approach you might as well embed that at the start so that the
> arch independent code can still allocate/free, that or move the memory
> alloc/dealloc entirely to the arch specific code. Although
Arnd Bergmann wrote:
> On Thursday 19 July 2007, Anthony Liguori wrote:
>
>>> Interestingly, once you have the kernel driver that maps a block device,
>>> you can do most of the useful user scenarios by means of /dev/loop
>>> and/or device mapper.
>>>
>> Not quite. Using device mapper to
76 matches
Mail list logo
