Re: [Qemu-devel] [PATCH 09/12] kvm: ppc: Drop KVM_CAP build dependencies
On 2011-06-10 20:32, Eduardo Habkost wrote:
On Wed, Jun 08, 2011 at 04:11:03PM +0200, Jan Kiszka wrote:
snip
@@ -217,7 +209,6 @@ int kvm_arch_get_registers(CPUState *env)
return ret;
}
-#ifdef KVM_CAP_PPC_BOOKE_SREGS
if (sregs.u.e.features KVM_SREGS_E_BASE) {
env-spr[SPR_BOOKE_CSRR0] = sregs.u.e.csrr0;
env-spr[SPR_BOOKE_CSRR1] = sregs.u.e.csrr1;
Which tree/commit-id did you use as base for this series? This chunk
doesn't apply on uq/master (patch 11/12, on the other hand, doesn't
apply against qemu.git/master, only uq/master).
After some patch hunting, I found out that the series apply cleanly if I
apply it against a manual merge of uq/master and qemu.git/master, but
maybe there is a branch that already had all the dependencies, that I
didn't know about?
As I wrote in the introduction, the series requires a trivial rebase of
uq/master over current qemu master (because of this patch).
Jan
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH-v3 2/2] kvm: Fix unused-but-set-variable warning
On 2011-06-10 20:46, Stefan Hajnoczi wrote: On Tue, May 31, 2011 at 09:53:49AM +0200, Christophe Fergeau wrote: Based on a patch from Hans de Goede hdego...@redhat.com This warning is new in gcc 4.6. Acked-by: Amit Shah amit.s...@redhat.com Signed-off-by: Christophe Fergeau cferg...@redhat.com --- target-i386/kvm.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) Thanks, applied to the trivial patches tree: http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/trivial-patches Please skip this one. I'll post a patch fixing the issue that this warning revealed (lacking save/restore of FPU OP, IP and DP). Jan signature.asc Description: OpenPGP digital signature
[Qemu-devel] [PATCH] Reset system before loadvm
From: Jan Kiszka jan.kis...@siemens.com In case we load the vmstate during incoming migration, we start from a clean, default machine state as we went through system reset before. But if we load from a snapshot, the machine can be in any state. That can cause troubles if loading an older image which does not carry all state information the executing QEMU requires. Almost no device takes care of this scenario. However, fixing this is trivial. We just need to issue a system reset during loadvm as well. Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- savevm.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/savevm.c b/savevm.c index 98b2422..5db01aa 100644 --- a/savevm.c +++ b/savevm.c @@ -2074,6 +2074,7 @@ int load_vmstate(const char *name) return -EINVAL; } +qemu_system_reset(); ret = qemu_loadvm_state(f); qemu_fclose(f); -- 1.7.1
[Qemu-devel] [Bug 795866] [NEW] pci passthrough doesn´t work
Public bug reported: Hi all, I have some problems passing through a pci device to kvm guest. First I have to say that I´m using the latest kvm-kernel und qemu-kvm from git-tree (Date 11.06.2011). I want´t to passthrough this device to guest: lspci-output: 02:00.0 Multimedia video controller: Micronas Semiconductor Holding AG Device 0720 (rev 01) So at first I have bind the driver to psi-stub: modprobe -r kvm-intel modprobe -r kvm echo 18c3 0720 /sys/bus/pci/drivers/pci-stub/new_id echo :02:00.0 /sys/bus/pci/devices/:02:00.0/driver/unbind echo :02:00.0 /sys/bus/pci/drivers/pci-stub/bind modprobe kvm modprobe kvm-intel Then I have assigned device to guest: -device pci-assign,host=02:00.0 When I start the guest. The device succesfully get´s an msi-IRQ on host- system: cat /proc/interrupt output: 32: 0 0 0 0 PCI-MSI-edge kvm_assigned_msi_device On guest device is visibel: lspci output: 00:04.0 Multimedia video controller: Micronas Semiconductor Holding AG Device 0720 (rev 01) Sometimes the device (on guest) get´s an IRQ between 10-16: 00:05.0 Multimedia video controller: Micronas Semiconductor Holding AG Device 0720 (rev 01) Subsystem: Micronas Semiconductor Holding AG Device dd00 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx+ Interrupt: pin A routed to IRQ 11 Region 0: Memory at f205 (32-bit, non-prefetchable) [size=64K] Region 1: Memory at f206 (32-bit, non-prefetchable) [size=64K] Capabilities: [58] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 64ns, L1 1us ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 unlimited, L1 unlimited ClockPM- Suprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt- Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [48] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Address: Data: Kernel modules: ngene In this case the kernel-modul (ngene) can not access the device: dmesg | grep ngene [ 69.977900] ngene :00:05.0: PCI INT A - Link[LNKA] - GSI 11 (level, high) - IRQ 11 [ 69.977909] ngene: Found Linux4Media cineS2 DVB-S2 Twin Tuner (v5) [ 69.978962] ngene :00:05.0: setting latency timer to 64 [ 69.979118] ngene: Device version 1 [ 69.979129] ngene :00:05.0: firmware: requesting ngene_18.fw [ 69.980884] ngene: Loading firmware file ngene_18.fw. [ 71.981052] ngene: Command timeout cmd=01 prev=00 [ 71.981205] host_to_ngene (c000): 01 00 00 00 00 00 00 00 [ 71.981457] ngene_to_host (c100): 00 00 00 00 00 00 00 00 [ 71.981704] dev-hosttongene (ec902000): 01 00 00 00 00 00 00 00 [ 71.981963] dev-ngenetohost (ec902100): 00 00 00 00 00 00 00 00 [ 73.985111] ngene: Command timeout cmd=02 prev=00 [ 73.985415] host_to_ngene (c000): 02 04 00 d0 00 04 00 00 [ 73.985684] ngene_to_host (c100): 00 00 00 00 00 00 00 00 [ 73.985931] dev-hosttongene (ec902000): 02 04 00 d0 00 04 00 00 [ 73.986191] dev-ngenetohost (ec902100): 00 00 00 00 00 00 00 00 [ 73.986568] ngene :00:05.0: PCI INT A disabled [ 73.986584] ngene: probe of :00:05.0 failed with error -1 Sometimes the device (on guest) gets an msi-irq f. e. IRQ 29. Then kernel-modul (ngene) can succesfully load the driver and all works fine. Short to say: HOSTGUEST STATUS MSI-IRQ MSI-IRQ ALL FINE MSI-IRQ IOAPIC-IRQ DOESN´t WORK with modinfo I had a look at the kernel-modul if there is way to force msi, but without success. But I think IRQ between (10-16) should also work because when I load the kernel-modul on host with IRQ (10-16) it works. (Device only get´s an MSI-IRQ If I start the vm to passthrough) Do anyone know where can be the problem? ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.
Re: [Qemu-devel] [Bug 795866] [NEW] pci passthrough doesn´t work
On 2011-06-11 11:05, steo wrote: Public bug reported: Hi all, I have some problems passing through a pci device to kvm guest. First I have to say that I´m using the latest kvm-kernel und qemu-kvm from git-tree (Date 11.06.2011). I want´t to passthrough this device to guest: lspci-output: 02:00.0 Multimedia video controller: Micronas Semiconductor Holding AG Device 0720 (rev 01) So at first I have bind the driver to psi-stub: modprobe -r kvm-intel modprobe -r kvm echo 18c3 0720 /sys/bus/pci/drivers/pci-stub/new_id echo :02:00.0 /sys/bus/pci/devices/:02:00.0/driver/unbind echo :02:00.0 /sys/bus/pci/drivers/pci-stub/bind modprobe kvm modprobe kvm-intel Then I have assigned device to guest: -device pci-assign,host=02:00.0 When I start the guest. The device succesfully get´s an msi-IRQ on host- system: cat /proc/interrupt output: 32: 0 0 0 0 PCI-MSI-edge kvm_assigned_msi_device On guest device is visibel: lspci output: 00:04.0 Multimedia video controller: Micronas Semiconductor Holding AG Device 0720 (rev 01) Sometimes the device (on guest) get´s an IRQ between 10-16: 00:05.0 Multimedia video controller: Micronas Semiconductor Holding AG Device 0720 (rev 01) Subsystem: Micronas Semiconductor Holding AG Device dd00 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx+ Interrupt: pin A routed to IRQ 11 Region 0: Memory at f205 (32-bit, non-prefetchable) [size=64K] Region 1: Memory at f206 (32-bit, non-prefetchable) [size=64K] Capabilities: [58] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 64ns, L1 1us ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 unlimited, L1 unlimited ClockPM- Suprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt- Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [48] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Address: Data: Kernel modules: ngene In this case the kernel-modul (ngene) can not access the device: dmesg | grep ngene [ 69.977900] ngene :00:05.0: PCI INT A - Link[LNKA] - GSI 11 (level, high) - IRQ 11 [ 69.977909] ngene: Found Linux4Media cineS2 DVB-S2 Twin Tuner (v5) [ 69.978962] ngene :00:05.0: setting latency timer to 64 [ 69.979118] ngene: Device version 1 [ 69.979129] ngene :00:05.0: firmware: requesting ngene_18.fw [ 69.980884] ngene: Loading firmware file ngene_18.fw. [ 71.981052] ngene: Command timeout cmd=01 prev=00 [ 71.981205] host_to_ngene (c000): 01 00 00 00 00 00 00 00 [ 71.981457] ngene_to_host (c100): 00 00 00 00 00 00 00 00 [ 71.981704] dev-hosttongene (ec902000): 01 00 00 00 00 00 00 00 [ 71.981963] dev-ngenetohost (ec902100): 00 00 00 00 00 00 00 00 [ 73.985111] ngene: Command timeout cmd=02 prev=00 [ 73.985415] host_to_ngene (c000): 02 04 00 d0 00 04 00 00 [ 73.985684] ngene_to_host (c100): 00 00 00 00 00 00 00 00 [ 73.985931] dev-hosttongene (ec902000): 02 04 00 d0 00 04 00 00 [ 73.986191] dev-ngenetohost (ec902100): 00 00 00 00 00 00 00 00 [ 73.986568] ngene :00:05.0: PCI INT A disabled [ 73.986584] ngene: probe of :00:05.0 failed with error -1 Sometimes the device (on guest) gets an msi-irq f. e. IRQ 29. Then kernel-modul (ngene) can succesfully load the driver and all works fine. Short to say: HOST GUEST STATUS MSI-IRQ MSI-IRQ ALL FINE MSI-IRQ IOAPIC-IRQDOESN´t WORK with modinfo I had a look at the kernel-modul if there is way to force msi, but without success. But I think IRQ between (10-16) should also work because when I load the kernel-modul on host with IRQ (10-16) it works. (Device only get´s an MSI-IRQ If I start the vm to passthrough) Do anyone know where can be the problem? Does '-device
[Qemu-devel] [PATCH][uq/master] kvm: x86: Save/restore FPU OP, IP and DP
From: Jan Kiszka jan.kis...@siemens.com
These FPU states are properly maintained by KVM but not yet by TCG. So
far we unconditionally set them to 0 in the guest which may cause
state corruptions - not only during migration.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
target-i386/cpu.h |6 +-
target-i386/kvm.c | 20 +++-
target-i386/machine.c |4
3 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 9c3340d..3c2dab9 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -641,6 +641,10 @@ typedef struct CPUX86State {
uint16_t fpuc;
uint8_t fptags[8]; /* 0 = valid, 1 = empty */
FPReg fpregs[8];
+/* KVM-only so far */
+uint16_t fpop;
+uint64_t fpip;
+uint64_t fpdp;
/* emulator internal variables */
float_status fp_status;
@@ -942,7 +946,7 @@ uint64_t cpu_get_tsc(CPUX86State *env);
#define cpu_list_id x86_cpu_list
#define cpudef_setup x86_cpudef_setup
-#define CPU_SAVE_VERSION 12
+#define CPU_SAVE_VERSION 13
/* MMU modes definitions */
#define MMU_MODE0_SUFFIX _kernel
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 5ebb054..938e0a3 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -718,6 +718,9 @@ static int kvm_put_fpu(CPUState *env)
fpu.fsw = env-fpus ~(7 11);
fpu.fsw |= (env-fpstt 7) 11;
fpu.fcw = env-fpuc;
+fpu.last_opcode = env-fpop;
+fpu.last_ip = env-fpip;
+fpu.last_dp = env-fpdp;
for (i = 0; i 8; ++i) {
fpu.ftwx |= (!env-fptags[i]) i;
}
@@ -740,7 +743,7 @@ static int kvm_put_xsave(CPUState *env)
{
int i, r;
struct kvm_xsave* xsave;
-uint16_t cwd, swd, twd, fop;
+uint16_t cwd, swd, twd;
if (!kvm_has_xsave()) {
return kvm_put_fpu(env);
@@ -748,7 +751,7 @@ static int kvm_put_xsave(CPUState *env)
xsave = qemu_memalign(4096, sizeof(struct kvm_xsave));
memset(xsave, 0, sizeof(struct kvm_xsave));
-cwd = swd = twd = fop = 0;
+cwd = swd = twd = 0;
swd = env-fpus ~(7 11);
swd |= (env-fpstt 7) 11;
cwd = env-fpuc;
@@ -756,7 +759,9 @@ static int kvm_put_xsave(CPUState *env)
twd |= (!env-fptags[i]) i;
}
xsave-region[0] = (uint32_t)(swd 16) + cwd;
-xsave-region[1] = (uint32_t)(fop 16) + twd;
+xsave-region[1] = (uint32_t)(env-fpop 16) + twd;
+memcpy(xsave-region[XSAVE_CWD_RIP], env-fpip, sizeof(env-fpip));
+memcpy(xsave-region[XSAVE_CWD_RDP], env-fpdp, sizeof(env-fpdp));
memcpy(xsave-region[XSAVE_ST_SPACE], env-fpregs,
sizeof env-fpregs);
memcpy(xsave-region[XSAVE_XMM_SPACE], env-xmm_regs,
@@ -921,6 +926,9 @@ static int kvm_get_fpu(CPUState *env)
env-fpstt = (fpu.fsw 11) 7;
env-fpus = fpu.fsw;
env-fpuc = fpu.fcw;
+env-fpop = fpu.last_opcode;
+env-fpip = fpu.last_ip;
+env-fpdp = fpu.last_dp;
for (i = 0; i 8; ++i) {
env-fptags[i] = !((fpu.ftwx i) 1);
}
@@ -935,7 +943,7 @@ static int kvm_get_xsave(CPUState *env)
{
struct kvm_xsave* xsave;
int ret, i;
-uint16_t cwd, swd, twd, fop;
+uint16_t cwd, swd, twd;
if (!kvm_has_xsave()) {
return kvm_get_fpu(env);
@@ -951,13 +959,15 @@ static int kvm_get_xsave(CPUState *env)
cwd = (uint16_t)xsave-region[0];
swd = (uint16_t)(xsave-region[0] 16);
twd = (uint16_t)xsave-region[1];
-fop = (uint16_t)(xsave-region[1] 16);
+env-fpop = (uint16_t)(xsave-region[1] 16);
env-fpstt = (swd 11) 7;
env-fpus = swd;
env-fpuc = cwd;
for (i = 0; i 8; ++i) {
env-fptags[i] = !((twd i) 1);
}
+memcpy(env-fpip, xsave-region[XSAVE_CWD_RIP], sizeof(env-fpip));
+memcpy(env-fpdp, xsave-region[XSAVE_CWD_RDP], sizeof(env-fpdp));
env-mxcsr = xsave-region[XSAVE_MXCSR];
memcpy(env-fpregs, xsave-region[XSAVE_ST_SPACE],
sizeof env-fpregs);
diff --git a/target-i386/machine.c b/target-i386/machine.c
index bbeae88..e02c2a3 100644
--- a/target-i386/machine.c
+++ b/target-i386/machine.c
@@ -390,6 +390,10 @@ static const VMStateDescription vmstate_cpu = {
VMSTATE_UINT64_V(xcr0, CPUState, 12),
VMSTATE_UINT64_V(xstate_bv, CPUState, 12),
VMSTATE_YMMH_REGS_VARS(ymmh_regs, CPUState, CPU_NB_REGS, 12),
+/* Further FPU states */
+VMSTATE_UINT16_V(fpop, CPUState, 13),
+VMSTATE_UINT64_V(fpip, CPUState, 13),
+VMSTATE_UINT64_V(fpdp, CPUState, 13),
VMSTATE_END_OF_LIST()
/* The above list is not sorted /wrt version numbers, watch out! */
},
--
1.7.1
[Qemu-devel] [Bug 795866] Re: pci passthrough doesn´t work
lspci - output on guest: 00:04.0 Multimedia video controller: Micronas Semiconductor Holding AG Device 0720 (rev 01) Subsystem: Micronas Semiconductor Holding AG Device dd00 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx+ Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 29 Region 0: Memory at f203 (32-bit, non-prefetchable) [size=64K] Region 1: Memory at f204 (32-bit, non-prefetchable) [size=64K] Capabilities: access denied Kernel driver in use: ngene Kernel modules: ngene 00:05.0 Multimedia video controller: Micronas Semiconductor Holding AG Device 0720 (rev 01) Subsystem: Micronas Semiconductor Holding AG Device dd00 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx+ Interrupt: pin A routed to IRQ 11 Region 0: Memory at f205 (32-bit, non-prefetchable) [size=64K] Region 1: Memory at f206 (32-bit, non-prefetchable) [size=64K] Capabilities: access denied Kernel modules: ngene IRQ 11 not working. IRQ 29 working -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/795866 Title: pci passthrough doesn´t work Status in QEMU: New Bug description: Hi all, I have some problems passing through a pci device to kvm guest. First I have to say that I´m using the latest kvm-kernel und qemu-kvm from git-tree (Date 11.06.2011). I want´t to passthrough this device to guest: lspci-output: 02:00.0 Multimedia video controller: Micronas Semiconductor Holding AG Device 0720 (rev 01) So at first I have bind the driver to psi-stub: modprobe -r kvm-intel modprobe -r kvm echo 18c3 0720 /sys/bus/pci/drivers/pci-stub/new_id echo :02:00.0 /sys/bus/pci/devices/:02:00.0/driver/unbind echo :02:00.0 /sys/bus/pci/drivers/pci-stub/bind modprobe kvm modprobe kvm-intel Then I have assigned device to guest: -device pci-assign,host=02:00.0 When I start the guest. The device succesfully get´s an msi-IRQ on host-system: cat /proc/interrupt output: 32: 0 0 0 0 PCI-MSI-edge kvm_assigned_msi_device On guest device is visibel: lspci output: 00:04.0 Multimedia video controller: Micronas Semiconductor Holding AG Device 0720 (rev 01) Sometimes the device (on guest) get´s an IRQ between 10-16: 00:05.0 Multimedia video controller: Micronas Semiconductor Holding AG Device 0720 (rev 01) Subsystem: Micronas Semiconductor Holding AG Device dd00 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx+ Interrupt: pin A routed to IRQ 11 Region 0: Memory at f205 (32-bit, non-prefetchable) [size=64K] Region 1: Memory at f206 (32-bit, non-prefetchable) [size=64K] Capabilities: [58] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 64ns, L1 1us ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 unlimited, L1 unlimited ClockPM- Suprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt- Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [48] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Address: Data: Kernel modules: ngene In this case the kernel-modul (ngene) can not access the device: dmesg | grep ngene [ 69.977900] ngene :00:05.0: PCI INT A - Link[LNKA] - GSI 11 (level, high) - IRQ 11 [ 69.977909] ngene: Found Linux4Media cineS2 DVB-S2 Twin Tuner (v5) [ 69.978962]
[Qemu-devel] [Bug 795866] Re: pci passthrough doesn´t work
Here is the dmesg - output of second device which is currently working on guest with MSI-IRQ 29: [2.137175] ngene :00:04.0: PCI INT A - Link[LNKD] - GSI 11 (level, high) - IRQ 11 [2.137183] ngene: Found Linux4Media cineS2 DVB-S2 Twin Tuner (v5) [2.140506] ngene :00:04.0: setting latency timer to 64 [2.140679] ngene: Device version 1 [2.140693] ngene :00:04.0: firmware: requesting ngene_18.fw [2.214848] ngene: Loading firmware file ngene_18.fw. [2.249797] ngene :00:04.0: irq 29 for MSI/MSI-X -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/795866 Title: pci passthrough doesn´t work Status in QEMU: New Bug description: Hi all, I have some problems passing through a pci device to kvm guest. First I have to say that I´m using the latest kvm-kernel und qemu-kvm from git-tree (Date 11.06.2011). I want´t to passthrough this device to guest: lspci-output: 02:00.0 Multimedia video controller: Micronas Semiconductor Holding AG Device 0720 (rev 01) So at first I have bind the driver to psi-stub: modprobe -r kvm-intel modprobe -r kvm echo 18c3 0720 /sys/bus/pci/drivers/pci-stub/new_id echo :02:00.0 /sys/bus/pci/devices/:02:00.0/driver/unbind echo :02:00.0 /sys/bus/pci/drivers/pci-stub/bind modprobe kvm modprobe kvm-intel Then I have assigned device to guest: -device pci-assign,host=02:00.0 When I start the guest. The device succesfully get´s an msi-IRQ on host-system: cat /proc/interrupt output: 32: 0 0 0 0 PCI-MSI-edge kvm_assigned_msi_device On guest device is visibel: lspci output: 00:04.0 Multimedia video controller: Micronas Semiconductor Holding AG Device 0720 (rev 01) Sometimes the device (on guest) get´s an IRQ between 10-16: 00:05.0 Multimedia video controller: Micronas Semiconductor Holding AG Device 0720 (rev 01) Subsystem: Micronas Semiconductor Holding AG Device dd00 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx+ Interrupt: pin A routed to IRQ 11 Region 0: Memory at f205 (32-bit, non-prefetchable) [size=64K] Region 1: Memory at f206 (32-bit, non-prefetchable) [size=64K] Capabilities: [58] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 64ns, L1 1us ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 unlimited, L1 unlimited ClockPM- Suprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt- Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [48] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Address: Data: Kernel modules: ngene In this case the kernel-modul (ngene) can not access the device: dmesg | grep ngene [ 69.977900] ngene :00:05.0: PCI INT A - Link[LNKA] - GSI 11 (level, high) - IRQ 11 [ 69.977909] ngene: Found Linux4Media cineS2 DVB-S2 Twin Tuner (v5) [ 69.978962] ngene :00:05.0: setting latency timer to 64 [ 69.979118] ngene: Device version 1 [ 69.979129] ngene :00:05.0: firmware: requesting ngene_18.fw [ 69.980884] ngene: Loading firmware file ngene_18.fw. [ 71.981052] ngene: Command timeout cmd=01 prev=00 [ 71.981205] host_to_ngene (c000): 01 00 00 00 00 00 00 00 [ 71.981457] ngene_to_host (c100): 00 00 00 00 00 00 00 00 [ 71.981704] dev-hosttongene (ec902000): 01 00 00 00 00 00 00 00 [ 71.981963] dev-ngenetohost (ec902100): 00 00 00 00 00 00 00 00 [ 73.985111] ngene: Command timeout cmd=02 prev=00 [ 73.985415] host_to_ngene (c000): 02 04 00 d0 00 04 00 00 [ 73.985684] ngene_to_host (c100): 00 00 00 00 00 00 00 00 [ 73.985931] dev-hosttongene (ec902000): 02 04 00 d0 00 04 00 00 [ 73.986191] dev-ngenetohost (ec902100): 00 00 00 00 00 00 00 00 [ 73.986568]
Re: [Qemu-devel] semantics of -cpu host and check/enforce
On Fri, Jun 10, 2011 at 05:36:37PM -0400, Eduardo Habkost wrote: We have 3 sets of cpu features that may or may not be included in '-cpu host': A) Features that are supported by the host and that KVM can already emulate, or don't need KVM support to be used; B) Features that may be not supported by the host but can be emulated by KVM (e.g. the SVM features, or x2apic); C) Features that are supported by the host but KVM can't emulate. Divided in: C1) features we can't emulate and we know about it (e.g. dtes64)[1] C2) features we possibly can't emulate but we don't even know about it (e.g. features added to recent CPUs). It seems obvious that all the features in group A must always be included in '-cpu host', but what about features in the B or C groups? About group B: it looks like we are not being consistent. For example, svm_features has every bit enabled when using '-cpu host' even if the host doesn't support them; in other cases (e.g. x2apic), it is not enabled by '-cpu host' unless the host already supports it. SVM is a special feature. We can't just forward the host-cpuid to the guest because every SVM feature we provide to the guest needs emulation in the kernel module. The kernel-module will tell qemu-kvm about its feature set via the GET_SUPPORTED_CPUID ioctl. So the idea behint -cpu host and SVM features is that qemu-kvm enables all of them and masks out everything that is not supported by the kernel module. Note that the kernel might even emulate features that are not supported on the host, like the vmcb-clean-bits, so we really need to ask the kernel what is supported for the guest. Regards, Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
Re: [Qemu-devel] [PATCH] coroutine: Implement coroutines using gthread
Le jeudi 9 juin 2011 19:41:06, Aneesh Kumar K.V a écrit :
On platforms that doesn't support makecontext use gthread
based coroutine implementation.
Why not using one of the existing lib of coroutine or improving it ?
Could you give some hints ?
Why not use http://cvs.schmorp.de/libcoro/coro.h what is the base of the perl
coroutine lib and thus well tested on a lot of
plateform?
Bastien
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
NOTE: Tested on linux with force compliation of coroutine-gthread.c
Makefile.objs |5 ++
configure | 18 +
coroutine-gthread.c | 172
+++ 3 files changed, 195
insertions(+), 0 deletions(-)
create mode 100644 coroutine-gthread.c
diff --git a/Makefile.objs b/Makefile.objs
index 0f1d7df..d354d3c 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -13,9 +13,14 @@ oslib-obj-$(CONFIG_POSIX) += oslib-posix.o
qemu-thread-posix.o
### #
coroutines
coroutine-obj-y = qemu-coroutine.o qemu-coroutine-lock.o
+ifeq ($(CONFIG_UCONTEXT_COROUTINE),y)
coroutine-obj-$(CONFIG_POSIX) += coroutine-ucontext.o
+else
+coroutine-obj-$(CONFIG_POSIX) += coroutine-gthread.o
+endif
coroutine-obj-$(CONFIG_WIN32) += coroutine-win32.o
+
###
# block-obj-y is code used by both qemu system emulation and qemu-img
diff --git a/configure b/configure
index 980914a..529d8c4 100755
--- a/configure
+++ b/configure
@@ -2568,6 +2568,20 @@ if test $trace_backend = dtrace; then
fi
##
+# check if we have makecontext
+
+ucontext_coroutine=no
+cat $TMPC EOF
+#include ucontext.h
+int main(void) { makecontext(0, 0, 0); }
+EOF
+if compile_prog ; then
+ucontext_coroutine=yes
+fi
+
+
+
+##
# End of CC checks
# After here, no more $cc or $ld runs
@@ -3031,6 +3045,10 @@ if test $rbd = yes ; then
echo CONFIG_RBD=y $config_host_mak
fi
+if test $ucontext_coroutine = yes ; then
+ echo CONFIG_UCONTEXT_COROUTINE=y $config_host_mak
+fi
+
# USB host support
case $usb in
linux)
diff --git a/coroutine-gthread.c b/coroutine-gthread.c
new file mode 100644
index 000..37e5a16
--- /dev/null
+++ b/coroutine-gthread.c
@@ -0,0 +1,172 @@
+/*
+ *
+ * Copyright (C) 2006 Anthony Liguori anth...@codemonkey.ws
+ * Copyright (C) 2011 Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.0 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301 USA + */
+
+#include qemu-common.h
+#include qemu-coroutine-int.h
+#include glib.h
+
+typedef struct {
+Coroutine qemu_co;
+GThread *thread;
+gboolean runnable;
+} CoroutineGthread;
+
+typedef struct {
+/** Currently executing coroutine */
+CoroutineGthread *current;
+
+/** The default coroutine */
+CoroutineGthread leader;
+} CoroutineThreadState;
+
+static GCond *run_cond;
+static GMutex *run_lock;
+static pthread_key_t thread_state_key;
+
+static void qemu_coroutine_thread_cleanup(void *opaque)
+{
+CoroutineThreadState *s = opaque;
+
+qemu_free(s);
+}
+
+static void __attribute__((constructor)) coroutine_system_init(void)
+{
+int ret;
+if (!g_thread_supported()) {
+g_thread_init(NULL);
+}
+run_cond = g_cond_new();
+run_lock = g_mutex_new();
+
+ret = pthread_key_create(thread_state_key,
qemu_coroutine_thread_cleanup); +if (ret != 0) {
+fprintf(stderr, unable to create leader key: %s\n,
strerror(errno)); +abort();
+}
+}
+
+static CoroutineThreadState *coroutine_get_thread_state(void)
+{
+CoroutineThreadState *s = pthread_getspecific(thread_state_key);
+
+if (!s) {
+s = qemu_mallocz(sizeof(*s));
+s-current = s-leader;
+pthread_setspecific(thread_state_key, s);
+}
+return s;
+}
+
+static gpointer coroutine_thread(gpointer opaque)
+{
+CoroutineGthread *co = opaque;
+CoroutineThreadState *s = coroutine_get_thread_state();
+
+s-current = co;
+
+/* Wait for somebody make it runnable */
+
Re: [Qemu-devel] [PATCH-v3 2/2] kvm: Fix unused-but-set-variable warning
On Sat, Jun 11, 2011 at 8:46 AM, Jan Kiszka jan.kis...@web.de wrote: On 2011-06-10 20:46, Stefan Hajnoczi wrote: On Tue, May 31, 2011 at 09:53:49AM +0200, Christophe Fergeau wrote: Based on a patch from Hans de Goede hdego...@redhat.com This warning is new in gcc 4.6. Acked-by: Amit Shah amit.s...@redhat.com Signed-off-by: Christophe Fergeau cferg...@redhat.com --- target-i386/kvm.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) Thanks, applied to the trivial patches tree: http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/trivial-patches Please skip this one. I'll post a patch fixing the issue that this warning revealed (lacking save/restore of FPU OP, IP and DP). Okay, dropped from trivial-patches in favor of Jan's fix. Stefan
Re: [Qemu-devel] buildbot failure in qemu on pci_i386_debian_5_0
On Sat, Jun 11, 2011 at 3:23 AM, q...@buildbot.b1-systems.de wrote: The Buildbot has detected a new failure on builder pci_i386_debian_5_0 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/pci_i386_debian_5_0/builds/0 This is the first email notification from the QEMU buildbot, which automatically builds qemu.git and several subsystem repositories (pci, block, qmp, ppc, s390, agraf's xen, and trivial-patches). Builds run every day and the goal is to catch build breakages before they enter qemu.git. To see the build errors relating to this failure, follow the link above and select compile stdio output: CCi386-softmmu/exec.o /home/build/qemu/pci_i386_debian_5_0/build/exec.c: In function 'phys_page_for_each': /home/build/qemu/pci_i386_debian_5_0/build/exec.c:1816: error: too few arguments to function 'client-set_memory' make[2]: *** [exec.o] Error 1 make[1]: *** [subdir-i386-softmmu] Error 2 This failure is in the pci tree, so I think Michael will investigate. If you feel failure notifications are spamming the list, please let Daniel Gollub gol...@b1-systems.de and me know so we can adjust them. For more info on the QEMU buildbot see: http://wiki.qemu.org/ContinuousIntegration http://buildbot.b1-systems.de/qemu/ Stefan
[Qemu-devel] Invitation to connect on LinkedIn
LinkedIn 용준 공용준 requested to add you as a connection on LinkedIn: -- Jiajun, I'd like to add you to my professional network on LinkedIn. - 용준 Accept invitation from 용준 공용준 http://www.linkedin.com/e/-kkb1ec-gospopdb-4s/qTMmi8QEI_f3FNXUkL1mvZgy00BGYniwg3/blk/I140121473_11/1BpC5vrmRLoRZcjkkZt5YCpnlOt3RApnhMpmdzgmhxrSNBszYNclYPdPgNcz4Md359bR1Ou75qd4ljbPcTdPoUcP8UcjcLrCBxbOYWrSlI/EML_comm_afe/ View invitation from 용준 공용준 http://www.linkedin.com/e/-kkb1ec-gospopdb-4s/qTMmi8QEI_f3FNXUkL1mvZgy00BGYniwg3/blk/I140121473_11/34NnPcTd34Ocj0QckALqnpPbOYWrSlI/svi/ -- DID YOU KNOW you can showcase your professional knowledge on LinkedIn to receive job/consulting offers and enhance your professional reputation? Posting replies to questions on LinkedIn Answers puts you in front of the world's professional community. http://www.linkedin.com/e/-kkb1ec-gospopdb-4s/abq/inv-24/ -- (c) 2011, LinkedIn Corporation
Re: [Qemu-devel] QEMU API for modelling of user's hardware
I've found the following source of information regarding writing of device models for QEMU: http://www.linux-kvm.org/wiki/images/f/fe/2010-forum-armbru-qdev.pdf http://www.google.com/url?sa=Dq=http://www.linux-kvm.org/wiki/images/f/fe/2010-forum-armbru-qdev.pdf Is there any better or more detailed description (except of sources themselves ;-) )? -- TIA Regards, Wojtek
[Qemu-devel] buildbot failure in qemu on block_i386_debian_5_0
The Buildbot has detected a new failure on builder block_i386_debian_5_0 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/block_i386_debian_5_0/builds/1 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: yuzuki Build Reason: The Nightly scheduler named 'nightly_block' triggered this build Build Source Stamp: [branch block] HEAD Blamelist: BUILD FAILED: failed git sincerely, -The Buildbot
[Qemu-devel] buildbot failure in qemu on block_x86_64_debian_5_0
The Buildbot has detected a new failure on builder block_x86_64_debian_5_0 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/block_x86_64_debian_5_0/builds/1 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: yuzuki Build Reason: The Nightly scheduler named 'nightly_block' triggered this build Build Source Stamp: [branch block] HEAD Blamelist: BUILD FAILED: failed git sincerely, -The Buildbot
[Qemu-devel] (no subject)
Please find attached a patch to add built-in support for iSCSI into QEMU. Please review and/or apply this patch. This is the latest version of this patch and I think I have addressed all previous concerns and suggestions. Using built-in iSCSI support has many advantages for certain use cases : * if you have very many iSCSI devices it may be impractical to expose all LUNs to the underlying host. * the devices become private to the guest and are not visible to the host. This automatically avoids polluting the page-cache on the host. * security, the devices are private to the guest, which prevents other guests or the host itself from accessing the devices. * security, it allows non-root users a secure way to get private and password protected access to the device by using CHAP authentication. * migration, many other virtualization systems provide built-in iscsi clients like this. Also providing this as feature in QEMU may make it easier for such users to migrate over to QEMU/KVM. * easier to maintain. For users with very many QEMU instances I think having guest-private iscsi targets and LUNs may be easier to manage than 'huge set of files in /dev/scsi/*' * easier to maintain, when copying a QEMU instance from one host to another, this offers a more self-contained solution where the QEMU command line itself cotnains all required storage configuration, instead of also having to coordinate this move with setting up and tearing down open-iscsi logins on the underlying hosts. The patch has been tested by installing and running several distributions such as RHEL6 and Ubuntu on devices, both system disk as well as the installer CDROM as being iscsi devices. This testing has also been performed by running full QEMU under valgrind. Performance is comparable to using open-iscsi devices.
[Qemu-devel] [PATCH] iSCSI block driver support
This patch adds a new block driver : block.iscsi.c
This driver interfaces with the multiplatform posix library
for iscsi initiator/client access to iscsi devices hosted at
git://github.com/sahlberg/libiscsi.git
The patch adds the driver to interface with the iscsi library.
It also updated the configure script to
* by default, probe is libiscsi is available and if so, build
qemu against libiscsi.
* --enable-libiscsi
Force a build against libiscsi. If libiscsi is not available
the build will fail.
* --disable-libiscsi
Do not link against libiscsi, even if it is available.
When linked with libiscsi, qemu gains support to access iscsi resources
such as disks and cdrom directly, without having to make the devices visible
to the host.
You can specify devices using a iscsi url of the form :
iscsi://[username[:password@]]host[:port]/target-iqn-name/lun
When using authentication, the password can optionally be set with
LIBISCSI_CHAP_PASSWORD=password to avoid it showing up in the process list
Example:
./x86_64-softmmu/qemu-system-x86_64 -m 1024 -cdrom
iscsi://127.0.0.1/iqn.ronnie.test/2 --drive
file=iscsi://127.0.0.1/iqn.ronnie.test/1 -boot d -enable-kvm
Signed-off-by: Ronnie Sahlberg ronniesahlb...@gmail.com
---
Makefile.objs |1 +
block/iscsi.c | 596 +
configure | 31 +++
trace-events |6 +
4 files changed, 634 insertions(+), 0 deletions(-)
create mode 100644 block/iscsi.c
diff --git a/Makefile.objs b/Makefile.objs
index 52d8b23..1b21c14 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -25,6 +25,7 @@ block-nested-y += qed-check.o
block-nested-y += parallels.o nbd.o blkdebug.o sheepdog.o blkverify.o
block-nested-$(CONFIG_WIN32) += raw-win32.o
block-nested-$(CONFIG_POSIX) += raw-posix.o
+block-nested-$(CONFIG_LIBISCSI) += iscsi.o
block-nested-$(CONFIG_CURL) += curl.o
block-nested-$(CONFIG_RBD) += rbd.o
diff --git a/block/iscsi.c b/block/iscsi.c
new file mode 100644
index 000..07fb3bc
--- /dev/null
+++ b/block/iscsi.c
@@ -0,0 +1,596 @@
+/*
+ * QEMU Block driver for iSCSI images
+ *
+ * Copyright (c) 2010 Ronnie Sahlberg ronniesahlb...@gmail.com
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include config-host.h
+
+#include poll.h
+#include sysemu.h
+#include qemu-common.h
+#include qemu-error.h
+#include block_int.h
+#include trace.h
+
+#include iscsi/iscsi.h
+#include iscsi/scsi-lowlevel.h
+
+
+typedef struct IscsiLun {
+struct iscsi_context *iscsi;
+int lun;
+int block_size;
+unsigned long num_blocks;
+} IscsiLun;
+
+typedef struct IscsiAIOCB {
+BlockDriverAIOCB common;
+QEMUIOVector *qiov;
+QEMUBH *bh;
+IscsiLun *iscsilun;
+struct scsi_task *task;
+uint8_t *buf;
+int canceled;
+int status;
+size_t read_size;
+size_t read_offset;
+} IscsiAIOCB;
+
+struct IscsiTask {
+IscsiLun *iscsilun;
+int status;
+int complete;
+};
+
+static void
+iscsi_abort_task_cb(struct iscsi_context *iscsi, int status, void
*command_data,
+void *private_data)
+{
+}
+
+static void
+iscsi_aio_cancel(BlockDriverAIOCB *blockacb)
+{
+IscsiAIOCB *acb = (IscsiAIOCB *)blockacb;
+IscsiLun *iscsilun = acb-iscsilun;
+
+acb-status = -ECANCELED;
+acb-common.cb(acb-common.opaque, acb-status);
+acb-canceled = 1;
+
+iscsi_task_mgmt_abort_task_async(iscsilun-iscsi, acb-task,
+ iscsi_abort_task_cb, NULL);
+}
+
+static AIOPool iscsi_aio_pool = {
+.aiocb_size = sizeof(IscsiAIOCB),
+.cancel = iscsi_aio_cancel,
+};
+
+
+static void iscsi_process_read(void *arg);
+static void iscsi_process_write(void *arg);
+
+static int iscsi_process_flush(void *arg)
+{
+IscsiLun *iscsilun = arg;
+
+return iscsi_queue_length(iscsilun-iscsi) 0;
+}
+
+static void
+iscsi_set_events(IscsiLun *iscsilun)
+{
+struct iscsi_context *iscsi = iscsilun-iscsi;
+
+
[Qemu-devel] iSCSI support for QEMU
Sorry about the missing subject line in the previous mail Got confused when using git-send-patch :-) regards ronnie sahlberg On Sun, Jun 12, 2011 at 12:47 PM, Ronnie Sahlberg ronniesahlb...@gmail.com wrote: Please find attached a patch to add built-in support for iSCSI into QEMU. Please review and/or apply this patch. This is the latest version of this patch and I think I have addressed all previous concerns and suggestions. Using built-in iSCSI support has many advantages for certain use cases : * if you have very many iSCSI devices it may be impractical to expose all LUNs to the underlying host. * the devices become private to the guest and are not visible to the host. This automatically avoids polluting the page-cache on the host. * security, the devices are private to the guest, which prevents other guests or the host itself from accessing the devices. * security, it allows non-root users a secure way to get private and password protected access to the device by using CHAP authentication. * migration, many other virtualization systems provide built-in iscsi clients like this. Also providing this as feature in QEMU may make it easier for such users to migrate over to QEMU/KVM. * easier to maintain. For users with very many QEMU instances I think having guest-private iscsi targets and LUNs may be easier to manage than 'huge set of files in /dev/scsi/*' * easier to maintain, when copying a QEMU instance from one host to another, this offers a more self-contained solution where the QEMU command line itself cotnains all required storage configuration, instead of also having to coordinate this move with setting up and tearing down open-iscsi logins on the underlying hosts. The patch has been tested by installing and running several distributions such as RHEL6 and Ubuntu on devices, both system disk as well as the installer CDROM as being iscsi devices. This testing has also been performed by running full QEMU under valgrind. Performance is comparable to using open-iscsi devices.
[Qemu-devel] buildbot failure in qemu on xen_x86_64_debian_5_0
The Buildbot has detected a new failure on builder xen_x86_64_debian_5_0 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/xen_x86_64_debian_5_0/builds/1 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: yuzuki Build Reason: The Nightly scheduler named 'nightly_xen' triggered this build Build Source Stamp: [branch xen-next] HEAD Blamelist: BUILD FAILED: failed git sincerely, -The Buildbot
[Qemu-devel] buildbot failure in qemu on xen_i386_debian_5_0
The Buildbot has detected a new failure on builder xen_i386_debian_5_0 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/xen_i386_debian_5_0/builds/1 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: yuzuki Build Reason: The Nightly scheduler named 'nightly_xen' triggered this build Build Source Stamp: [branch xen-next] HEAD Blamelist: BUILD FAILED: failed git sincerely, -The Buildbot
