On 09/27/2012 11:49 AM, Raghavendra K T wrote:
On 09/25/2012 08:30 PM, Dor Laor wrote:
On 09/24/2012 02:02 PM, Raghavendra K T wrote:
On 09/24/2012 02:12 PM, Dor Laor wrote:
In order to help PLE and pvticketlock converge I thought that a small
test code should be developed to test this in a
On 09/24/2012 02:02 PM, Raghavendra K T wrote:
On 09/24/2012 02:12 PM, Dor Laor wrote:
In order to help PLE and pvticketlock converge I thought that a small
test code should be developed to test this in a predictable,
deterministic way.
The idea is to have a guest kernel module that spawn a
In order to help PLE and pvticketlock converge I thought that a small
test code should be developed to test this in a predictable,
deterministic way.
The idea is to have a guest kernel module that spawn a new thread each
time you write to a /sys/ entry.
Each such a thread spins over a sp
On 07/24/2012 03:30 PM, Sasha Levin wrote:
On 07/24/2012 10:26 AM, Dor Laor wrote:
On 07/24/2012 07:55 AM, Rusty Russell wrote:
On Mon, 23 Jul 2012 22:32:39 +0200, Sasha Levin wrote:
As it was discussed recently, there's currently no way for the guest to notify
the host about panics. Fu
On 07/24/2012 07:55 AM, Rusty Russell wrote:
On Mon, 23 Jul 2012 22:32:39 +0200, Sasha Levin wrote:
As it was discussed recently, there's currently no way for the guest to notify
the host about panics. Further more, there's no reasonable way to notify the
host of other critical events such as a
Amit Shah wrote:
On Wednesday 19 December 2007 21:02:06 Glauber de Oliveira Costa wrote:
> On Dec 19, 2007 12:27 PM, Avi Kivity <[EMAIL PROTECTED]> wrote:
> > Ingo Molnar wrote:
> > > * Avi Kivity <[EMAIL PROTECTED]> wrote:
> > >> Avi Kivity wrote:
> > >>> Testing shows wrmsr and rdtsc function
Ingo Molnar wrote:
* Dor Laor <[EMAIL PROTECTED]> wrote:
Here [include/asm-x86/tsc.h]:
/* Like get_cycles, but make sure the CPU is synchronized. */
static __always_inline cycles_t get_cycles_sync(void)
{
unsigned long long ret;
unsigned eax, edx;
/*
* Use RDT
Andi Kleen wrote:
[headers rewritten because of gmane crosspost breakage]
In the latest kernel (2.6.24-rc3) I noticed a drastic performance
decrease for KVM networking.
That should not have changed for quite some time.
Also it depends on the CPU of course.
I didn't find the exact
Ingo Molnar wrote:
* Dor Laor <[EMAIL PROTECTED]> wrote:
> Hi Ingo, Thomas,
>
> In the latest kernel (2.6.24-rc3) I noticed a drastic performance
> decrease for KVM networking. The reason is many vmexit (exit reason is
> cpuid instruction) caused by calls to getti
Hi Ingo, Thomas,
In the latest kernel (2.6.24-rc3) I noticed a drastic performance
decrease for KVM networking.
The reason is many vmexit (exit reason is cpuid instruction) caused by
calls to gettimeofday that uses tsc sourceclock.
read_tsc calls get_cycles_sync which might call cpuid in order
Anthony Liguori wrote:
This is a PCI device that implements a transport for virtio. It allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
While it's a little premature, we can start thinking of irq path
improvements.
The current patch acks a private isr and afterwards
Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
This is a PCI device that implements a transport for virtio. It allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
Didn't see support for dma.
Not sure what you're expecting the
David Brown wrote:
Uhm, not sure who to send this too...
I thought I'd try out the realtime patch set and it didn't work at all
with kvm. The console didn't dump anything and the system completely
locked up.
Anyone have any suggestions as to how to get more output on this issue?
It got to the
My current view of the IO stack is the following:
-- -- --
-- -
|NET_PCI_BACK| |BLK_PCI_BACK| |9P_PCI_BACK| |NET_FRONT|
|BLK_FRONT| |9P_FRONT|
-- -- --
---
>>
>> Nice driver. I'm hoping we can do a virtio driver using a similar
>> concept.
>>
>> > +#define PCI_VENDOR_ID_9P 0x5002
>> > +#define PCI_DEVICE_ID_9P 0x000D
>>
>> Where do these numbers come from? Can we be sure they don't conflict
>with
>> actual hardware?
>
>I stole the VENDOR_ID fr
>> > This adds a shared memory transport for a synthetic 9p device for
>> > paravirtualized file system support under KVM/QEMU.
>>
>> Nice driver. I'm hoping we can do a virtio driver using a similar
>> concept.
>>
>
>Yes. I'm looking at the patches from Dor now, it should be pretty
>straight forw
>> >> 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
>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
>> 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
>Avi Kivity wrote:
>> - new userspace interface (work in progress)
>
>kvmfs in kvm-15 kernel code does not to build with older kernels
(2.6.16
>fails, 2.6.18 works ok), looks like the reason are some changes in
>superblock handling.
>
>Do you intend to fix that?
Did you run the make sync under th
>
>
>> Somthing else that came up in a conversation with Dor: the need for a
>> clean way to raise a guest interrupt. The guest may be sleeping in
>> userspace, scheduled out, or running on another cpu (and requiring an
>> ipi to get it out of guest mode).
>
>yeah it'd be nice if I could just call
>
>Pavel Machek wrote:
>> On Mon 2007-02-19 10:30:52, Avi Kivity wrote:
>>
>>> Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
>>>
>>
>> changelog?
>>
>>
>
>Well, I can't think of anything to add beyond $subject. The patch adds
>calls from the arch-dependent hypercall handlers to a new arch
>indepen
>
>Hi all,
>
>A patch to use ARRAY_SIZE macro already defined in kernel.h
>
>Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
Applied, 10x
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.
>* Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
>> > dyntick-enabled guest:
>> > - reduce the load on the host when the guest is idling
>> > (currently an idle guest consumes a few percent cpu)
>>
>> yeah. KVM under -rt already works with dynticks enabled on both the
>> host and the guest. (but it's
>On linux-26..20-rc2, "modprobe kvm-intel" loaded the module
>successful, but running qemu returns a error ...
>
>/usr/local/kvm/bin/qemu -hda vdisk.img -cdrom cd.iso -boot d -m 128
>open /dev/kvm: No such file or directory
>Could not initialize KVM, will disable KVM support
Are you sure the kvm
25 matches
Mail list logo
