On Sunday 28 June 2009 20:51:14 Gleb Natapov wrote:
> KVM would like to provide x2APIC interface to a guest without emulating
> interrupt remapping device. The reason KVM prefers guest to use x2APIC
> is that x2APIC interface is better virtualizable and provides better
> performance than mmio x
On Mon, Jun 29, 2009 at 03:49:45PM +0800, Sheng Yang wrote:
> > Signed-off-by: Gleb Natapov
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index d1430ef..7438c5c 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -260,7 +260,7 @@ config SMP
> >
> > config X86_X2APIC
> >
On Sun, 2009-06-28 at 17:11 +0300, Avi Kivity wrote:
> > 1) I get the $subject warning a lot, when starting kvm:
> > [85763.262707] BUG: using smp_processor_id() in preemptible []
> > code: kvm/13877
> > [85763.262719] caller is kvm_write_guest_time+0x40/0x220 [kvm]
> > [85763.262722] Pid
On 06/28/2009 10:34 PM, Michael S. Tsirkin wrote:
This changes bus accesses to use high-level kvm_io_bus_read/kvm_io_bus_write
functions, which utilize read/write semaphore intead of mutex. in_range now
becomes unused so it is removed from device ops in favor of read/write
callbacks performing r
On 06/29/2009 11:32 AM, Johannes Berg wrote:
On Sun, 2009-06-28 at 17:11 +0300, Avi Kivity wrote:
1) I get the $subject warning a lot, when starting kvm:
[85763.262707] BUG: using smp_processor_id() in preemptible [] code:
kvm/13877
[85763.262719] caller is kvm_write_guest_time+0x4
On 06/28/2009 06:46 PM, Gleb Natapov wrote:
Remove KVM specific init/sipi handling from hw/apic.c. Now when
upstream QEMU handles init/sipi in a cpu loop KVM can do the same.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list:
On 06/28/2009 03:15 PM, Gleb Natapov wrote:
Directed EOI is specified by x2APIC, but is available even when lapic is
in xAPIC mode.
#define APIC_LVT_NUM 6
/* 14 is the version for Xeon and Pentium 8.4.8*/
-#define APIC_VERSION (0x14UL | ((APIC_LVT_NUM - 1)<
On Mon, Jun 29, 2009 at 11:37:00AM +0300, Avi Kivity wrote:
> On 06/28/2009 10:34 PM, Michael S. Tsirkin wrote:
>> This changes bus accesses to use high-level kvm_io_bus_read/kvm_io_bus_write
>> functions, which utilize read/write semaphore intead of mutex. in_range now
>> becomes unused so it is
On Sun, Jun 28, 2009 at 02:10:41PM -0700, Paul E. McKenney wrote:
> On Sun, Jun 28, 2009 at 10:06:36PM +0300, Michael S. Tsirkin wrote:
> > On Sun, Jun 28, 2009 at 09:14:11AM -0700, Paul E. McKenney wrote:
> > > On Sun, Jun 28, 2009 at 04:22:24PM +0300, Michael S. Tsirkin wrote:
> > > > Paul,
> > >
On Mon, Jun 29, 2009 at 12:18:28PM +0300, Avi Kivity wrote:
> On 06/28/2009 03:15 PM, Gleb Natapov wrote:
>> Directed EOI is specified by x2APIC, but is available even when lapic is
>> in xAPIC mode.
>>
>> #define APIC_LVT_NUM 6
>> /* 14 is the version for Xeon and Pentium
On 06/28/2009 03:15 PM, Gleb Natapov wrote:
This patch implements MSR interface to a local apic as defines by x2APIC
Intel specification.
@@ -269,7 +275,12 @@ int kvm_apic_match_physical_addr(struct kvm_lapic *apic,
u16 dest)
int kvm_apic_match_logical_addr(struct kvm_lapic *apic, u8 mda)
{
On Mon, Jun 29, 2009 at 11:37:00AM +0300, Avi Kivity wrote:
> On 06/28/2009 10:34 PM, Michael S. Tsirkin wrote:
>> This changes bus accesses to use high-level kvm_io_bus_read/kvm_io_bus_write
>> functions, which utilize read/write semaphore intead of mutex. in_range now
>> becomes unused so it is
On 06/29/2009 12:23 PM, Michael S. Tsirkin wrote:
On Mon, Jun 29, 2009 at 11:37:00AM +0300, Avi Kivity wrote:
On 06/28/2009 10:34 PM, Michael S. Tsirkin wrote:
This changes bus accesses to use high-level kvm_io_bus_read/kvm_io_bus_write
functions, which utilize read/write semaphore in
On 06/29/2009 12:29 PM, Gleb Natapov wrote:
On Mon, Jun 29, 2009 at 12:18:28PM +0300, Avi Kivity wrote:
On 06/28/2009 03:15 PM, Gleb Natapov wrote:
Directed EOI is specified by x2APIC, but is available even when lapic is
in xAPIC mode.
#define APIC_LVT_NUM 6
/*
On Mon, Jun 29, 2009 at 12:42:02PM +0300, Avi Kivity wrote:
> On 06/28/2009 03:15 PM, Gleb Natapov wrote:
>> This patch implements MSR interface to a local apic as defines by x2APIC
>> Intel specification.
>>
>> @@ -269,7 +275,12 @@ int kvm_apic_match_physical_addr(struct kvm_lapic
>> *apic, u16 d
On Mon, Jun 29, 2009 at 12:44:53PM +0300, Avi Kivity wrote:
> On 06/29/2009 12:23 PM, Michael S. Tsirkin wrote:
>> On Mon, Jun 29, 2009 at 11:37:00AM +0300, Avi Kivity wrote:
>>
>>> On 06/28/2009 10:34 PM, Michael S. Tsirkin wrote:
>>>
This changes bus accesses to use high-level
>>>
On 06/29/2009 12:41 PM, Michael S. Tsirkin wrote:
On Mon, Jun 29, 2009 at 11:37:00AM +0300, Avi Kivity wrote:
On 06/28/2009 10:34 PM, Michael S. Tsirkin wrote:
This changes bus accesses to use high-level kvm_io_bus_read/kvm_io_bus_write
functions, which utilize read/write semaphore in
On Mon, Jun 29, 2009 at 12:49:00PM +0300, Avi Kivity wrote:
> On 06/29/2009 12:29 PM, Gleb Natapov wrote:
>> On Mon, Jun 29, 2009 at 12:18:28PM +0300, Avi Kivity wrote:
>>
>>> On 06/28/2009 03:15 PM, Gleb Natapov wrote:
>>>
Directed EOI is specified by x2APIC, but is available even w
On 06/29/2009 12:51 PM, Gleb Natapov wrote:
On Mon, Jun 29, 2009 at 12:42:02PM +0300, Avi Kivity wrote:
On 06/28/2009 03:15 PM, Gleb Natapov wrote:
This patch implements MSR interface to a local apic as defines by x2APIC
Intel specification.
@@ -269,7 +275,12 @@ int kvm_apic_match_ph
On Mon, 2009-06-29 at 12:08 +0300, Avi Kivity wrote:
> >> You can see where it hangs using the monitor 'info registers' and 'x/30i
> >> $eip' commands.
> >>
> >
> > not much luck since it doesn't hang at a specific instruction:
> >
>
> You can try mapping these with gdb (in fact, you ca
On 06/29/2009 12:51 PM, Michael S. Tsirkin wrote:
We can convert it to rcu indepenently of other things protected by
slots_lock; no need to do everything at the same time.
Yes but once we merge locks, it will be harder to split them out.
I know I can now do grep bus_lock and find all plac
On Mon, 2009-06-29 at 11:54 +0200, Johannes Berg wrote:
> On Mon, 2009-06-29 at 12:08 +0300, Avi Kivity wrote:
>
> > >> You can see where it hangs using the monitor 'info registers' and 'x/30i
> > >> $eip' commands.
> > >>
> > >
> > > not much luck since it doesn't hang at a specific instruc
On 06/29/2009 12:54 PM, Johannes Berg wrote:
On Mon, 2009-06-29 at 12:08 +0300, Avi Kivity wrote:
You can see where it hangs using the monitor 'info registers' and 'x/30i
$eip' commands.
not much luck since it doesn't hang at a specific instruction:
You can try mapping
On 06/29/2009 12:57 PM, Johannes Berg wrote:
It's actually panic'ed because it ran out of memory, but didn't print
that to my vga/console/curses/...
And if I add -m 512 it works just fine. Seems the default is too small
for me... But why would qemu/kvm have different defaults?
Both
On 06/29/2009 12:52 PM, Gleb Natapov wrote:
We're changing something that the guests sees. Suppose the guest has a
bug in directed EOI, just upgrading kvm will cause it to trigger. If we
make it dependent on x2apic (or something else that needs to be selected
by the user), we maintain compatibi
On Mon, 2009-06-29 at 12:59 +0300, Avi Kivity wrote:
> > It's actually panic'ed because it ran out of memory, but didn't print
> > that to my vga/console/curses/...
> >
>
> Maybe we give it crappy numa table, try booting with numa disabled.
# CONFIG_NUMA is not set
> Also make sure you
On 06/29/2009 01:00 PM, Johannes Berg wrote:
Also make sure you boot with the bios provided by qemu-kvm, not some
random qemu.
I, uh, have no idea how to ensure that -- I'm simply using the debian
kvm package.
That should be a good way to ensure it. What version is it?
--
error c
On Mon, 2009-06-29 at 13:04 +0300, Avi Kivity wrote:
> On 06/29/2009 01:00 PM, Johannes Berg wrote:
>
> >> Also make sure you boot with the bios provided by qemu-kvm, not some
> >> random qemu.
> >>
> >
> > I, uh, have no idea how to ensure that -- I'm simply using the debian
> > kvm package
On Mon, 2009-06-29 at 13:00 +0300, Avi Kivity wrote:
> On 06/29/2009 12:57 PM, Johannes Berg wrote:
> >> It's actually panic'ed because it ran out of memory, but didn't print
> >> that to my vga/console/curses/...
> >>
> >
> > And if I add -m 512 it works just fine. Seems the default is too s
On Mon, Jun 29, 2009 at 12:53:48PM +0300, Avi Kivity wrote:
> On 06/29/2009 12:41 PM, Michael S. Tsirkin wrote:
>> On Mon, Jun 29, 2009 at 11:37:00AM +0300, Avi Kivity wrote:
>>
>>> On 06/28/2009 10:34 PM, Michael S. Tsirkin wrote:
>>>
This changes bus accesses to use high-level
>>>
KVM would like to provide x2APIC interface to a guest without emulating
interrupt remapping device. The reason KVM prefers guest to use x2APIC
is that x2APIC interface is better virtualizable and provides better
performance than mmio xAPIC interface:
- msr exits are faster than mmio (no page table
On 06/29/2009 01:06 PM, Johannes Berg wrote:
And if I add -m 512 it works just fine. Seems the default is too small
for me... But why would qemu/kvm have different defaults?
Both are 128 MB. Strange. And certainly Linux should boot in 128 MB.
If I boot with -m 512 I get this:
On Mon, 2009-06-29 at 13:16 +0300, Avi Kivity wrote:
> > If I boot with -m 512 I get this:
> > root@(none):~# free
> > total used free sharedbuffers cached
> > Mem:378608 25196 353412 0 1012 8692
> > -/+ buffers/cache:
On 06/29/2009 01:06 PM, Michael S. Tsirkin wrote:
2. if I do it before in_range removal it's a lot of churn:
one of the reasons for code reorg is so that there are less
places to change locking.
I don't think you really need to change anything. slots_lock is already
taken (except whe
* Gleb Natapov wrote:
> KVM would like to provide x2APIC interface to a guest without emulating
> interrupt remapping device. The reason KVM prefers guest to use x2APIC
> is that x2APIC interface is better virtualizable and provides better
> performance than mmio xAPIC interface:
>
> - msr exit
On 06/29/2009 01:18 PM, Johannes Berg wrote:
If I boot with -m 512 I get this:
root@(none):~# free
total used free sharedbuffers cached
Mem:378608 25196 353412 0 1012 8692
-/+ buffers/cache: 15492 363116
Swap:
On Mon, 2009-06-29 at 13:25 +0300, Avi Kivity wrote:
> > So even my qemu is missing a lot more than you are. But I guess my
> > kernel might also be a lot larger.
> >
>
> Aha. Maybe paravirt patching allocates a lot of memory? Otherwise
> there should be no difference between qemu-kvm and
On Mon, Jun 29, 2009 at 12:22:35PM +0200, Ingo Molnar wrote:
>
> * Gleb Natapov wrote:
>
> > KVM would like to provide x2APIC interface to a guest without emulating
> > interrupt remapping device. The reason KVM prefers guest to use x2APIC
> > is that x2APIC interface is better virtualizable and
On 06/29/2009 01:32 PM, Johannes Berg wrote:
Do you really have a 100MB kernel?
Hmm. Maybe?
text data bss dec hex filename
5635486 5482828 84287488954058025afc6ea vmlinux
-rwxr-xr-x 1 johannes johannes 86242879 2009-06-29 11:31
I am running mix of XP and SuSE 11.1.
I think this one is triggered by Windows XP SP 3, because the VM
rebooted in the same time when the back-trace appear in the syslog.
How can I get the latest code ?
Thanks in advance.
Best regards,
Ivelin Ivanov
Gleb Natapov wrote:
> On Sun, Jun 28, 2009 a
On Mon, 2009-06-29 at 03:08 -0700, Gleb Natapov wrote:
>
> - local_irq_save(flags);
> mask_IO_APIC_setup(ioapic_entries);
> - mask_8259A();
Is there a reason why the 8259 mask/unmask operations are separated from
io-apic mask/unmask operations.
Can we keep it together so that it w
On Mon, 2009-06-29 at 13:39 +0300, Avi Kivity wrote:
> On 06/29/2009 01:32 PM, Johannes Berg wrote:
> >
> >> Do you really have a 100MB kernel?
> >>
> >
> > Hmm. Maybe?
> >
> > text data bss dec hex filename
> > 5635486 5482828 842874889540580
On Mon, Jun 29, 2009 at 03:46:56AM -0700, Suresh Siddha wrote:
> On Mon, 2009-06-29 at 03:08 -0700, Gleb Natapov wrote:
> >
> > - local_irq_save(flags);
> > mask_IO_APIC_setup(ioapic_entries);
> > - mask_8259A();
>
> Is there a reason why the 8259 mask/unmask operations are separated fro
On 06/29/2009 01:55 PM, Johannes Berg wrote:
I had MAXSMP configured, which makes it 4096, but if I turn off MAXSMP
and make NR_CPUS 8, then I get
text data bss dechex filename
5594521 2562924 127262722088371713ea905 vmlinux
12MB bs
On Mon, 2009-06-29 at 04:25 -0700, Gleb Natapov wrote:
> I left interrupt masking in enable_IR_x2apic() because interrupt should
> be masked during transition to x2apic mode, so it can't be moved to
> enable_IR(). I moved io-apic into enable_IR() because the state of
> io-apic depend on whether IR
Bugs item #2813926, was opened at 2009-06-29 13:57
Message generated for change (Tracker Item Submitted) made by saezien
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2813926&group_id=180599
Please note that this message will contain a full copy of the
On Mon, 2009-06-29 at 14:38 +0300, Avi Kivity wrote:
> On 06/29/2009 01:55 PM, Johannes Berg wrote:
> > I had MAXSMP configured, which makes it 4096, but if I turn off MAXSMP
> > and make NR_CPUS 8, then I get
> > text data bss dechex filename
> > 5594521
This series switches kvm_io_device to slots_lock from kvm->lock mutex,
and uses that to rework io bus API. This takes less locks on data path,
and uses less lines of code. These changes will also be useful to serve
as basis for Greg's iosignalfd work.
Signed-off-by: Michael S. Tsirkin
---
I have
slots_lock is taken everywhere when device ops are called.
Document this as we will use this to rework locking for io.
Signed-off-by: Michael S. Tsirkin
---
virt/kvm/iodev.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/virt/kvm/iodev.h b/virt/kvm/iodev.h
index 2c67f
switch coalesced mmio slots_lock. slots_lock is already taken for read
everywhere, so we only need to take it for write when changing zones.
This is in preparation to removing in_range and kvm->lock around it.
Signed-off-by: Michael S. Tsirkin
---
virt/kvm/coalesced_mmio.c | 12 ++--
Use slots_lock to protect device list on the bus. slots_lock is already
taken for read everywhere, so we only need to take it for write when
registering devices. This is in preparation to removing in_range and
kvm->lock around it.
Signed-off-by: Michael S. Tsirkin
---
arch/x86/kvm/i8254.c
This changes bus accesses to use high-level kvm_io_bus_read/kvm_io_bus_write
functions. in_range now becomes unused so it is removed from device ops in
favor of read/write callbacks performing range checks internally.
This allows aliasing (mostly for in-kernel virtio), as well as better error
hand
On Mon, Jun 29, 2009 at 03:09:19PM +0300, Michael S. Tsirkin wrote:
> This changes bus accesses to use high-level kvm_io_bus_read/kvm_io_bus_write
> functions. in_range now becomes unused so it is removed from device ops in
> favor of read/write callbacks performing range checks internally.
>
> Th
On 06/17/2009 04:07 PM, Marcelo Tosatti wrote:
KVM: use vcpu_id instead of bsp_vcpu pointer in kvm_vcpu_is_bsp
Change kvm_vcpu_is_bsp to use vcpu_id instead of bsp_vcpu pointer, which
is only initialized at the end of kvm_vm_ioctl_create_vcpu.
Applied, thanks.
--
error compiling committee.
On 06/29/2009 03:08 PM, Michael S. Tsirkin wrote:
This series switches kvm_io_device to slots_lock from kvm->lock mutex,
and uses that to rework io bus API. This takes less locks on data path,
and uses less lines of code. These changes will also be useful to serve
as basis for Greg's iosignalfd w
On Wed, Jun 24, 2009 at 11:43:00AM +0300, Avi Kivity wrote:
> On 06/19/2009 04:16 PM, Joerg Roedel wrote:
>> Hi,
>>
>> this is the third version of the patches for KVM to support 1GB pages.
>> Changes
>> to the last version include:
>>
>> - changed reporting of 1GB page support to userspace t
KVM would like to provide x2APIC interface to a guest without emulating
interrupt remapping device. The reason KVM prefers guest to use x2APIC
is that x2APIC interface is better virtualizable and provides better
performance than mmio xAPIC interface:
- msr exits are faster than mmio (no page table
kerneloops.org shows tons of oopses on amd, see
http://www.kerneloops.org/oops.php?number=79008. I suspect this has to
do with resuming a laptop while a guest is running. Can anyone confirm
or deny?
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this l
The qcow block driver format is no longer maintained and likely contains
serious data corruptors. Urge users to stay away for it, and advertise
the new and improved replacement.
Signed-off-by: Avi Kivity
---
block/qcow.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git
On Sun, Jun 28, 2009 at 10:34:25PM +0300, Michael S. Tsirkin wrote:
> This changes bus accesses to use high-level kvm_io_bus_read/kvm_io_bus_write
> functions, which utilize read/write semaphore intead of mutex. in_range now
> becomes unused so it is removed from device ops in favor of read/write
On Mon, Jun 29, 2009 at 01:37:12PM +0300, Ivelin Ivanov wrote:
> I am running mix of XP and SuSE 11.1.
> I think this one is triggered by Windows XP SP 3, because the VM
> rebooted in the same time when the back-trace appear in the syslog.
> How can I get the latest code ?
http://www.linux-kvm.or
On 06/29/2009 05:06 PM, Marcelo Tosatti wrote:
On Sun, Jun 28, 2009 at 10:34:25PM +0300, Michael S. Tsirkin wrote:
This changes bus accesses to use high-level kvm_io_bus_read/kvm_io_bus_write
functions, which utilize read/write semaphore intead of mutex. in_range now
becomes unused so it is
On 06/29/2009 05:39 PM, Joerg Roedel wrote:
On Mon, Jun 29, 2009 at 04:41:17PM +0300, Avi Kivity wrote:
kerneloops.org shows tons of oopses on amd, see
http://www.kerneloops.org/oops.php?number=79008. I suspect this has to
do with resuming a laptop while a guest is running. Can anyone conf
On Mon, Jun 29, 2009 at 04:41:17PM +0300, Avi Kivity wrote:
> kerneloops.org shows tons of oopses on amd, see
> http://www.kerneloops.org/oops.php?number=79008. I suspect this has to
> do with resuming a laptop while a guest is running. Can anyone confirm
> or deny?
I havn't verified this
On Mon, 2009-06-29 at 06:29 -0700, Gleb Natapov wrote:
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index d1430ef..3e5b6ea 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -260,12 +260,15 @@ config SMP
>
> config X86_X2APIC
> bool "Support x2apic"
> - depends on X8
On Mon, Jun 29, 2009 at 07:58:39AM -0700, Suresh Siddha wrote:
> On Mon, 2009-06-29 at 06:29 -0700, Gleb Natapov wrote:
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index d1430ef..3e5b6ea 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -260,12 +260,15 @@ config SMP
>
On Mon, 2009-06-29 at 08:10 -0700, Gleb Natapov wrote:
> On Mon, Jun 29, 2009 at 07:58:39AM -0700, Suresh Siddha wrote:
> > Thinking more, probably we shouldn't remove this dependency. This might
> > encourage people (knowingly or unknowingly) to enable x2apic without
> > interrupt-remapping. Can w
Errors are:
hw/pcspk.c:85: error: expected declaration specifiers or ‘...’ before
‘kvm_pit_state’
hw/pcspk.c:87: error: expected declaration specifiers or ‘...’ before
‘kvm_pit_state’
hw/pcspk.c: In function ‘pcspk_callback’:
hw/pcspk.c:114: error: too many arguments to function ‘kvm_get
(Applies to kvm.git/master:4631e094)
The following is the latest attempt to fix the races in irqfd/eventfd, as
well as restore DEASSIGN support. For more details, please read the patch
headers.
You can also find this applied as a git tree:
git pull
git://git.kernel.org/pub/scm/linux/kernel/git
We need to plug some race conditions on eventfd shutdown. In order to
do this, we need to change the context in which the release notification
is delivered so that the wqh lock is now held. However, there is currently
code in the release callback that assumes it can sleep.
We have a slight chick
eventfd currently emits a POLLHUP wakeup on f_ops->release() to generate a
"release" callback. This lets eventfd clients know if the eventfd is about
to go away and is very useful particularly for in-kernel clients. However,
until recently it is not possible to use this feature of eventfd in a
ra
DEASSIGN allows us to optionally disassociate an IRQFD from its underlying
eventfd without destroying the eventfd in the process. This is useful
for conditions like live-migration which may have an eventfd associated
with a device and an IRQFD. We need to be able to decouple the guest
from the ev
From: Davide Libenzi
The following patch changes the eventfd interface to de-couple the eventfd
memory context, from the file pointer instance.
Without such change, there is no clean way to racely free handle the
POLLHUP event sent when the last instance of the file* goes away.
Also, now the inte
On Mon, Jun 29, 2009 at 08:15:05AM -0700, Suresh Siddha wrote:
> On Mon, 2009-06-29 at 08:10 -0700, Gleb Natapov wrote:
> > On Mon, Jun 29, 2009 at 07:58:39AM -0700, Suresh Siddha wrote:
> > > Thinking more, probably we shouldn't remove this dependency. This might
> > > encourage people (knowingly
Gregory Haskins wrote:
> (Applies to kvm.git/master:4631e094)
>
> The following is the latest attempt to fix the races in irqfd/eventfd, as
> well as restore DEASSIGN support. For more details, please read the patch
> headers.
>
> You can also find this applied as a git tree:
>
> git pull
> git:/
On Mon, Jun 29, 2009 at 03:09:11PM +0300, Michael S. Tsirkin wrote:
> Use slots_lock to protect device list on the bus. slots_lock is already
> taken for read everywhere, so we only need to take it for write when
> registering devices. This is in preparation to removing in_range and
> kvm->lock a
Mark McLoughlin wrote:
> Errors are:
>
> hw/pcspk.c:85: error: expected declaration specifiers or ‘...’ before
> ‘kvm_pit_state’
> hw/pcspk.c:87: error: expected declaration specifiers or ‘...’ before
> ‘kvm_pit_state’
> hw/pcspk.c: In function ‘pcspk_callback’:
> hw/pcspk.c:114: error:
There is a missing unlock on one fail path in ioapic_mmio_write,
fix that.
Signed-off-by: Jiri Slaby
---
virt/kvm/ioapic.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
index d8b2eca..2b3307b 100644
--- a/virt/kvm/ioapic.c
+++ b/
Look good. A couple of minor nits:
On Mon, Jun 29, 2009 at 11:44:15AM -0400, Gregory Haskins wrote:
> eventfd currently emits a POLLHUP wakeup on f_ops->release() to generate a
> "release" callback. This lets eventfd clients know if the eventfd is about
> to go away and is very useful particularl
On Mon, Jun 29, 2009 at 11:44:20AM -0400, Gregory Haskins wrote:
> DEASSIGN allows us to optionally disassociate an IRQFD from its underlying
> eventfd without destroying the eventfd in the process. This is useful
> for conditions like live-migration which may have an eventfd associated
> with a d
Signed-off-by: Jan Kiszka
---
configure |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure b/configure
index 88830aa..83faf93 100755
--- a/configure
+++ b/configure
@@ -2130,7 +2130,7 @@ configure_kvm() {
if test ! \( "$target_cpu" = "$cpu" -o \
\( "$target_c
On Mon, Jun 29, 2009 at 12:50:31PM -0300, Marcelo Tosatti wrote:
> > diff --git a/arch/x86/kvm/i8259.c b/arch/x86/kvm/i8259.c
> > index 148c52a..1851aec 100644
> > --- a/arch/x86/kvm/i8259.c
> > +++ b/arch/x86/kvm/i8259.c
> > @@ -548,6 +548,6 @@ struct kvm_pic *kvm_create_pic(struct kvm *kvm)
> >
Bugs item #2506814, was opened at 2009-01-14 11:38
Message generated for change (Comment added) made by mellen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2506814&group_id=180599
Please note that this message will contain a full copy of the comment th
Michael S. Tsirkin wrote:
> Look good. A couple of minor nits:
>
> On Mon, Jun 29, 2009 at 11:44:15AM -0400, Gregory Haskins wrote:
>
>> eventfd currently emits a POLLHUP wakeup on f_ops->release() to generate a
>> "release" callback. This lets eventfd clients know if the eventfd is about
>> to
On Mon, Jun 29, 2009 at 07:38:51PM +0300, Michael S. Tsirkin wrote:
> On Mon, Jun 29, 2009 at 12:50:31PM -0300, Marcelo Tosatti wrote:
> > > diff --git a/arch/x86/kvm/i8259.c b/arch/x86/kvm/i8259.c
> > > index 148c52a..1851aec 100644
> > > --- a/arch/x86/kvm/i8259.c
> > > +++ b/arch/x86/kvm/i8259.c
On Mon, Jun 29, 2009 at 12:52:24PM -0400, Gregory Haskins wrote:
> Michael S. Tsirkin wrote:
> > Look good. A couple of minor nits:
> >
> > On Mon, Jun 29, 2009 at 11:44:15AM -0400, Gregory Haskins wrote:
> >
> >> eventfd currently emits a POLLHUP wakeup on f_ops->release() to generate a
> >> "r
This series switches kvm_io_device to slots_lock from kvm->lock mutex,
and uses that to rework io bus API. This takes less locks on data path,
and uses less lines of code. These changes will also be useful to serve
as basis for Greg's iosignalfd work.
Signed-off-by: Michael S. Tsirkin
---
This w
slots_lock is taken everywhere when device ops are called.
Document this as we will use this to rework locking for io.
Signed-off-by: Michael S. Tsirkin
---
virt/kvm/iodev.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/virt/kvm/iodev.h b/virt/kvm/iodev.h
index 2c67f
switch coalesced mmio slots_lock. slots_lock is already taken for read
everywhere, so we only need to take it for write when changing zones.
This is in preparation to removing in_range and kvm->lock around it.
Signed-off-by: Michael S. Tsirkin
---
virt/kvm/coalesced_mmio.c | 12 ++--
switch pit creation to slots_lock. slots_lock is already taken for read
everywhere, so we only need to take it for write when creating pit.
This is in preparation to removing in_range and kvm->lock around it.
Signed-off-by: Michael S. Tsirkin
---
arch/x86/kvm/x86.c |4 ++--
1 files changed,
This changes bus accesses to use high-level kvm_io_bus_read/kvm_io_bus_write
functions. in_range now becomes unused so it is removed from device ops in
favor of read/write callbacks performing range checks internally.
This allows aliasing (mostly for in-kernel virtio), as well as better error
hand
Use slots_lock to protect device list on the bus. slots_lock is already
taken for read everywhere, so we only need to take it for write when
registering devices. This is in preparation to removing in_range and
kvm->lock around it.
Signed-off-by: Michael S. Tsirkin
---
arch/x86/kvm/i8254.c
Document kvm->lock nesting within kvm->slots_lock
Signed-off-by: Michael S. Tsirkin
---
virt/kvm/kvm_main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 728118f..afbf006 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/k
Hi
I am using kvm-86 on 2.6.28 and I am able to pass through most of my PCI
devices successfully. However, I do not see even the KVM BIOS output if I pass
through my VGA adapter.
I am doing -vga none, -nographic and -pcidevice host=xx:yy.z
Should I expect to see the kvm BIOS output? Is VGA
On Mon, Jun 29, 2009 at 05:54:46PM +0300, Avi Kivity wrote:
> On 06/29/2009 05:39 PM, Joerg Roedel wrote:
>> On Mon, Jun 29, 2009 at 04:41:17PM +0300, Avi Kivity wrote:
>>
>>> kerneloops.org shows tons of oopses on amd, see
>>> http://www.kerneloops.org/oops.php?number=79008. I suspect this ha
(Applies to kvm.git/master:4631e094)
The following is the latest attempt to fix the races in irqfd/eventfd, as
well as restore DEASSIGN support. For more details, please read the patch
headers. I've restored the slow-work variant of the logic as a separate
patch (5/5) so we can get a better idea
We need to plug some race conditions on eventfd shutdown. In order to
do this, we need to change the context in which the release notification
is delivered so that the wqh lock is now held. However, there is currently
code in the release callback that assumes it can sleep.
We have a slight chick
From: Davide Libenzi
The following patch changes the eventfd interface to de-couple the eventfd
memory context, from the file pointer instance.
Without such change, there is no clean way to racely free handle the
POLLHUP event sent when the last instance of the file* goes away.
Also, now the inte
eventfd currently emits a POLLHUP wakeup on f_ops->release() to generate a
"release" callback. This lets eventfd clients know if the eventfd is about
to go away and is very useful particularly for in-kernel clients. However,
until recently it is not possible to use this feature of eventfd in a
ra
This patch eliminates the mostly idle, dedicated work-queue in favor of
utilizing the slow-work thread pool. The downside to this approach is
that we add ~30 lines of complexity to irqfd to get rid of the thread,
but this may be a worthwhile tradeoff.
Note that a race is known to exist: the slow-
1 - 100 of 115 matches
Mail list logo
