Hi all,
I can reproduce bug #2143498 (FreeBSD fails to reboot), and it seems
to be related to the ioapic reset; using -no-kvm-irqchip solves the
problem, at least here.
Looking at the code I've not found where the in-kernel ioapic is reset;
the patch below reloads its state from userspace in the
Nakajima, Jun wrote:
What I mean is that a hypervisor (with a single vender id) can support multiple
interfaces, exposing a single interface to each guest that would expect a
specific interface at runtime.
Yes, and for the reasons outlined in a previous post in this thread,
this is an incr
On 10/3/2008 4:30:29 PM, H. Peter Anvin wrote:
> Nakajima, Jun wrote:
> > What it means their hypervisor returns the interface signature (i.e.
> > "Hv#1"), and that defines the interface. If we use "Lv_1", for
> > example, we can define the interface 0x4002 through 0x40FF for
> > Linux.
>
On Saturday 04 October 2008, Anthony Liguori wrote:
> Paul Brook wrote:
> > On Friday 03 October 2008, Ryan Harper wrote:
> >> The default buffer size breaks up larger read/write requests
> >> unnecessarily. When we encounter requests larger than the default dma
> >> buffer, reallocate the buffer t
Paul Brook wrote:
On Friday 03 October 2008, Ryan Harper wrote:
The default buffer size breaks up larger read/write requests unnecessarily.
When we encounter requests larger than the default dma buffer, reallocate
the buffer to support the request.
Allocating unboundedly large host buf
Nakajima, Jun wrote:
What it means their hypervisor returns the interface signature (i.e. "Hv#1"), and that
defines the interface. If we use "Lv_1", for example, we can define the interface
0x4002 through 0x40FF for Linux. Since leaf 0x4000 and 0x4001 are separate, we can
decou
On Friday 03 October 2008, Ryan Harper wrote:
> The default buffer size breaks up larger read/write requests unnecessarily.
> When we encounter requests larger than the default dma buffer, reallocate
> the buffer to support the request.
Allocating unboundedly large host buffers based on guest inpu
On 10/1/2008 6:24:26 PM, H. Peter Anvin wrote:
> Nakajima, Jun wrote:
> > >
> > > All I have seen out of Microsoft only covers CPUID levels
> > > 0x4000 as an vendor identification leaf and 0x4001 as a
> > > "hypervisor identification leaf", but you might have access to other
> > > informa
The default buffer size breaks up larger read/write requests unnecessarily.
When we encounter requests larger than the default dma buffer, reallocate the
buffer to support the request.
Signed-off-by: Ryan Harper <[EMAIL PROTECTED]>
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index f2b4814..a94f
Refactor scsi write path to match the simpler, faster scsi read path. No need
to call into the write completion function to calculate the request buf length.
Signed-off-by: Ryan Harper <[EMAIL PROTECTED]>
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index 16b3215..f2b4814 100644
--- a/hw/scsi-di
The patch refactors lsi_do_command to queue both read and write operations where
previously the code only queue'ed read operations.
Signed-off-by: Ryan Harper <[EMAIL PROTECTED]>
diff --git a/hw/lsi53c895a.c b/hw/lsi53c895a.c
index 5c161a1..5c0535c 100644
--- a/hw/lsi53c895a.c
+++ b/hw/lsi53c895
The patch changes lsi_queue_command to take a parameter indicating whether the
queue'ed command is a read or write. This is needed because the lsi device may
change phase we've recorded the type of operation.
Signed-off-by: Ryan Harper <[EMAIL PROTECTED]>
diff --git a/hw/lsi53c895a.c b/hw/lsi53c
With the aio refactoring completed we now have aio backend that supports
submitting large amounts of io into the host system. Curiously, write
performance through the scsi device is significantly slower than read
performance. On our reference setup[1], we see about 10MB/s writes and 40MB/s
for re
Hi
I do not see (halted) when I "stop" (pause) the vm. Tried on both KVM-70 and
kvm-73.
Is there a particular version it was introduced in?
Thanks
/Jd
(qemu) info cpus
info cpus
* CPU #0: pc=0xc00faaca thread_id=18641
(qemu) stop
stop
(qemu) info cpus
info cpus
* CPU #0: pc=0x00
When you attach a USB Card Reader from host to guest, but neither KVM-75
or KVM-76 works.
It of course connect the USB device, Windows XP detects it as a Cherry
XX44 card reader, but it never detects when a smart card is inserted, so
the application software cannot contact the smart card.
Using KV
Avi Kivity wrote:
> Simon Gao wrote:
>> Hi,
>>
>> Is it ok to use gcc-4.1.2 to compile kvm module and utility tools now?
>> Or is gcc-3.x.x still required?
>>
>>
>
> gcc 4 is supported.
>
Great. I want to try KVM with RHEL 5.x. This is very helpful.
Simon
--
To unsubscribe from this list: send
i have sent patch that remove the aliasing and i will resend it again
but untill then this patch should be applied as it fix kernel panic.
>From 61a13744e2367572f3e27ab5c0cce6e080e94d67 Mon Sep 17 00:00:00 2001
From: Izik Eidus <[EMAIL PROTECTED]>
Date: Fri, 3 Oct 2008 17:40:32 +0300
Subject: [PAT
* On Friday 03 Oct 2008 19:34:42 Zhang, Xiantao wrote:
> >> Since linux-ia64 DMAR is not ready in kvm.git, and it should be in
> >> linux-ia64.git. So it should be in kvm.git once Avi merged with
> >
> > OK; Does Linus' tree currently have the necessary support?
>
> If Linus's tree has picked up it
Simon Gao wrote:
Hi,
Is it ok to use gcc-4.1.2 to compile kvm module and utility tools now?
Or is gcc-3.x.x still required?
gcc 4 is supported.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe from this list: send the
Amit Shah wrote:
> * On Friday 03 Oct 2008 13:02:05 Zhang, Xiantao wrote:
>> Amit Shah wrote:
>>> * On Monday 29 Sep 2008 10:56:29 Zhang, Xiantao wrote:
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Sat, 27 Sep 2008 10:59:36 +0800
Subject: [PATCH] kvm: Moving device_assignment logic
* john cooper <[EMAIL PROTECTED]> [2008-10-02 18:51]:
> Ryan Harper wrote:
>
> >Results:
> > These results are with the patch series applied to KVM (plus a small KVM
> > only
> > change -- KVM patches forthcoming).
>
> Is the above "KVM only change" a kernel-side kvm patch?
> If so could you pro
* On Friday 03 Oct 2008 16:07:54 Sheng Yang wrote:
> > Just one thing: can you make the irq_source_id argument the 3rd one and
> > the 'level' as the last one? It's clearer to think of it that way.
>
> Yeah, put the irq_source_id at the end of parameter list is a little ugly.
> But I think it's bet
On Fri, Oct 03, 2008 at 01:06:53PM +0530, Amit Shah wrote:
> * On Thursday 02 Oct 2008 22:15:59 Sheng Yang wrote:
>
> > /* This should be called with the kvm->lock mutex held */
> > -void kvm_set_irq(struct kvm *kvm, int irq, int level)
> > +void kvm_set_irq(struct kvm *kvm, int irq, int level, i
On Wed, Oct 01, 2008 at 09:19:56AM +0200, Joerg Roedel wrote:
> > It might be possible to have a per-device slow or fast path, where
> > the fast path is for devices which have no DMA limitations
> > (high-end devices generally don't) and the slow path is for
> > devices which do.
>
> This solves
* On Friday 03 Oct 2008 13:02:05 Zhang, Xiantao wrote:
> Amit Shah wrote:
> > * On Monday 29 Sep 2008 10:56:29 Zhang, Xiantao wrote:
> >> From: Xiantao Zhang <[EMAIL PROTECTED]>
> >> Date: Sat, 27 Sep 2008 10:59:36 +0800
> >> Subject: [PATCH] kvm: Moving device_assignment logic to kvm_main.c
> >>
>
* On Thursday 02 Oct 2008 22:15:59 Sheng Yang wrote:
> /* This should be called with the kvm->lock mutex held */
> -void kvm_set_irq(struct kvm *kvm, int irq, int level)
> +void kvm_set_irq(struct kvm *kvm, int irq, int level, int irq_source_id)
Just one thing: can you make the irq_source_id arg
Amit Shah wrote:
> * On Monday 29 Sep 2008 10:56:29 Zhang, Xiantao wrote:
>> From: Xiantao Zhang <[EMAIL PROTECTED]>
>> Date: Sat, 27 Sep 2008 10:59:36 +0800
>> Subject: [PATCH] kvm: Moving device_assignment logic to kvm_main.c
>>
>> To share with other archs, this patch moves device_assignment
>>
Fixed. Thank you, Amit! Attached new version.
>From 4f8d82eeb3f2eb8d2e97d28d5738958a483120e6 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Fri, 3 Oct 2008 14:58:09 +0800
Subject: [PATCH] kvm/ia64: Make pmt table be able to hold physical mmio
entries.
Don't try to do put_p
* On Monday 29 Sep 2008 10:56:29 Zhang, Xiantao wrote:
> From: Xiantao Zhang <[EMAIL PROTECTED]>
> Date: Sat, 27 Sep 2008 10:59:36 +0800
> Subject: [PATCH] kvm: Moving device_assignment logic to kvm_main.c
>
> To share with other archs, this patch moves device_assignment
> logic to common parts.
>
29 matches
Mail list logo
