Re: virtio_net sometimes didn't work
how to info pci in qemu?
the usb controller also used irq 11, i think the interrupt maybe cause by this.
i will modify qemu, ignore -usb,and try again.
i add some debug code, printk the ioaddr of vdev.
static int i;
/* reading the ISR has the effect of also clearing it so it's very
* important to save off the value. */
isr = ioread8(vp_dev-ioaddr + VIRTIO_PCI_ISR);
/* It's definitely not us if the ISR was not high */
if (!isr) {
i++;
if( i==1 ) {
printk(KERN_EMERG 2);
printk(KERN_EMERG ioaddr %p, vp_dev-ioaddr );
i=0;
}
return IRQ_NONE;
}
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
ACPI: PCI Interrupt :00:03.0[A] - Link [LNKC] - GSI 11 (level,
high) - IRQ 11
20ioaddr 0001c040020ioaddr 0001c040020ioaddr
0001c040020ioaddr 0001c040020ioaddr
0001c040020ioaddr 0001c040020ioaddr
0001c040020ioaddr 0001c040020ioaddr
0001c040020ioaddr 0001c0403irq 11: nobody cared (try booting
with the irqpoll option)
[c01457b0] __report_bad_irq+0x2b/0x69
[c0145979] note_interrupt+0x18b/0x1b2
[c01452a9] handle_IRQ_event+0x26/0x51
[c014537f] __do_IRQ+0xab/0xdc
[c0106445] do_IRQ+0x46/0x53
[c0104e8a] common_interrupt+0x1a/0x20
[c01276f2] __do_softirq+0x4f/0xc2
[c0127793] do_softirq+0x2e/0x32
[c0104f3c] apic_timer_interrupt+0x1c/0x30
[c02ae9fe] _spin_unlock_irqrestore+0x6/0x7
[c01455dc] setup_irq+0xab/0x108
[f8a9a09b] vp_interrupt+0x0/0x114 [virtio_pci]
[c01456ad] request_irq+0x74/0x90
[f8a9a2fb] virtio_pci_probe+0x14c/0x1c2 [virtio_pci]
[c01d4096] pci_device_probe+0x36/0x57
[c022f935] driver_probe_device+0x42/0x8b
[c022fa23] __driver_attach+0x4a/0x71
[c022f9d9] __driver_attach+0x0/0x71
[c022f45a] bus_for_each_dev+0x39/0x5b
[c022f89f] driver_attach+0x11/0x13
[c022f9d9] __driver_attach+0x0/0x71
[c022f17d] bus_add_driver+0x64/0xfd
[c01d41f9] __pci_register_driver+0x6c/0x8e
[f8830020] virtio_pci_init+0x20/0x34 [virtio_pci]
[c013b216] sys_init_module+0x1749/0x18c2
[c014ab9b] generic_file_read+0x9a/0xaf
[c0167011] vfs_read+0xa8/0x150
[c0103dcb] sysenter_past_esp+0x54/0x79
handlers:
[f8a9a09b] (vp_interrupt+0x0/0x114 [virtio_pci])
Disabling IRQ #11
the output of lspci -vv
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
Subsystem: Unknown device 1af4:1100
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR-
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
Subsystem: Unknown device 1af4:1100
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR-
Latency: 0
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE
[Natoma/Triton II] (prog-if 80 [Master])
Subsystem: Unknown device 1af4:1100
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR-
Latency: 0
Region 4: I/O ports at c000 [size=16]
00:01.2 USB Controller: Intel Corporation 82371SB PIIX3 USB
[Natoma/Triton II] (rev 01) (prog-if 00 [UHCI])
Subsystem: Unknown device 1af4:1100
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR-
Latency: 0
Interrupt: pin D routed to IRQ 11
Region 4: I/O ports at c020 [size=32]
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
Subsystem: Unknown device 1af4:1100
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR-
Interrupt: pin A routed to IRQ 9
00:02.0 VGA compatible controller: Cirrus Logic GD 5446 (prog-if 00
[VGA controller])
Subsystem: Unknown device 1af4:1100
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR-
Region 0: Memory at f000 (32-bit, prefetchable) [size=32M]
Region 1: Memory at f200 (32-bit, non-prefetchable) [size=4K]
Expansion ROM at f201 [disabled] [size=64K]
00:03.0 RAM memory: Unknown device 1af4:1002
Subsystem: Unknown device 1af4:0005
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF-
Re: virtio_net sometimes didn't work
On Wed, Feb 16, 2011 at 04:00:15PM +0800, lidong chen wrote:
how to info pci in qemu?
just type it at the monitor prompt.
the usb controller also used irq 11, i think the interrupt maybe cause by
this.
i will modify qemu, ignore -usb,and try again.
i add some debug code, printk the ioaddr of vdev.
static int i;
/* reading the ISR has the effect of also clearing it so it's very
* important to save off the value. */
isr = ioread8(vp_dev-ioaddr + VIRTIO_PCI_ISR);
/* It's definitely not us if the ISR was not high */
if (!isr) {
i++;
if( i==1 ) {
printk(KERN_EMERG 2);
printk(KERN_EMERG ioaddr %p, vp_dev-ioaddr );
i=0;
}
return IRQ_NONE;
}
OK, so we seem to get it right.
Try to stick the printout in qemu
case VIRTIO_PCI_ISR:
/* reading from the ISR also clears it. */
ret = vdev-isr;
vdev-isr = 0;
qemu_set_irq(proxy-pci_dev.irq[0], 0);
see whether it's the baloon device or the virtio net
device that gets to handle the reads.
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
ACPI: PCI Interrupt :00:03.0[A] - Link [LNKC] - GSI 11 (level,
high) - IRQ 11
20ioaddr 0001c040020ioaddr 0001c040020ioaddr
0001c040020ioaddr 0001c040020ioaddr
0001c040020ioaddr 0001c040020ioaddr
0001c040020ioaddr 0001c040020ioaddr
0001c040020ioaddr 0001c0403irq 11: nobody cared (try booting
with the irqpoll option)
[c01457b0] __report_bad_irq+0x2b/0x69
[c0145979] note_interrupt+0x18b/0x1b2
[c01452a9] handle_IRQ_event+0x26/0x51
[c014537f] __do_IRQ+0xab/0xdc
[c0106445] do_IRQ+0x46/0x53
[c0104e8a] common_interrupt+0x1a/0x20
[c01276f2] __do_softirq+0x4f/0xc2
[c0127793] do_softirq+0x2e/0x32
[c0104f3c] apic_timer_interrupt+0x1c/0x30
[c02ae9fe] _spin_unlock_irqrestore+0x6/0x7
[c01455dc] setup_irq+0xab/0x108
[f8a9a09b] vp_interrupt+0x0/0x114 [virtio_pci]
[c01456ad] request_irq+0x74/0x90
[f8a9a2fb] virtio_pci_probe+0x14c/0x1c2 [virtio_pci]
[c01d4096] pci_device_probe+0x36/0x57
[c022f935] driver_probe_device+0x42/0x8b
[c022fa23] __driver_attach+0x4a/0x71
[c022f9d9] __driver_attach+0x0/0x71
[c022f45a] bus_for_each_dev+0x39/0x5b
[c022f89f] driver_attach+0x11/0x13
[c022f9d9] __driver_attach+0x0/0x71
[c022f17d] bus_add_driver+0x64/0xfd
[c01d41f9] __pci_register_driver+0x6c/0x8e
[f8830020] virtio_pci_init+0x20/0x34 [virtio_pci]
[c013b216] sys_init_module+0x1749/0x18c2
[c014ab9b] generic_file_read+0x9a/0xaf
[c0167011] vfs_read+0xa8/0x150
[c0103dcb] sysenter_past_esp+0x54/0x79
handlers:
[f8a9a09b] (vp_interrupt+0x0/0x114 [virtio_pci])
Disabling IRQ #11
the output of lspci -vv
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
Subsystem: Unknown device 1af4:1100
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR-
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
Subsystem: Unknown device 1af4:1100
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR-
Latency: 0
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE
[Natoma/Triton II] (prog-if 80 [Master])
Subsystem: Unknown device 1af4:1100
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR-
Latency: 0
Region 4: I/O ports at c000 [size=16]
00:01.2 USB Controller: Intel Corporation 82371SB PIIX3 USB
[Natoma/Triton II] (rev 01) (prog-if 00 [UHCI])
Subsystem: Unknown device 1af4:1100
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR-
Latency: 0
Interrupt: pin D routed to IRQ 11
Region 4: I/O ports at c020 [size=32]
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
Subsystem: Unknown device 1af4:1100
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR-
Interrupt: pin A routed to IRQ 9
00:02.0 VGA compatible controller: Cirrus Logic GD 5446 (prog-if 00
[VGA controller])
Subsystem: Unknown device 1af4:1100
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66MHz-
[Bug 29232] New: [VT-d] VT-d device passthrough fail to guest
https://bugzilla.kernel.org/show_bug.cgi?id=29232 Summary: [VT-d] VT-d device passthrough fail to guest Product: Virtualization Version: unspecified Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: kvm AssignedTo: virtualization_...@kernel-bugs.osdl.org ReportedBy: xudong@intel.com CC: a...@redhat.com Regression: Yes Environment: Host OS : IA32E Guest OS : IA32E kvm.git Commit: a685b38e272587e644fedd37269ddb82df21c052 qemu-kvm Commit: 671d89d6411655bb4f8058ce6eb86bb0bb8ec978 Host Kernel Version: 2.6.38-rc4 Bug detailed description: -- When assign one PCI/e device to guest, qemu report error and guest can not boot up. If do hot-add device to guest, qemu will be killed. [root@vt-nhm9 qemu-kvm]# qemu-system-x86_64 -m 512 -smp 2 -device pci-assign,host=13:00.0 -net none -hda /path/rhel5.img assigned_dev_pci_read: pread failed, ret = 0 errno = 22 Reproduce steps: 1) install latest kvm and qemu-kvm 2) qemu-system-x86_64 -m 512 -smp 2 -device pci-assign,host=13:00.0 -net none -hda /path/rhel5.img 3) there will be a qemu error -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] KVM: VMX: Short circuit STI; HLT while an interrupt is pending
On 02/15/2011 10:36 PM, Marcelo Tosatti wrote:
On Mon, Feb 14, 2011 at 04:42:16PM +0200, Avi Kivity wrote:
Short-circuit an STI; HLT sequence while an interrupt is pending:
instead of halting, re-entering the guest, and exiting immediately
on an interrupt window exit, go directly to the last step.
Saves a vmexit on workloads where interrupts are received synchronously;
an example is a disk backed by the host page cache where there is no
latency (from the guest's point of view) between the request and fulfilment.
Signed-off-by: Avi Kivitya...@redhat.com
---
arch/x86/kvm/vmx.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index ee1cd1a..541da0e 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3437,6 +3437,15 @@ static int handle_interrupt_window(struct kvm_vcpu
*vcpu)
static int handle_halt(struct kvm_vcpu *vcpu)
{
skip_emulated_instruction(vcpu);
+ /*
+ * Short-circuit an STI; HLT sequence while an interrupt is pending:
+ * instead of halting, re-entering the guest, and exiting immediately
+ * on an interrupt window exit, go directly to the last step.
+ */
+ if ((to_vmx(vcpu)-cpu_based_vm_exec_control
+ CPU_BASED_VIRTUAL_INTR_PENDING)
+ (kvm_get_rflags(vcpu) X86_EFLAGS_IF))
+ return handle_interrupt_window(vcpu);
return kvm_emulate_halt(vcpu);
}
Why does the normal vcpu entry path fails to inject the interrupt? Because
after halt,
KVM_REQ_EVENT is not set?
Yes. Also, we want to clear CPU_BASED_VIRTUAL_INTR_PENDING.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: Start lock documentation
On 02/15/2011 07:08 PM, Jan Kiszka wrote: On 2011-02-15 17:44, Marcelo Tosatti wrote: On Wed, Feb 09, 2011 at 03:11:28PM +0100, Jan Kiszka wrote: The goal of this document shall be - overview of all locks used in KVM core - provide details on the scope of each lock - explain the lock type, specifically of a raw spin locks - provide a lock ordering guide Start with one dependency chain and two locks. Signed-off-by: Jan Kiszkajan.kis...@siemens.com --- Documentation/kvm/locking.txt | 30 ++ 1 files changed, 30 insertions(+), 0 deletions(-) create mode 100644 Documentation/kvm/locking.txt diff --git a/Documentation/kvm/locking.txt b/Documentation/kvm/locking.txt new file mode 100644 index 000..23f9092 --- /dev/null +++ b/Documentation/kvm/locking.txt @@ -0,0 +1,30 @@ +KVM Lock Overview += + +1. Acquisition Orders +- + +kvm_lock ++- kvm::srcu / kvm::lock ++- kvm::slots_lock ++- kvm::mmu_lock +... Its not easy to understand what you mean here. What kvm_lock has to do with the ordering described below it? kvm_lock is the head of this chain, i.e. there are code paths where it is taken first, then kvm::lock, etc. Right, but it is not mandatory for most fields protected by the lock. So we have - which locks _may_ nest, and how - which locks _must_ nest, and how, to access a particular field (may depend on type of access for rcu) -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
KVM Test report, kernel a685b38... qemu 671d89d...
Hi, all, This is KVM test result against kvm.git a685b38e272587e644fedd37269ddb82df21c052, and qemu-kvm.git 671d89d6411655bb4f8058ce6eb86bb0bb8ec978. Currently qemu-kvm can build successfully on RHEL5, and Qcow image create failure issue also got fixed, our nightly testing resumed. One VT-d device assignment issue opened on latest KVM. New issue: 1. [VT-d] VT-d device passthrough fail to guest https://bugzilla.kernel.org/show_bug.cgi?id=29232 Fixed issues: 1. [KVM] Noacpi Windows guest can not boot up on 32bit KVM host https://bugzilla.kernel.org/show_bug.cgi?id=21402 2. [Qemu-kvm] qemu-img fail to create qcow image https://bugs.launchpad.net/bugs/706766 Three old Issues: 1. ltp diotest running time is 2.54 times than before https://sourceforge.net/tracker/?func=detailaid=2723366group_id=180599atid=893831 2. 32bits Rhel5/FC6 guest may fail to reboot after installation https://sourceforge.net/tracker/?func=detailatid=893831aid=1991647group_id=180599 3. perfctr wrmsr warning when booting 64bit RHEl5.3 https://sourceforge.net/tracker/?func=detailaid=2721640group_id=180599atid=893831 Best Regards, Xudong Hao -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM Test report, kernel a685b38... qemu 671d89d...
On 02/16/2011 11:05 AM, Hao, Xudong wrote: Hi, all, This is KVM test result against kvm.git a685b38e272587e644fedd37269ddb82df21c052, and qemu-kvm.git 671d89d6411655bb4f8058ce6eb86bb0bb8ec978. Currently qemu-kvm can build successfully on RHEL5, and Qcow image create failure issue also got fixed, our nightly testing resumed. One VT-d device assignment issue opened on latest KVM. New issue: 1. [VT-d] VT-d device passthrough fail to guest https://bugzilla.kernel.org/show_bug.cgi?id=29232 Alex? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On Tue, Feb 15, 2011 at 05:07:07PM -0600, Anthony Liguori wrote:
On 02/15/2011 11:11 AM, Blue Swirl wrote:
On Mon, Feb 14, 2011 at 11:47 PM, Anthony Liguorianth...@codemonkey.ws
wrote:
Any device we expose to the user through -device needs to maintain a
compatible interface forever. For our own sanity, I think we should try to
expose as little as possible.
Restricting the users from adding arbitrary devices is a different
issue. Dropping qdev support to prevent user from adding the device
seems draconian, what's wrong with no_user flag?
I think you're missing my point.
It should be possible to make a device qdev without exposing it
via a factory interface. Today it's all or nothing and that's the
part I dislike.
I think you are mixing too different thing here. The purpose of qdev (or
other device tree implementation) should be 1. to provide factory
interface. 2 to keep track on how devices are interconnected (or in
other words to keep track of device tree). But you are constantly
talking about how qdev should be object oriented way to build devices
themselves and I think this shouldn't be part of qdev at all.
no_user is a hack. We can do better.
A good example of a device that we should model through qdev but not expose
via -device is actually SerialState.
You wouldn't want users to add any serial ports? What should be do
with serial ports then, always enable a full set of ports? How would
the user use them?
No, users should be able to create ISASerialDevice,
MMIOSerialDevice, but not UART16650A. Here's what I'm talking
about:
class ISASerialDevice : public ISADevice
{
UART16650A uart;
};
class MMIOSerialDevice : public PlatformDevice
{
UART16650A uart;
};
There should be factory interfaces for ISASeriaDevice and
MMIOSerialDevice but not UART16650A.
This is OK and I do not disagree with this, but this is not what qdev
should be about. Qdev should be about allowing user to specify how and
which classes (read devices) should be instantiated at how they should
be interconnected. Taking yous example above qdev should allow to say: I
want to instantiate ISASerialDevice on bus object isabus0 (which was
instantiated before). It should claim resources A, B and C from that
bus. I also what instantiate MMIOSerialDevice on bus object systembus
claiming resource Z.
--
Gleb.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 15
On 02/16/2011 01:13 AM, Anthony Liguori wrote:
On 02/15/2011 10:26 AM, Chris Wright wrote:
QAPI and QMP
- Anthony adding a new wiki page to describe all of this
http://wiki.qemu.org/Features/QAPI
[ 'change', {'device': 'str', 'target': 'str'}, {'arg': 'str'}, 'none' ]
-
void qmp_change(const char *device, const char *target, bool has_arg,
const char *arg, Error **errp);
AFAICT a json-string allows embedded NULs ('\'). There translate to
UTF-8 as '\0', terminating your char *s. Either we use some
length/pointer structure, or the parser has to look for them and kill
them, and we have to specify them as verboten.
BlockDeviceInfo *qmp_query_block_device_info(const char *device, Error **errp)
{
BlockDeviceInfo *info;
BlockDriverState *bs;
Error *local_err = NULL;
bs = bdrv_find(device,local_err);
if (local_err) {
error_propagate(errp, local_err);
return NULL;
}
info-file = qemu_strdup(bs-filename);
info-ro = bs-readonly;
info-drv = qemu_strdup(bs-drv);
info-encrypted = bs-encrypted;
if (bs-backing_file[0]) {
info-has_backing_file = true;
info-backing_file = qemu_strdup(info-backing_file);
}
return info;
}
So, info and all its pointer-typed members are required to be
qemu_free() compatible, with just a single pointer pointing to an
object, and generated code will qemu_free() everything?
Recommend translating '-' in identifiers to '_' so we can use '-' in the
schema as a word separator.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Slow disk IO on virtio kvm guests with Centos 5.5 as hypervisor
On Tue, 15 Feb 2011 15:50:00 +, Stefan Hajnoczi stefa...@gmail.com wrote: On Tue, Feb 15, 2011 at 10:15 AM, Thomas Broda tho...@bassfimass.de wrote: Using O_DIRECT, performance went down to 11 MB/s on the hypervisor... Hmm...can you restate that as: host X MB/s guest Y MB/s Trying dd with oflag=direct an of=/dev/vg0/lvtest (directly on the KVM hypervisor) yielded a result of 11MB/s. If I try this on the guest with /dev/vda1 as output device, results are between 1.9MB/s and 7.7MB/s, usually around 3.5MB/s. To sum it up: Host: 11 MB/s Guest: 3.5 MB/s I've checked the RAID controller in the meantime. It's a HP Smart Array P400. Write Caching is switched off since the contoller has no BBU (yet). Could it be related to this? -- Thomas -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Slow disk IO on virtio kvm guests with Centos 5.5 as hypervisor
On Wed, Feb 16, 2011 at 12:50 PM, Thomas Broda tho...@bassfimass.de wrote: On Tue, 15 Feb 2011 15:50:00 +, Stefan Hajnoczi stefa...@gmail.com wrote: On Tue, Feb 15, 2011 at 10:15 AM, Thomas Broda tho...@bassfimass.de wrote: Using O_DIRECT, performance went down to 11 MB/s on the hypervisor... Hmm...can you restate that as: host X MB/s guest Y MB/s Trying dd with oflag=direct an of=/dev/vg0/lvtest (directly on the KVM hypervisor) yielded a result of 11MB/s. If I try this on the guest with /dev/vda1 as output device, results are between 1.9MB/s and 7.7MB/s, usually around 3.5MB/s. To sum it up: Host: 11 MB/s Guest: 3.5 MB/s I've checked the RAID controller in the meantime. It's a HP Smart Array P400. Write Caching is switched off since the contoller has no BBU (yet). Could it be related to this? The disabled write cache will result in slow writes so your host benchmark result is low on an absolute scale. However, the relative Guest/Host performance is very poor here (3.5/11 = 31%). A number of performance improvements have been made to KVM and Centos 5.5 does not contain them because it is too old. If you want to see a more current reflection of KVM performance, you could try Fedora 14 host and guest. The components that matter are: host kernel, qemu-kvm userspace, and guest kernel. Stefan -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 15
On 02/16/2011 04:24 AM, Avi Kivity wrote:
On 02/16/2011 01:13 AM, Anthony Liguori wrote:
On 02/15/2011 10:26 AM, Chris Wright wrote:
QAPI and QMP
- Anthony adding a new wiki page to describe all of this
http://wiki.qemu.org/Features/QAPI
[ 'change', {'device': 'str', 'target': 'str'}, {'arg': 'str'},
'none' ]
-
void qmp_change(const char *device, const char *target, bool
has_arg, const char *arg, Error **errp);
AFAICT a json-string allows embedded NULs ('\'). There translate
to UTF-8 as '\0', terminating your char *s. Either we use some
length/pointer structure, or the parser has to look for them and kill
them, and we have to specify them as verboten.
I feel like it would be safer for us to not accept strings with embedded
NULs. There's no way we're going to consistently handle this correctly
in QEMU since we expect NUL terminated strings. They won't work for any
of the standard C functions either.
BlockDeviceInfo *qmp_query_block_device_info(const char *device, Error
**errp)
{
BlockDeviceInfo *info;
BlockDriverState *bs;
Error *local_err = NULL;
bs = bdrv_find(device,local_err);
if (local_err) {
error_propagate(errp, local_err);
return NULL;
}
info-file = qemu_strdup(bs-filename);
info-ro = bs-readonly;
info-drv = qemu_strdup(bs-drv);
info-encrypted = bs-encrypted;
if (bs-backing_file[0]) {
info-has_backing_file = true;
info-backing_file = qemu_strdup(info-backing_file);
}
return info;
}
So, info and all its pointer-typed members are required to be
qemu_free() compatible, with just a single pointer pointing to an
object, and generated code will qemu_free() everything?
Yes.
Recommend translating '-' in identifiers to '_' so we can use '-' in
the schema as a word separator.
Already do that and we make extensive use of that in the schema.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 15
On (Tue) 15 Feb 2011 [17:13:13], Anthony Liguori wrote: On 02/15/2011 10:26 AM, Chris Wright wrote: revisit new - old migration - Amit offers virtio-serial patches and some legwork So, to me, migration correctness trumps compatibility. I don't think compatibility is useful if it means that a guest may fail during migration. We have subsections as a way to support the cases where it's safe to migrate to an old version only if a feature is not being used or a corner case is not currently happening. This is the best way to approach the problem. If a subsection won't work, that means you want to migrate when you're completely sure that migrating will break a guest. That doesn't seem reasonable at all to me. I think in the last discussion on Amit's patches, I had suggested that subsections could be used to allow migration when there wasn't any queued data. I think this is the best we can do while preserving correctness. The only problem is that virtio hasn't been converted over to vmstate, which is necessary for subsections. Amit -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 15
On 02/16/2011 08:39 AM, Amit Shah wrote: On (Tue) 15 Feb 2011 [17:13:13], Anthony Liguori wrote: On 02/15/2011 10:26 AM, Chris Wright wrote: revisit new - old migration - Amit offers virtio-serial patches and some legwork So, to me, migration correctness trumps compatibility. I don't think compatibility is useful if it means that a guest may fail during migration. We have subsections as a way to support the cases where it's safe to migrate to an old version only if a feature is not being used or a corner case is not currently happening. This is the best way to approach the problem. If a subsection won't work, that means you want to migrate when you're completely sure that migrating will break a guest. That doesn't seem reasonable at all to me. I think in the last discussion on Amit's patches, I had suggested that subsections could be used to allow migration when there wasn't any queued data. I think this is the best we can do while preserving correctness. The only problem is that virtio hasn't been converted over to vmstate, which is necessary for subsections. Then it needs to be converted. Regards, Anthony Liguori Amit -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM Test report, kernel a685b38... qemu 671d89d...
On Wed, 2011-02-16 at 11:10 +0200, Avi Kivity wrote: On 02/16/2011 11:05 AM, Hao, Xudong wrote: Hi, all, This is KVM test result against kvm.git a685b38e272587e644fedd37269ddb82df21c052, and qemu-kvm.git 671d89d6411655bb4f8058ce6eb86bb0bb8ec978. Currently qemu-kvm can build successfully on RHEL5, and Qcow image create failure issue also got fixed, our nightly testing resumed. One VT-d device assignment issue opened on latest KVM. New issue: 1. [VT-d] VT-d device passthrough fail to guest https://bugzilla.kernel.org/show_bug.cgi?id=29232 Extremely reproducible. Looks like it's a result of this kernel change: commit 47970b1b2aa64464bc0a9543e86361a622ae7c03 Author: Chris Wright chr...@sous-sol.org Date: Thu Feb 10 15:58:56 2011 -0800 pci: use security_capable() when checking capablities during config space re Eric Paris noted that commit de139a3 (pci: check caps from sysfs file open to read device dependent config space) caused the capability check to bypass security modules and potentially auditing. Rectify this by calling security_capable() when checking the open file's capabilities for config space reads. Reported-by: Eric Paris epa...@redhat.com Signed-off-by: Chris Wright chr...@sous-sol.org Signed-off-by: James Morris jmor...@namei.org Chris, why isn't this working for us? Thanks, Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM Test report, kernel a685b38... qemu 671d89d...
On Wed, 2011-02-16 at 08:01 -0700, Alex Williamson wrote: On Wed, 2011-02-16 at 11:10 +0200, Avi Kivity wrote: On 02/16/2011 11:05 AM, Hao, Xudong wrote: Hi, all, This is KVM test result against kvm.git a685b38e272587e644fedd37269ddb82df21c052, and qemu-kvm.git 671d89d6411655bb4f8058ce6eb86bb0bb8ec978. Currently qemu-kvm can build successfully on RHEL5, and Qcow image create failure issue also got fixed, our nightly testing resumed. One VT-d device assignment issue opened on latest KVM. New issue: 1. [VT-d] VT-d device passthrough fail to guest https://bugzilla.kernel.org/show_bug.cgi?id=29232 Extremely reproducible. Looks like it's a result of this kernel change: commit 47970b1b2aa64464bc0a9543e86361a622ae7c03 Author: Chris Wright chr...@sous-sol.org Date: Thu Feb 10 15:58:56 2011 -0800 pci: use security_capable() when checking capablities during config space re Eric Paris noted that commit de139a3 (pci: check caps from sysfs file open to read device dependent config space) caused the capability check to bypass security modules and potentially auditing. Rectify this by calling security_capable() when checking the open file's capabilities for config space reads. Reported-by: Eric Paris epa...@redhat.com Signed-off-by: Chris Wright chr...@sous-sol.org Signed-off-by: James Morris jmor...@namei.org Chris, why isn't this working for us? Thanks, Ah, I see now that this has already been fixed. The above commit was reverted in f00eaeea7a42b5ea327e9ce8839cb0b53d3bdb4e and a corrected version applied in a628e7b87e100befac9702aa0c3b9848a7685e49. So it should be fixed on the next kvm.git merge. Thanks, Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Slow disk IO on virtio kvm guests with Centos 5.5 as hypervisor
On Wed, 16 Feb 2011 13:11:46 +, Stefan Hajnoczi stefa...@gmail.com wrote: A number of performance improvements have been made to KVM and Centos 5.5 does not contain them because it is too old. If you want to see a more current reflection of KVM performance, you could try Fedora 14 host and guest. I will try Fedora then. Thanks for helping! -- Thomas -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Why exit on MSR_STAR and friends?
Hi, In the recent KVM forum, Marcelo Tosatti presented some KVM performance improvements. One of them (page 17 of the presentation) was about the MSRs used by SYSCALL: MSR_STAR, MSR_LSTAR, MSR_CSTAR (and also MSR_SYSCALL_MASK). He said that Guests have direct access to these MSRs, and this is why KVM needs to restore their original host value when returning to user space (they aren't used in the kernel, so there's no reason to restore them earlier). I was suprised, then, to discover that KVM doesn't add these MSRs to the MSR bitmap, so when the guest changes these MSR values, or even reads them, we cause an exit - both on read and on write of these MSRs. I was wondering why these exits are needed. I can maybe guess why an exit is needed on write - just to save the guest value so we don't need to read it when going back to user space. Is this a good optimization because we assume that the guest very rarely changes these MSRs? Or is there another explanation as to why these exits are needed? But I can't even guess why an exit is needed on read... If you're curious why I noticed these exits - I was running a nested KVM (L0's guest L1 is KVM, that itself has a guest L2). Whenever L2 does something that L1 needs to handle in user space (e.g., PIO), L1 does all these MSR reads and writes, and we get exits for each of them - many of those exits for each L2 PIO :( Thanks, Nadav Har'El. -- Nadav Har'El| Wednesday, Feb 16 2011, 12 Adar I 5771 n...@math.technion.ac.il |- Phone +972-523-790466, ICQ 13349191 |Support bacteria - they're the only http://nadav.harel.org.il |culture some people have! -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM Test report, kernel a685b38... qemu 671d89d...
* Alex Williamson (alex.william...@redhat.com) wrote:
On Wed, 2011-02-16 at 11:10 +0200, Avi Kivity wrote:
On 02/16/2011 11:05 AM, Hao, Xudong wrote:
Hi, all,
This is KVM test result against kvm.git
a685b38e272587e644fedd37269ddb82df21c052, and qemu-kvm.git
671d89d6411655bb4f8058ce6eb86bb0bb8ec978.
Currently qemu-kvm can build successfully on RHEL5, and Qcow image create
failure issue also got fixed, our nightly testing resumed. One VT-d
device assignment issue opened on latest KVM.
New issue:
1. [VT-d] VT-d device passthrough fail to guest
https://bugzilla.kernel.org/show_bug.cgi?id=29232
Extremely reproducible. Looks like it's a result of this kernel change:
commit 47970b1b2aa64464bc0a9543e86361a622ae7c03
Author: Chris Wright chr...@sous-sol.org
Date: Thu Feb 10 15:58:56 2011 -0800
pci: use security_capable() when checking capablities during config space
re
Eric Paris noted that commit de139a3 (pci: check caps from sysfs file
open to read device dependent config space) caused the capability check
to bypass security modules and potentially auditing. Rectify this by
calling security_capable() when checking the open file's capabilities
for config space reads.
Reported-by: Eric Paris epa...@redhat.com
Signed-off-by: Chris Wright chr...@sous-sol.org
Signed-off-by: James Morris jmor...@namei.org
Chris, why isn't this working for us? Thanks,
It's a broken patch, the fix is floating about. Linus reverted it and I
supplied this patch after the revert:
From 683034fca7b8c322f87b8b4f664f1ae0b5fc Mon Sep 17 00:00:00 2001
From: Chris Wright chr...@sous-sol.org
Date: Mon, 14 Feb 2011 19:12:00 -0500
Subject: [PATCH] pci: use security_capable() when checking capablities during
config space read
This reintroduces commit 47970b1b which was subsequently reverted
as f00eaeea. The original change was broken and caused X startup
failures and generally made privileged processes incapable of reading
device dependent config space. The normal capable() interface returns
true on success, but the LSM interface returns 0 on success. This thinko
is now fixed in this patch, and has been confirmed to work properly.
So, once again...Eric Paris noted that commit de139a3 (pci: check caps
from sysfs file open to read device dependent config space) caused the
capability check to bypass security modules and potentially auditing.
Rectify this by calling security_capable() when checking the open file's
capabilities for config space reads.
Reported-by: Eric Paris epa...@redhat.com
Tested-by: Dave Young hidave.darks...@gmail.com
Acked-by: James Morris jmor...@namei.org
Cc: Dave Airlie airl...@gmail.com
Cc: Alex Riesen raa.l...@gmail.com
Cc: Sedat Dilek sedat.di...@googlemail.com
Cc: Linus Torvalds torva...@linux-foundation.org
Signed-off-by: Chris Wright chr...@sous-sol.org
---
drivers/pci/pci-sysfs.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 8ecaac9..ea25e5b 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -23,6 +23,7 @@
#include linux/mm.h
#include linux/fs.h
#include linux/capability.h
+#include linux/security.h
#include linux/pci-aspm.h
#include linux/slab.h
#include pci.h
@@ -368,7 +369,7 @@ pci_read_config(struct file *filp, struct kobject *kobj,
u8 *data = (u8*) buf;
/* Several chips lock up trying to read undefined config space */
- if (cap_raised(filp-f_cred-cap_effective, CAP_SYS_ADMIN)) {
+ if (security_capable(filp-f_cred, CAP_SYS_ADMIN) == 0) {
size = dev-cfg_size;
} else if (dev-hdr_type == PCI_HEADER_TYPE_CARDBUS) {
size = 128;
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 29232] [VT-d] VT-d device passthrough fail to guest
https://bugzilla.kernel.org/show_bug.cgi?id=29232 alex.william...@redhat.com changed: What|Removed |Added CC||alex.william...@redhat.com --- Comment #1 from alex.william...@redhat.com 2011-02-16 16:43:26 --- This will be fixed with the 2.6.38-rc5 merge of kvm.git. Commit 47970b1b was bad and later reverted in f00eaeea. A corrected version was added in 683034fca. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] KVM: VMX: Short circuit STI; HLT while an interrupt is pending
On Wed, Feb 16, 2011 at 11:01:47AM +0200, Avi Kivity wrote:
On 02/15/2011 10:36 PM, Marcelo Tosatti wrote:
On Mon, Feb 14, 2011 at 04:42:16PM +0200, Avi Kivity wrote:
Short-circuit an STI; HLT sequence while an interrupt is pending:
instead of halting, re-entering the guest, and exiting immediately
on an interrupt window exit, go directly to the last step.
Saves a vmexit on workloads where interrupts are received synchronously;
an example is a disk backed by the host page cache where there is no
latency (from the guest's point of view) between the request and
fulfilment.
Signed-off-by: Avi Kivitya...@redhat.com
---
arch/x86/kvm/vmx.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index ee1cd1a..541da0e 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3437,6 +3437,15 @@ static int handle_interrupt_window(struct kvm_vcpu
*vcpu)
static int handle_halt(struct kvm_vcpu *vcpu)
{
skip_emulated_instruction(vcpu);
+ /*
+ * Short-circuit an STI; HLT sequence while an interrupt is pending:
+ * instead of halting, re-entering the guest, and exiting immediately
+ * on an interrupt window exit, go directly to the last step.
+ */
+ if ((to_vmx(vcpu)-cpu_based_vm_exec_control
+ CPU_BASED_VIRTUAL_INTR_PENDING)
+ (kvm_get_rflags(vcpu) X86_EFLAGS_IF))
+ return handle_interrupt_window(vcpu);
return kvm_emulate_halt(vcpu);
}
Why does the normal vcpu entry path fails to inject the interrupt? Because
after halt,
KVM_REQ_EVENT is not set?
Yes. Also, we want to clear CPU_BASED_VIRTUAL_INTR_PENDING.
Is there a reason why it cannot be handled in the main loop?
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND][PATCH] qemu-kvm: Drop vga dirty logging workarounds
On Mon, Feb 14, 2011 at 07:19:20PM +0100, Jan Kiszka wrote: These diffs to upstream should all date back to the days qemu-kvm supported vga dirty logging with restricted/broken kvm kernel modules. We no longer do, so there is no need for those workarounds. Even worse they can trigger internal bug checks these days: BUG: kvm_dirty_pages_log_change: invalid parameters 000a8000-000a Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- When the log_start/stop callbacks are upstream and about to be merged back, you likely want this patch to be applied first. :) Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
KVM, Entropy and Windows
Hello all, I believe I am hitting a problem on one of our Windows 2003 KVM guests were I believe it is running out of Entropy and causing SSL issues. I see that there is a module called virtio-rng which I believe passes the HW entropy source through to the guest but does this work on Windows as-well ? If it doesn't any ideas on how I can increase the amount of entropy being generated on a headless system ? or even monitor entropy on a Windows system ? Thank you in advance. -- Thanks, Phil -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
the fr-ca keymap is not working...
Hi... A lot of keys were not working when I used the fr-ca layout in a KVM guest. I have updated my /usr/share/kvm/keymaps/fr-ca and added the following entries at the ends to make it works. The only keys that still behave strangely are dead_xxxkeys. #hardcoded keys minus 0x0c numbersign 0x29 Eacute 0x35 shift equal 0xd semicolon 0x27 colon 0x27 shift less 0x2b greater 0x2b shift comma 0x33 apostrophe 0x33 shift period 0x34 shift Thanks Pierre-Yves Langlois -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Passthrough of 2 PCI devices works 80% (Kernel 2.6.37, Debian Squeeze, Win7 VM)
On Tue, 2011-02-15 at 20:57 +, Da Powah wrote: Hi, i`ve got a question about pci passthrogh of 2 pci devices (2x DVB-S2 PCI cards with Saa7146 PCI Bridge from Technotrend: S2-3200). I am using squeeze with a 2.6.37 selfcompiled Kernel. I want to passthrough both devices to a virtual machine (Win7) an get problems. If i passthrough one device (other is unplugged) it works flawlessly. I'm glad to hear it works one at a time. It's oddly specific that you mention it works if the other card is unplugged, can you only physically have one card plugged in at a time for it to work (ie. if you have both cards physically installed, but only one assigned to the guest, does it work)? Can you simultaneously assign each card to separate guests and they work? The time i add both devices and pass them through i am still able to start the VM and i don`t see anything in the error logs. Even Windows7 or XP detects both cards and installs the driver correctly (actual BDA Driver, standard broadcast video driver). But the time i want to acces the cards, i get a BSOD - caused by the driver. I'll toss out a dumb question, can the drivers for Win7 or WinXP drive two cards when running on bare metal? Does a Linux guest work with both cards better? I already aligned the io memory of both devices, checked the libvirt logs, kernel and syslogs - there is nothing for a kvm newbe that seems to be odd. The kernel is compiled with all the mentioned kernel options of the linux-kvm.org page - except that i compiled the stub driver as module. One card alone (both tried separately) is working w/o any flaws. Kvm is able to pass through all devices behind a PCI Bridge - so take a look at the 03:0x.0 devices below: i use those 2 sat boards only in 3 PCI slots. What am i able to do to make deeper analysis or to solve the problem ? If each card works when assigned separately and you can boot the guest with both cards assign and the drivers load and device manager isn't reporting any errors, I'd lean towards a Windows driver issue. There is some debugging you can enable in hw/device-assignment.c that might shed some light on what the drivers is trying to do before the BSOD. What error is the BSOD reporting? Are you using the latest qemu-kvm.git? Thanks, Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] Provide control over unmapped pages (v4)
On Mon, Feb 14, 2011 at 2:33 AM, Balbir Singh bal...@linux.vnet.ibm.com wrote: * MinChan Kim minchan@gmail.com [2011-02-10 14:41:44]: I don't know why the part of message is deleted only when I send you. Maybe it's gmail bug. I hope mail sending is successful in this turn. :) On Thu, Feb 10, 2011 at 2:33 PM, Minchan Kim minchan@gmail.com wrote: Sorry for late response. On Fri, Jan 28, 2011 at 8:18 PM, Balbir Singh bal...@linux.vnet.ibm.com wrote: * MinChan Kim minchan@gmail.com [2011-01-28 16:24:19]: But the assumption for LRU order to change happens only if the page cannot be successfully freed, which means it is in some way active.. and needs to be moved no? 1. holded page by someone 2. mapped pages 3. active pages 1 is rare so it isn't the problem. Of course, in case of 3, we have to activate it so no problem. The problem is 2. 2 is a problem, but due to the size aspects not a big one. Like you said even lumpy reclaim affects it. May be the reclaim code could honour may_unmap much earlier. Even if it is, it's a trade-off to get a big contiguous memory. I don't want to add new mess. (In addition, lumpy is weak by compaction as time goes by) What I have in mind for preventing LRU ignore is that put the page into original position instead of head of lru. Maybe it can help the situation both lumpy and your case. But it's another story. How about the idea? I borrow the idea from CFLRU[1] - PCFLRU(Page-Cache First LRU) When we allocates new page for page cache, we adds the page into LRU's tail. When we map the page cache into page table, we rotate the page into LRU's head. So, inactive list's result is following as. M.P : mapped page N.P : none-mapped page HEAD-M.P-M.P-M.P-M.P-N.P-N.P-N.P-N.P-N.P-TAIL Admin can set threshold window size which determines stop reclaiming none-mapped page contiguously. I think it needs some tweak of page cache/page mapping functions but we can use kswapd/direct reclaim without change. Also, it can change page reclaim policy totally but it's just what you want, I think. I am not sure how this would work, moreover the idea behind min_unmapped_pages is to keep sufficient unmapped pages around for the FS metadata and has been working with the existing code for zone reclaim. What you propose is more drastic re-org of the LRU and I am not sure I have the apetite for it. Yes. My suggestion can change LRU order totally but it can't meet your goal so it was a bad idea. Sorry for bothering you. I can add reviewed-by [1/3],[2/3], but still doubt [3/3]. LRU ordering problem as I mentioned is not only your problem but it's general problem these day(ex, more aggressive compaction/lumpy reclaim). So we may need general solution if it is real problem. Okay. I don't oppose your approach from now on until I can prove how much LRU-reordering makes bad effect. (But still I raise my eyebrow on implementation [3/3] but I don't oppose it until I suggest better approach) Thanks. -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu compiling error on ppc64: kvm.c:81: error: 'struct kvm_sregs' has no member named 'pvr'
On 02/15/2011 05:59 PM, Dushyant Bansal wrote: 2. How to configure makefiles to get output of printk statements inside kvm/arch/powerpc/kvm/trace.h Better don't make them printks - just use the tracing framework. I'd write up a small howto here myself, but I'm pretty much on the jump to my plane for vacation. Avi, could you please guide him a bit on how to get data out of tracepoints? Thanks for the quick reply :) I have added some more trace parameters in the tracing framework and currently, it is working fine. 1. Add new field in struct kvm_vcpu_stat (kvm_host.h) 2. Add corresponding entry in struct kvm_stats_debugfs_item debugfs_entries[] (book3s.c) 3. Increment or Decrement that field where ever necessary. Those aren't tracepoints; they're deprecated debug statistics. For tracepoints, see include/trace/events/kvm.h (general kvm tracepoints) arch/powerpc/kvm/trace.h (ppc specific tracepoints) arch/powerpc/kvm/book3s_mmu_hpte.c (examples of use, look for trace_kvm_*) Documentation/trace/tracepoints.txt (documentation, likely outdated) -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
