[kvm-devel] muev
Rumor News: Oncology Med. Inc. (OTC: ONCO) a Cancer Treatment Solutions Group is said to have experienced over a 1000% increase in revenues for the fiscal 3rd quarter ending July, 2007 compared with the prior year while fiscal fourth quarter results for 2007 are on track to exceed this years third quarter results. ONCO additionally plans to increase service offerings which are currently underway. Dont wait for the news to come out and lose the opportunity to get in front of the general investing public. Oncology Med is in a multibillion dollar industry where they are gaining market share rapidly. Call your broker now for ONCO. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [et-mgmt-tools] ANNOUNCE: virt-top 0.3.2.7 released
Richard W.M. Jones wrote: > Richard W.M. Jones wrote: >> Richard W.M. Jones wrote: >>> Farkas Levente wrote: [EMAIL PROTECTED] ~]# /usr/bin/virt-top --connect qemu:///system libvir: error : this function is not supported by the hypervisor: virConnectGetHostname Fatal error: exception Libvirt.Virterror(3, 0, _, 2, _, 0, _, _, 0, _, _, 0) [EMAIL PROTECTED] ~]# rpm -q libvirt libvirt-0.3.2-2 >>> >>> You've found a real bug. Virt-top is not very well tested against >>> qemu, or rather that should be not tested at all. But I'll go and >>> try to make it work with qemu now. Probably take a few hours though ... >> >> The patch to fix that particular bug is attached. There may be other >> though, still testing ... > > OK, I'm fairly sure this is the only patch needed. > > I'm going to roll this in to the next (0.3.2.8) release later. > > Libvirt needs works to support block and network stats from QEMU/KVM. > Virt-top won't fail because this is missing, it just can't display > anything in those columns. The work as far as I understand it is fairly > simple, but also lower down on my list of priorities at the moment. > > Another thing which virt-top uses but which is missing in QEMU/KVM is > physical CPU usage and CPU pinning. I have absolutely no idea if qemu > supports this -- I assume it does through ordinary Linux mechanisms such > as numactl. As for KVM, no idea whatsoever. maybe you can ask kvm people:-) anyway if the new version will be uploaded i can try it again. -- Levente "Si vis pacem para bellum!" - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/6] virtio net driver
Am Donnerstag, 20. September 2007 schrieb Rusty Russell:
> The network driver uses *two* virtqueues: one for input packets and
> one for output packets. This has nice locking properties (ie. we
> don't do any for recv vs send).
[...]
> 3) Resolve freeing of old xmit skbs (someone sent patch IIRC?)
Yes, that was me. I am quite busy at the moment but I will send a refreshed
patch soon. The most annoying fact of my current patch is, that I have to add
locking. (Because of the only one operation per virtqueue at a time rule)
[...]
> +struct virtnet_info
> +{
> + struct virtqueue_ops *vq_ops;
> + struct virtqueue *vq_recv;
> + struct virtqueue *vq_send;
> + struct net_device *ndev;
This is only a matter of taste, but I like netdev or dev more than ndev.
[...]
Everything else looks sane.
20-minutes-code-review-by: Christian Borntraeger <[EMAIL PROTECTED]>
Christian
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 1/3] move grp decoding to function to make x86_emulate_insn() clearer
To improve readability, move push, writeback, and grp 1a/2/3/4/5/9 emulation
parts to functions.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
drivers/kvm/x86_emulate.c | 447 ++---
1 files changed, 262 insertions(+), 185 deletions(-)
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index 3a1c712..67fe1e1 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -898,6 +898,240 @@ done:
return (rc == X86EMUL_UNHANDLEABLE) ? -1 : 0;
}
+static inline void emulate_push(struct x86_emulate_ctxt *ctxt)
+{
+ struct decode_cache *c = &ctxt->decode;
+
+ c->dst.type = OP_MEM;
+ c->dst.bytes = c->op_bytes;
+ c->dst.val = c->src.val;
+ register_address_increment(c->regs[VCPU_REGS_RSP], -c->op_bytes);
+ c->dst.ptr = (void *) register_address(ctxt->ss_base,
c->regs[VCPU_REGS_RSP]);
+}
+
+static inline int emulate_grp1a(struct x86_emulate_ctxt *ctxt, struct
x86_emulate_ops *ops)
+{
+ struct decode_cache *c = &ctxt->decode;
+ int rc;
+
+ /* 64-bit mode: POP always pops a 64-bit operand. */
+
+ if (ctxt->mode == X86EMUL_MODE_PROT64)
+ c->dst.bytes = 8;
+
+ rc = ops->read_std(register_address(ctxt->ss_base,
c->regs[VCPU_REGS_RSP]),
+ &c->dst.val, c->dst.bytes, ctxt->vcpu);
+ if (rc != 0)
+ return rc;
+
+ register_address_increment(c->regs[VCPU_REGS_RSP], c->dst.bytes);
+
+ return 0;
+}
+
+static inline void emulate_grp2(struct decode_cache *c, unsigned long *_eflags)
+{
+ switch (c->modrm_reg) {
+ case 0: /* rol */
+ emulate_2op_SrcB("rol", c->src, c->dst, *_eflags);
+ break;
+ case 1: /* ror */
+ emulate_2op_SrcB("ror", c->src, c->dst, *_eflags);
+ break;
+ case 2: /* rcl */
+ emulate_2op_SrcB("rcl", c->src, c->dst, *_eflags);
+ break;
+ case 3: /* rcr */
+ emulate_2op_SrcB("rcr", c->src, c->dst, *_eflags);
+ break;
+ case 4: /* sal/shl */
+ case 6: /* sal/shl */
+ emulate_2op_SrcB("sal", c->src, c->dst, *_eflags);
+ break;
+ case 5: /* shr */
+ emulate_2op_SrcB("shr", c->src, c->dst, *_eflags);
+ break;
+ case 7: /* sar */
+ emulate_2op_SrcB("sar", c->src, c->dst, *_eflags);
+ break;
+ }
+}
+
+static inline int emulate_grp3(struct x86_emulate_ctxt *ctxt,
+ struct x86_emulate_ops *ops,
+ unsigned long *_eflags)
+{
+ struct decode_cache *c = &ctxt->decode;
+ int rc = 0;
+
+ switch (c->modrm_reg) {
+ case 0 ... 1: /* test */
+ /*
+* Special case in Grp3: test has an immediate
+* source operand.
+*/
+ c->src.type = OP_IMM;
+ c->src.ptr = (unsigned long *)c->eip;
+ c->src.bytes = (c->d & ByteOp) ? 1 : c->op_bytes;
+ if (c->src.bytes == 8)
+ c->src.bytes = 4;
+ switch (c->src.bytes) {
+ case 1:
+ c->src.val = insn_fetch(s8, 1, c->eip);
+ break;
+ case 2:
+ c->src.val = insn_fetch(s16, 2, c->eip);
+ break;
+ case 4:
+ c->src.val = insn_fetch(s32, 4, c->eip);
+ break;
+ }
+ emulate_2op_SrcV("test", c->src, c->dst, *_eflags);
+ break;
+ case 2: /* not */
+ c->dst.val = ~c->dst.val;
+ break;
+ case 3: /* neg */
+ emulate_1op("neg", c->dst, *_eflags);
+ break;
+ default:
+ DPRINTF("Cannot emulate %02x\n", c->b);
+ rc = X86EMUL_UNHANDLEABLE;
+ break;
+ }
+done:
+ return rc;
+}
+
+static inline int emulate_grp45(struct x86_emulate_ctxt *ctxt,
+ struct x86_emulate_ops *ops,
+ unsigned long *_eflags,
+ int *no_wb)
+{
+ struct decode_cache *c = &ctxt->decode;
+ int rc;
+
+ switch (c->modrm_reg) {
+ case 0: /* inc */
+ emulate_1op("inc", c->dst, *_eflags);
+ break;
+ case 1: /* dec */
+ emulate_1op("dec", c->dst, *_eflags);
+ break;
+ case 4: /* jmp abs */
+ if (c->b == 0xff)
+ c->eip = c->dst.val;
+ else {
+ DPRINTF("Cannot emulate %02x\n", c->b);
+ return X86EMUL_UNHANDLEABLE;
+ }
+ break;
+ case 6: /* push */
+
+ /* 64-bit mode: PUSH always pushes a 64-bit operand.
[kvm-devel] [PATCH 3/3] remove no_wb
Remove no_wb, use dst.type = OP_NONE instead, idea stollen from xen-3.1
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
drivers/kvm/x86_emulate.c | 76 ++--
drivers/kvm/x86_emulate.h |2 +-
2 files changed, 25 insertions(+), 53 deletions(-)
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index 2f8cb16..c614f96 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -1004,8 +1004,7 @@ done:
}
static inline int emulate_grp45(struct x86_emulate_ctxt *ctxt,
- struct x86_emulate_ops *ops,
- int *no_wb)
+ struct x86_emulate_ops *ops)
{
struct decode_cache *c = &ctxt->decode;
int rc;
@@ -1043,7 +1042,7 @@ static inline int emulate_grp45(struct x86_emulate_ctxt
*ctxt,
c->dst.bytes, ctxt->vcpu);
if (rc != 0)
return rc;
- *no_wb = 1;
+ c->dst.type = OP_NONE;
break;
default:
DPRINTF("Cannot emulate %02x\n", c->b);
@@ -1124,6 +1123,10 @@ static inline int writeback(struct x86_emulate_ctxt
*ctxt,
ctxt->vcpu);
if (rc != 0)
return rc;
+ break;
+ case OP_NONE:
+ /* no writeback */
+ break;
default:
break;
}
@@ -1134,7 +1137,6 @@ int
x86_emulate_insn(struct x86_emulate_ctxt *ctxt, struct x86_emulate_ops *ops)
{
unsigned long cr2 = ctxt->cr2;
- int no_wb = 0;
u64 msr_data;
unsigned long saved_rcx = 0, saved_eip = 0;
struct decode_cache *c = &ctxt->decode;
@@ -1346,7 +1348,7 @@ x86_emulate_insn(struct x86_emulate_ctxt *ctxt, struct
x86_emulate_ops *ops)
case 0xe9: /* jmp rel */
case 0xeb: /* jmp rel short */
JMP_REL(c->src.val);
- no_wb = 1; /* Disable writeback. */
+ c->dst.type = OP_NONE; /* Disable writeback. */
break;
case 0xf6 ... 0xf7: /* Grp3 */
rc = emulate_grp3(ctxt, ops);
@@ -1354,18 +1356,16 @@ x86_emulate_insn(struct x86_emulate_ctxt *ctxt, struct
x86_emulate_ops *ops)
goto done;
break;
case 0xfe ... 0xff: /* Grp4/Grp5 */
- rc = emulate_grp45(ctxt, ops, &no_wb);
+ rc = emulate_grp45(ctxt, ops);
if (rc != 0)
goto done;
break;
}
writeback:
- if (!no_wb) {
- rc = writeback(ctxt, ops);
- if (rc != 0)
- goto done;
- }
+ rc = writeback(ctxt, ops);
+ if (rc != 0)
+ goto done;
/* Commit shadow register state. */
memcpy(ctxt->vcpu->regs, c->regs, sizeof c->regs);
@@ -1406,7 +1406,7 @@ special_insn:
register_address_increment(c->regs[VCPU_REGS_RSP],
c->op_bytes);
- no_wb = 1; /* Disable writeback. */
+ c->dst.type = OP_NONE; /* Disable writeback. */
break;
case 0x6c: /* insb */
case 0x6d: /* insw/insd */
@@ -1534,8 +1534,6 @@ special_insn:
twobyte_insn:
switch (c->b) {
case 0x01: /* lgdt, lidt, lmsw */
- /* Disable writeback. */
- no_wb = 1;
switch (c->modrm_reg) {
u16 size;
unsigned long address;
@@ -1589,56 +1587,30 @@ twobyte_insn:
default:
goto cannot_emulate;
}
+ /* Disable writeback. */
+ c->dst.type = OP_NONE;
break;
case 0x21: /* mov from dr to reg */
- no_wb = 1;
if (c->modrm_mod != 3)
goto cannot_emulate;
rc = emulator_get_dr(ctxt, c->modrm_reg, &c->regs[c->modrm_rm]);
+ if (rc)
+ goto cannot_emulate;
+ c->dst.type = OP_NONE; /* no writeback */
break;
case 0x23: /* mov from reg to dr */
- no_wb = 1;
if (c->modrm_mod != 3)
goto cannot_emulate;
rc = emulator_set_dr(ctxt, c->modrm_reg,
c->regs[c->modrm_rm]);
+ if (rc)
+ goto cannot_emulate;
+ c->dst.type = OP_NONE; /* no writeback */
break;
case 0x40 ... 0x4f: /* cmov */
c->dst.val = c->dst.orig_val = c->src.val;
- no_wb = 1;
- /*
-* First, assume we're decoding an even cmov opcode
-* (lsb == 0).
-*/
-
[kvm-devel] [ kvm-Bugs-1799590 ] save/restore 64-bit linux guests fails
Bugs item #1799590, was opened at 2007-09-21 19:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1799590&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: yunfeng (yunfeng) Assigned to: Nobody/Anonymous (nobody) Summary: save/restore 64-bit linux guests fails Initial Comment: Environment: HOST (ia32/ia32e/IA64): 32e GUEST (ia32/ia32e/IA64): 32e COMMIT: 06f0698c5ee2e3be7e5ce3c6148bdd7a11af4644-114b08b348ab2c63e4bddc742cbcbd1f1b271f3e Hardware: paxville Bug detailed description: -- restore 64bit linux guest fails The error info: Migration failed rc=201 Reproduce steps: 1. prepare 32e linux guest image qemu-img create -b /share/xvs/img/ia32e_UP/ia32e_rhel4u3.img -f qcow /share/xvs/var/tmp- img_CPL_SR_46_1190345331_1 2. boot up a 64bit linux guest qemu-system-x86_64 . -m 256 -monitor pty -net nic,macaddr=00:16:3e:1c:47:4d,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /share/xvs/var/tmp-img_CPL_SR_46_1190345331_1 3. save guest in qemu cmd shell migrate "exec:dd of=/share/install/aaa" 4. restore saved guest qemu-system-x86_64 . -m 256 -net nic,macaddr=00:16:3e:1c:47:4d,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /share/xvs/var/tmp-img_CPL_SR_46_1190345331_1 - incoming /share/install/aaa Current result: Expected result: -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1799590&group_id=180599 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 0/3] Make some cleanup in x86_emulate.c
This patch series makes some cleanups in x86_emulate.c [PATCH 1/3] move some parts of x86_decode_insn() into functions. [PATCH 2/3] remove _eflags and use directly ctxt->eflags [PATCH 3/3] remove no_wb - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 2/3] remove _eflags and use directly ctxt->eflags.
Remove _eflags and use directly ctxt->eflags. Caching eflags is not needed as
it is restored to vcpu by kvm_main.c:emulate_instruction() from ctxt->eflags
only if emulation doesn't fail
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
drivers/kvm/x86_emulate.c | 120 ++---
1 files changed, 58 insertions(+), 62 deletions(-)
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index 67fe1e1..2f8cb16 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -929,37 +929,37 @@ static inline int emulate_grp1a(struct x86_emulate_ctxt
*ctxt, struct x86_emulat
return 0;
}
-static inline void emulate_grp2(struct decode_cache *c, unsigned long *_eflags)
+static inline void emulate_grp2(struct x86_emulate_ctxt *ctxt)
{
+ struct decode_cache *c = &ctxt->decode;
switch (c->modrm_reg) {
case 0: /* rol */
- emulate_2op_SrcB("rol", c->src, c->dst, *_eflags);
+ emulate_2op_SrcB("rol", c->src, c->dst, ctxt->eflags);
break;
case 1: /* ror */
- emulate_2op_SrcB("ror", c->src, c->dst, *_eflags);
+ emulate_2op_SrcB("ror", c->src, c->dst, ctxt->eflags);
break;
case 2: /* rcl */
- emulate_2op_SrcB("rcl", c->src, c->dst, *_eflags);
+ emulate_2op_SrcB("rcl", c->src, c->dst, ctxt->eflags);
break;
case 3: /* rcr */
- emulate_2op_SrcB("rcr", c->src, c->dst, *_eflags);
+ emulate_2op_SrcB("rcr", c->src, c->dst, ctxt->eflags);
break;
case 4: /* sal/shl */
case 6: /* sal/shl */
- emulate_2op_SrcB("sal", c->src, c->dst, *_eflags);
+ emulate_2op_SrcB("sal", c->src, c->dst, ctxt->eflags);
break;
case 5: /* shr */
- emulate_2op_SrcB("shr", c->src, c->dst, *_eflags);
+ emulate_2op_SrcB("shr", c->src, c->dst, ctxt->eflags);
break;
case 7: /* sar */
- emulate_2op_SrcB("sar", c->src, c->dst, *_eflags);
+ emulate_2op_SrcB("sar", c->src, c->dst, ctxt->eflags);
break;
}
}
static inline int emulate_grp3(struct x86_emulate_ctxt *ctxt,
- struct x86_emulate_ops *ops,
- unsigned long *_eflags)
+ struct x86_emulate_ops *ops)
{
struct decode_cache *c = &ctxt->decode;
int rc = 0;
@@ -986,13 +986,13 @@ static inline int emulate_grp3(struct x86_emulate_ctxt
*ctxt,
c->src.val = insn_fetch(s32, 4, c->eip);
break;
}
- emulate_2op_SrcV("test", c->src, c->dst, *_eflags);
+ emulate_2op_SrcV("test", c->src, c->dst, ctxt->eflags);
break;
case 2: /* not */
c->dst.val = ~c->dst.val;
break;
case 3: /* neg */
- emulate_1op("neg", c->dst, *_eflags);
+ emulate_1op("neg", c->dst, ctxt->eflags);
break;
default:
DPRINTF("Cannot emulate %02x\n", c->b);
@@ -1005,7 +1005,6 @@ done:
static inline int emulate_grp45(struct x86_emulate_ctxt *ctxt,
struct x86_emulate_ops *ops,
- unsigned long *_eflags,
int *no_wb)
{
struct decode_cache *c = &ctxt->decode;
@@ -1013,10 +1012,10 @@ static inline int emulate_grp45(struct x86_emulate_ctxt
*ctxt,
switch (c->modrm_reg) {
case 0: /* inc */
- emulate_1op("inc", c->dst, *_eflags);
+ emulate_1op("inc", c->dst, ctxt->eflags);
break;
case 1: /* dec */
- emulate_1op("dec", c->dst, *_eflags);
+ emulate_1op("dec", c->dst, ctxt->eflags);
break;
case 4: /* jmp abs */
if (c->b == 0xff)
@@ -1055,7 +1054,6 @@ static inline int emulate_grp45(struct x86_emulate_ctxt
*ctxt,
static inline int emulate_grp9(struct x86_emulate_ctxt *ctxt,
struct x86_emulate_ops *ops,
- unsigned long *_eflags,
unsigned long cr2)
{
struct decode_cache *c = &ctxt->decode;
@@ -1071,7 +1069,7 @@ static inline int emulate_grp9(struct x86_emulate_ctxt
*ctxt,
c->regs[VCPU_REGS_RAX] = (u32) (old >> 0);
c->regs[VCPU_REGS_RDX] = (u32) (old >> 32);
- *_eflags &= ~EFLG_ZF;
+ ctxt->eflags &= ~EFLG_ZF;
} else {
new = ((u64)c->regs[VCPU_REGS_RCX] << 32) | (u32)
c->regs[VCPU_REGS_RBX];
@@ -1079,7 +1077,7 @@ static inline int emulate_grp9(struct x86_emulate_ctxt
*ctxt,
rc = ops->cmpxchg_emulated(cr2, &old, &new, 8, ctxt->vcpu);
Re: [kvm-devel] [PATCH 2/6] virtio_config
On Thu, 2007-09-20 at 14:55 +0200, Avi Kivity wrote: > Avi Kivity wrote: > > Rusty Russell wrote: > >> Previous versions of virtio didn't commonalize probing. For every > >> driver, every virtio implementation (KVM, lguest, etc) needed an > >> in-kernel stub to join their bus to the probe code. > >> > >> To solve this, we introduce a "virtio_config" mechanism, which is > >> simply a set of [u8 type][u8 len][...data...] fields for each device. > >> Some convenient wrapper functions make this fairly easy for drivers to > >> unpack their configuration data themselves. > >> > >> This configuration data could be PCI config space, or an unrelated bus > >> (eg. lguest) or manufactured by the kernel itself. It's designed to > >> be extensible: fields get marked as the device reads them so a host > >> supporting some future extension can tell if the guest driver > >> understood it. This also applies to bitfields: the guest explicitly > >> acks the bits it understands. > >> > >> There's also a simple status bitmask useful for low-level host > >> analysis of what the guest is doing with the device. > >> > >> > > > > Lovely. > > > > A side effect of this is that Xen drivers can no longer use virtio. I'm not so sure. We were always assuming that Xen could do state management in its virtio layer. If this is not true, it implies we need hooks in the virtio drivers, and I don't think we've made it worse by making it translate xenbus config info into virtio_config. Rusty. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 6/6] virtio ring helper
On Thu, 2007-09-20 at 14:43 +0200, Avi Kivity wrote: > Rusty Russell wrote: > > These helper routines supply most of the virtqueue_ops for hypervisors > > which want to use a ring for virtio. Unlike the previous lguest > > implementation: > > > > 3) The page numbers are always 64 bit (PAE anyone?) > > > > 32 bits of page numbers give 44 bits of physical address on x86. That's > 16TB per guest. Admittedly it's smaller on a VAX. I like to feel that I make these mistakes to ensure others are paying attention. However, it does mean that I can just put an address in there and increase the length field to 32 bits. Much rejoicing. Will fix and resend tomorrow (Friday is in-office-away-from-test-machine day). > I don't like the chaining and would prefer the descriptor to refer to an > array of page descriptors. However I can't complain since this isn't > common code. The intent is for kvm to use it. I'll certainly consider your patches, although I suspect that managing descriptor pages will make things ugly enough to cause you to reconsider. Thanks! Rusty. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/6] virtio with config abstraction and ring implementation
On Thu, 2007-09-20 at 15:43 +0200, Dor Laor wrote:
> Rusty Russell wrote:
> > Drivers now unpack their own configuration: their probe() methods
> > are
> > uniform. The configuration mechanism is extensible and can be backed by
> > PCI, a string of bytes, or something else.
> I like the separation of the ring code, the improved descriptors and
> the notify too.
> Regarding the pci config space, I rather see config_ops type of
> operations to let
> the 390/xen/other implementations jump on our wagon.
It's possible to abstract at the find_config() level, but it's also not
too bad to linearize any existing configuration. I chose to change the
lguest device page to use a linearized format, but I could have adapted
the old device info struct in the kernel without too much hassle:
FYI, here's the lguest snippet, for example:
+struct lguest_config {
+ struct virtio_config_space v;
+
+ /* Status pointer: 4 bytes, then comes the config space itself. */
+ u8 *status;
+};
...
+static void lguest_writeb(struct virtio_config_space *v, unsigned off, u8 b)
+{
+ struct lguest_config *c = container_of(v, struct lguest_config, v);
+
+ c->status[4 + off] = b;
+}
+
+static u8 lguest_readb(struct virtio_config_space *v, unsigned off)
+{
+ struct lguest_config *c = container_of(v, struct lguest_config, v);
+
+ return c->status[4 + off];
+}
+
+static void lguest_set_status(struct virtio_config_space *v, u32 status)
+{
+ struct lguest_config *c = container_of(v, struct lguest_config, v);
+
+ memcpy(c->status, &status, sizeof(status));
+}
+
+static u32 lguest_get_status(struct virtio_config_space *v)
+{
+ struct lguest_config *c = container_of(v, struct lguest_config, v);
+ u32 status;
+
+ memcpy(&status, c->status, sizeof(status));
+ return status;
+}
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/6] virtio interace
On Thu, 2007-09-20 at 14:27 +0200, Avi Kivity wrote: > Rusty Russell wrote: > > +struct virtio_backend_ops virtio_backend_ops; > > +EXPORT_SYMBOL_GPL(virtio_backend_ops); > > Suggest calling this virtio_transport_ops rather than the too-generic > virtio_backend_ops. Especially since Xen uses backend for something > completely different. Hi Avi, Agreed, fixed. I actually don't like this interface at all, but it is simple until we determine something better. > > +/** > > + * virtqueue_ops - operations for virtqueue abstraction layer > > + * @new_vq: create a new virtqueue > > + * config: the virtio_config_space field describing the queue > > + * off: the offset in the config space of the queue configuration > > + * len: the length of the virtio_config_space field > > > > 'off, len' are really a magic cookie. Why does the interface care about > their meaning? off is a cookie, len isn't. The driver does "get me the foo field" and it returns off + len. If it wants to read or write the foo field it needs that length. In practice, drivers use the virtio_config_vq() convenience interface which does "find field, hand to ops->new_vq". > > + * callback: the driver callback when the queue is used. > > > > Missing callback return value description. Indeed, that's always made me uncomfortable. Fixed. Although it's possible that an explicit disable hook is better... > > + * @kick: update after add_buf > > + * vq: the struct virtqueue > > + * After one or more add_buf calls, invoke this to kick the virtio layer. > > > > 'the other side' Thanks, fixed. > I'm not thrilled about reusing pci ids. Maybe the s390 can say whether > this is a real issue. I doubt it: it's not a problem for lguest. But I wonder if I've chosen the right fields... Rusty. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 4/6] virtio block driver
On Fri, Sep 21 2007, Rusty Russell wrote:
> On Thu, 2007-09-20 at 15:05 +0200, Jens Axboe wrote:
> > On Thu, Sep 20 2007, Rusty Russell wrote:
> > > +static void end_dequeued_request(struct request *req,
> > > + struct request_queue *q, int uptodate)
> > > +{
> > > + /* And so the insanity of the block layer infects us here. */
> > > + int nsectors = req->hard_nr_sectors;
> > > +
> > > + if (blk_pc_request(req)) {
> > > + nsectors = (req->data_len + 511) >> 9;
> > > + if (!nsectors)
> > > + nsectors = 1;
> > > + }
> > > + if (end_that_request_first(req, uptodate, nsectors))
> > > + BUG();
> > > + add_disk_randomness(req->rq_disk);
> > > + end_that_request_last(req, uptodate);
> > > +}
> >
> > We have end_queued_request(), lets add end_dequeued_request(). Below.
>
> OK, thanks, I'll throw that in the mix and test...
I've queued it for 2.6.24 as well, so should be in mainline in that time
frame.
> > > + vblk->sg[0].page = virt_to_page(&vbr->out_hdr);
> > > + vblk->sg[0].offset = offset_in_page(&vbr->out_hdr);
> > > + vblk->sg[0].length = sizeof(vbr->out_hdr);
> > > + num = blk_rq_map_sg(q, vbr->req, vblk->sg+1);
> >
> > This wont work for chained sglists, but I gather (I'm so funny) that it
> > wont be an issue for you. How large are your sglists?
>
> Hmm, potentially extremely large. What do I need to do for chained
> sglists?
Not a lot, actually. You snipped the problematic part in your reply,
though:
vblk->sg[num+1].page = virt_to_page(&vbr->in_hdr);
which assumes that sg is a contigious piece of memory, for chained sg
lists that isn't true. sg chaining will be in 2.6.24, so if you really
do need large sglists, then that's the way to go.
blk_rq_map_sg() maps correctly for you, no changes needed there. But you
want to use sg_last() for adding to the end of the sglist. And then use
sg_next() to retrieve the next sg segment instead of sg + 1, and
for_each_sg() to loop over all segments.
Just something to keep in mind, if you plan on merging this post 2.6.23.
> > > + if (!do_req(q, vblk, req)) {
> > > + /* Queue full? Wait. */
> > > + blk_stop_queue(q);
> > > + break;
> > > + }
> >
> > Personally I think this bool stuff is foul. You return false/true, but
> > still use ! to test. That is just more confusing than the canonical 0/1
> > good/bad return imho.
>
> Except "0/1" is not canonical in the kernel. Arguably, "-errno/0" is
> canonical. OTOH, bool is clear.
-errno/0, then. 1 is typically used for 'failure without specific error
number' when -Exx doesn't apply. Like the above :-)
But lets just agree to disagree on the bool.
> if do_req() fails, we assume the queue is full. I shall change the
> comment to that effect.
Thanks!
--
Jens Axboe
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 4/6] virtio block driver
On Thu, 2007-09-20 at 14:27 +0200, Jens Axboe wrote: > On Thu, Sep 20 2007, Rusty Russell wrote: > > The block driver uses scatter-gather lists with sg[0] being the > > request information (struct virtio_blk_outhdr) with the type, sector > > and inbuf id. The next N sg entries are the bio itself, then the last > > sg is the status byte. Whether the N entries are in or out depends on > > whether it's a read or a write. > > > > We accept the normal (SCSI) ioctls: they get handed through to the other > > side which can then handle it or reply that it's unsupported. It's > > not clear that this actually works in general, since I don't know > > if blk_pc_request() requests have an accurate rq_data_dir(). > > They should, if they imply a data transfer. OK, good. We rely on that to mark input vs output sg elements. I was wondering if there was some weird requests which did both input and output. > > Although we try to reply -ENOTTY on unsupported commands, the block > > layer in its infinite wisdom suppressed the error so ioctl(fd, > > CDROMEJECT) returns success to userspace. > > How about ever submitting a patch for that, instead of just repeatedly > complaining about it? To be fair, I've left the complaint in that same patch, you're just reading it repeatedly 8) I shall look through the code and see if I can figure out how to fix it. I'm assuming from your response that there's not some strange reason to preserve current behaviour. Thanks! Rusty. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 4/6] virtio block driver
On Thu, 2007-09-20 at 15:05 +0200, Jens Axboe wrote:
> On Thu, Sep 20 2007, Rusty Russell wrote:
> > +static void end_dequeued_request(struct request *req,
> > +struct request_queue *q, int uptodate)
> > +{
> > + /* And so the insanity of the block layer infects us here. */
> > + int nsectors = req->hard_nr_sectors;
> > +
> > + if (blk_pc_request(req)) {
> > + nsectors = (req->data_len + 511) >> 9;
> > + if (!nsectors)
> > + nsectors = 1;
> > + }
> > + if (end_that_request_first(req, uptodate, nsectors))
> > + BUG();
> > + add_disk_randomness(req->rq_disk);
> > + end_that_request_last(req, uptodate);
> > +}
>
> We have end_queued_request(), lets add end_dequeued_request(). Below.
OK, thanks, I'll throw that in the mix and test...
> > + vblk->sg[0].page = virt_to_page(&vbr->out_hdr);
> > + vblk->sg[0].offset = offset_in_page(&vbr->out_hdr);
> > + vblk->sg[0].length = sizeof(vbr->out_hdr);
> > + num = blk_rq_map_sg(q, vbr->req, vblk->sg+1);
>
> This wont work for chained sglists, but I gather (I'm so funny) that it
> wont be an issue for you. How large are your sglists?
Hmm, potentially extremely large. What do I need to do for chained
sglists?
> > + if (!do_req(q, vblk, req)) {
> > + /* Queue full? Wait. */
> > + blk_stop_queue(q);
> > + break;
> > + }
>
> Personally I think this bool stuff is foul. You return false/true, but
> still use ! to test. That is just more confusing than the canonical 0/1
> good/bad return imho.
Except "0/1" is not canonical in the kernel. Arguably, "-errno/0" is
canonical. OTOH, bool is clear.
if do_req() fails, we assume the queue is full. I shall change the
comment to that effect.
Thanks!
Rusty.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ kvm-Bugs-1799596 ] Cannot boot acpi smp windows guest
Bugs item #1799596, was opened at 2007-09-21 19:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1799596&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: yunfeng (yunfeng) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot boot acpi smp windows guest Initial Comment: HOST (ia32/ia32e/IA64): 32e GUEST (ia32/ia32e/IA64): 32e COMMIT: 06f0698c5ee2e3be7e5ce3c6148bdd7a11af4644-114b08b348ab2c63e4bddc742cbcbd1f1b 271f3e Hardware: paxville Bug detailed description: -- acpi smp windows guest cannot be booted up. The guest will hang when booting process shows microsoft logo. See the attached snapshot. Current result: Expected result: -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1799596&group_id=180599 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/6] virtio interace
On Thursday 20 September 2007, Rusty Russell wrote:
> + * virtio_driver - operations for a virtio I/O driver
> + * @name: the name of the driver (KBUILD_MODNAME).
> + * @owner: the module which contains these routines (ie. THIS_MODULE).
> + * @id_table: the ids (we re-use PCI ids) serviced by this driver.
> + * @probe: the function to call when a device is found. Returns a token for
> + * remove, or PTR_ERR().
> + * @remove: the function when a device is removed.
> + */
> +struct virtio_driver {
> + const char *name;
> + struct module *owner;
> + struct pci_device_id *id_table;
> + void *(*probe)(struct device *device,
> + struct virtio_config_space *config,
> + struct virtqueue_ops *vqops);
> + void (*remove)(void *dev);
> +};
> +
> +int register_virtio_driver(struct virtio_driver *drv);
> +void unregister_virtio_driver(struct virtio_driver *drv);
> +
> +/* The particular virtio backend supplies these. */
> +struct virtio_backend_ops {
> + int (*register_driver)(struct virtio_driver *drv);
> + void (*unregister_driver)(struct virtio_driver *drv);
> +};
> +extern struct virtio_backend_ops virtio_backend_ops;
This still seems a little awkward. From what I understand, you register
a virtio_driver, which leads to a pci_driver (or whatever you are based on)
to be registered behind the covers, so that the pci_device can be used
directly as the virtio device.
I think there should instead be a pci_driver that automatically binds
to all PCI based virtio imlpementations and creates a child device for
the actual virtio_device. Then you can have the virtio_driver itself
be based on a device_driver, and you can get rid of the global
virtio_backend_ops. That will be useful when a virtual machine
has two ways to get at the virtio devices, e.g. a KVM guest that
has both hcall based probing for virtio devices and some other virtio
devices that are exported through PCI.
Arnd <><
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/6] virtio net driver
On Fri, 2007-09-21 at 12:48 +0200, Christian Borntraeger wrote:
> Am Donnerstag, 20. September 2007 schrieb Rusty Russell:
> > The network driver uses *two* virtqueues: one for input packets and
> > one for output packets. This has nice locking properties (ie. we
> > don't do any for recv vs send).
> [...]
> > 3) Resolve freeing of old xmit skbs (someone sent patch IIRC?)
>
> Yes, that was me. I am quite busy at the moment but I will send a refreshed
> patch soon. The most annoying fact of my current patch is, that I have to add
> locking. (Because of the only one operation per virtqueue at a time rule)
Sorry Christian, I thought it was you but was in a hurry to send out the
patches so didn't go back and check.
Can't we just re-use the default xmit lock?
> [...]
> > +struct virtnet_info
> > +{
> > + struct virtqueue_ops *vq_ops;
> > + struct virtqueue *vq_recv;
> > + struct virtqueue *vq_send;
> > + struct net_device *ndev;
>
> This is only a matter of taste, but I like netdev or dev more than ndev.
Yeah, I agreed. It was a moment of weakness: I've renamed it to "dev".
Thanks!
Rusty.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 4/6] virtio block driver
On Fri, Sep 21 2007, Rusty Russell wrote: > On Thu, 2007-09-20 at 14:27 +0200, Jens Axboe wrote: > > On Thu, Sep 20 2007, Rusty Russell wrote: > > > The block driver uses scatter-gather lists with sg[0] being the > > > request information (struct virtio_blk_outhdr) with the type, sector > > > and inbuf id. The next N sg entries are the bio itself, then the last > > > sg is the status byte. Whether the N entries are in or out depends on > > > whether it's a read or a write. > > > > > > We accept the normal (SCSI) ioctls: they get handed through to the other > > > side which can then handle it or reply that it's unsupported. It's > > > not clear that this actually works in general, since I don't know > > > if blk_pc_request() requests have an accurate rq_data_dir(). > > > > They should, if they imply a data transfer. > > OK, good. We rely on that to mark input vs output sg elements. I was > wondering if there was some weird requests which did both input and > output. There very soon will be bidirectional requests with both in and out elements, but they will be clearly marked as such (and the driver needs to be marked capable). So nothing to worry about for now. > > > Although we try to reply -ENOTTY on unsupported commands, the block > > > layer in its infinite wisdom suppressed the error so ioctl(fd, > > > CDROMEJECT) returns success to userspace. > > > > How about ever submitting a patch for that, instead of just repeatedly > > complaining about it? > > To be fair, I've left the complaint in that same patch, you're just > reading it repeatedly 8) That may be the case :-) > I shall look through the code and see if I can figure out how to fix it. > I'm assuming from your response that there's not some strange reason to > preserve current behaviour. It surely sounds like a bug, if you issue ioctl(fd, CDROMEJECT), the driver sees it and returns -ENOTTY, but userland sees a 0 retval. So if you have time, please do poke at it a bit. -- Jens Axboe - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 4/6] virtio block driver
On Fri, 2007-09-21 at 13:47 +0200, Jens Axboe wrote:
> On Fri, Sep 21 2007, Rusty Russell wrote:
> > On Thu, 2007-09-20 at 15:05 +0200, Jens Axboe wrote:
> > > We have end_queued_request(), lets add end_dequeued_request(). Below.
> >
> > OK, thanks, I'll throw that in the mix and test...
>
> I've queued it for 2.6.24 as well, so should be in mainline in that time
> frame.
OK, I'll sit it in my queue so my patches work until then.
> > > > + vblk->sg[0].page = virt_to_page(&vbr->out_hdr);
> > > > + vblk->sg[0].offset = offset_in_page(&vbr->out_hdr);
> > > > + vblk->sg[0].length = sizeof(vbr->out_hdr);
> > > > + num = blk_rq_map_sg(q, vbr->req, vblk->sg+1);
> > >
> > > This wont work for chained sglists, but I gather (I'm so funny) that it
> > > wont be an issue for you. How large are your sglists?
> >
> > Hmm, potentially extremely large. What do I need to do for chained
> > sglists?
>
> Not a lot, actually. You snipped the problematic part in your reply,
> though:
>
> vblk->sg[num+1].page = virt_to_page(&vbr->in_hdr);
>
> which assumes that sg is a contigious piece of memory, for chained sg
> lists that isn't true. sg chaining will be in 2.6.24, so if you really
> do need large sglists, then that's the way to go.
I'm not sure if I need large sglists here. Obviously I want to handle
anything the block layer can give to me (assume you're going to increase
MAX_PHYS_SEGMENTS soon?). This might make "vblk" too big to kmalloc
easily:
struct virtio_blk
{
...
/* Scatterlist: can be too big for stack. */
struct scatterlist sg[3+MAX_PHYS_SEGMENTS];
};
The sglist for virtio is really a scratch space to represent the request
buffers (with one element for metadata at start and one at end) which we
hand through to the virtio layer which turns it into its internal
descriptors for the host to read.
Have you thought of putting an sglist inside the req itself? Then
instead of blk_rq_map_sg() it'd just be req->sg? It could just be a
chain of sg's in each bio I guess.
This would allow me to just to borrow that request sg chain, rather than
doing the req -> sg -> virtio double-conversion.
> > Except "0/1" is not canonical in the kernel. Arguably, "-errno/0" is
> > canonical. OTOH, bool is clear.
>
> -errno/0, then. 1 is typically used for 'failure without specific error
> number' when -Exx doesn't apply. Like the above :-)
See, I'd be absolutely sure that >= 0 is success (like all syscalls),
and I'd be appalled by code which used it as failure.
So I think you're right that we should agree to disagree :)
Thanks!
Rusty.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Test result for KVM, kernel 06f0698c.. , userspace 114b08b..
Hi, all, This is today's KVM test result against kvm.git 06f0698c5ee2e3be7e5ce3c6148bdd7a11af4644 and kvm-userspace.git 114b08b348ab2c63e4bddc742cbcbd1f1b271f3e. 2 New issues found 1. save/restore 64-bit linux guest fails https://sourceforge.net/tracker/index.php?func=detail&aid=1799590&group_ id=180599&atid=893831 2. Cannot boot smp windows guests SMP XP windows guest will hang SMP win2k guest will turn black SMP 2003 windows reports driver error. https://sourceforge.net/tracker/index.php?func=detail&aid=1799596&group_ id=180599&atid=893831 One issue fixed: 1. booting 64bit vista causes host to hang https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1798550&gro up_id=180599 Old issues: 1. 64bit guest with >1.5GBmem cannot start network https://sourceforge.net/tracker/index.php?func=detail&aid=1792984&group_ id=180599&atid=893831 2. Cannot boot win2k guest https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1768187&gro up_id=180599 3. Network issue of 64bit linux guest https://sourceforge.net/tracker/index.php?func=detail&aid=1796939&group_ id=180599&atid=893831 4. blue screen while install 64bit vista https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1796941&gro up_id=180599 5. Create multiple guests simultaneously or create one guest many times may fail https://sourceforge.net/tracker/index.php?func=detail&aid=1741312&group_ id=180599&atid=893831 6. Can not boot IA32e RHEL 4u3 guest with -no-acpi https://sourceforge.net/tracker/index.php?func=detail&aid=1741314&group_ id=180599&atid=893831 7. Some ltp test cases fail https://sourceforge.net/tracker/index.php?func=detail&aid=1741316&group_ id=180599&atid=893831 8. Linux guest crash without nolapic, 2.6.22 kernel. https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1769884&gro up_id=180599 Thanks Yunfeng - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/6] virtio net driver
Am Freitag, 21. September 2007 schrieb Rusty Russell:
> Can't we just re-use the default xmit lock?
yes we can.
This patch is untested but is basically an refresh of an ealier version. I
currently have no code testable with the latest virtio version from this mail
thread, so if you could apply this (It still has the ndev name) and test the
patch? Thanks
Christian
---
Use the sent interrupt for xmit reclaim.
---
drivers/net/virtio_net.c | 43 ++-
1 file changed, 26 insertions(+), 17 deletions(-)
Index: virtio/drivers/net/virtio_net.c
===
--- virtio.orig/drivers/net/virtio_net.c
+++ virtio/drivers/net/virtio_net.c
@@ -52,10 +52,29 @@ static inline void vnet_hdr_to_sg(struct
sg_init_one(sg, skb_vnet_hdr(skb), sizeof(struct virtio_net_hdr));
}
+static void free_old_xmit_skbs(struct net_device *dev)
+{
+ struct virtnet_info *vi = netdev_priv(dev);
+ struct sk_buff *skb;
+ unsigned int len;
+
+ netif_tx_lock(dev);
+ while ((skb = vi->vq_ops->get_buf(vi->vq_send, &len)) != NULL) {
+ pr_debug("Sent skb %p\n", skb);
+ __skb_unlink(skb, &vi->send);
+ dev->stats.tx_bytes += len;
+ dev->stats.tx_packets++;
+ dev_kfree_skb_irq(skb);
+ }
+ netif_tx_unlock(dev);
+}
+
static bool skb_xmit_done(void *ndev)
{
/* In case we were waiting for output buffers. */
netif_wake_queue(ndev);
+ /* reclaim sent skbs */
+ fre_old_xmit_skbs(ndev);
return true;
}
@@ -209,20 +228,6 @@ again:
return 0;
}
-static void free_old_xmit_skbs(struct virtnet_info *vi)
-{
- struct sk_buff *skb;
- unsigned int len;
-
- while ((skb = vi->vq_ops->get_buf(vi->vq_send, &len)) != NULL) {
- pr_debug("Sent skb %p\n", skb);
- __skb_unlink(skb, &vi->send);
- vi->ndev->stats.tx_bytes += len;
- vi->ndev->stats.tx_packets++;
- kfree_skb(skb);
- }
-}
-
static int start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct virtnet_info *vi = netdev_priv(dev);
@@ -235,8 +240,6 @@ static int start_xmit(struct sk_buff *sk
dev->name, skb,
dest[0], dest[1], dest[2], dest[3], dest[4], dest[5]);
- free_old_xmit_skbs(vi);
-
/* Encode metadata header at front. */
hdr = skb_vnet_hdr(skb);
if (skb->ip_summed == CHECKSUM_PARTIAL) {
@@ -267,15 +270,21 @@ static int start_xmit(struct sk_buff *sk
vnet_hdr_to_sg(sg, skb);
num = skb_to_sgvec(skb, sg+1, 0, skb->len) + 1;
+ local_irq_disable();
+ netif_tx_lock(dev);
__skb_queue_head(&vi->send, skb);
err = vi->vq_ops->add_buf(vi->vq_send, sg, num, 0, skb);
if (err) {
pr_debug("%s: virtio not prepared to send\n", dev->name);
skb_unlink(skb, &vi->send);
netif_stop_queue(dev);
+ netif_tx_unlock(dev);
+ local_irq_enable();
return NETDEV_TX_BUSY;
}
vi->vq_ops->kick(vi->vq_send);
+ netif_tx_unlock(dev);
+ local_irq_enable();
return 0;
}
@@ -335,7 +344,7 @@ static void *virtnet_probe(struct device
dev->poll = virtnet_poll;
dev->hard_start_xmit = start_xmit;
dev->weight = 16;
- dev->features = NETIF_F_HIGHDMA;
+ dev->features = NETIF_F_HIGHDMA | NETIF_F_LLTX;
SET_NETDEV_DEV(dev, device);
/* Do we support "hardware" checksums? */
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/6] virtio interace
On Fri, 2007-09-21 at 14:05 +0200, Arnd Bergmann wrote:
> On Thursday 20 September 2007, Rusty Russell wrote:
> > +int register_virtio_driver(struct virtio_driver *drv);
> > +void unregister_virtio_driver(struct virtio_driver *drv);
> > +
> > +/* The particular virtio backend supplies these. */
> > +struct virtio_backend_ops {
> > + int (*register_driver)(struct virtio_driver *drv);
> > + void (*unregister_driver)(struct virtio_driver *drv);
> > +};
> > +extern struct virtio_backend_ops virtio_backend_ops;
>
> This still seems a little awkward. From what I understand, you register
> a virtio_driver, which leads to a pci_driver (or whatever you are based on)
> to be registered behind the covers, so that the pci_device can be used
> directly as the virtio device.
Hi Arnd,
Yes, and I dislike it too.
> I think there should instead be a pci_driver that automatically binds
> to all PCI based virtio imlpementations and creates a child device for
> the actual virtio_device.
I'm not sure I understand. For PCI probing to work, you want to have
identified yourself as a driver for each PCI id claimed by a virtio
device.
Hmm, I guess we could have a PCI driver which claims all VIRTIO vendor
devices. Then it can call virtio_find_driver() (?) at the top of its
probe function to find if there's a matching virtio driver. This PCI
driver would have to be initialized after all the virtio drivers are
registered, but that's easy.
The virtio layer would simply maintain a linked list of drivers and
implement the virtio_find_driver() matching function.
And since we've suppressed normal PCI driver request_module (since it
always finds "the driver") then we can implement that in
virtio_find_driver(), and not use a PCI MODULE_DEVICE_TABLE. Then we
don't need (full) PCI ids at all.
OK, I have some coding to do now...
Rusty.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/6] virtio net driver
On Fri, Sep 21, 2007 at 02:36:43PM +0200, Christian Borntraeger wrote:
>
> @@ -335,7 +344,7 @@ static void *virtnet_probe(struct device
> dev->poll = virtnet_poll;
> dev->hard_start_xmit = start_xmit;
> dev->weight = 16;
> - dev->features = NETIF_F_HIGHDMA;
> + dev->features = NETIF_F_HIGHDMA | NETIF_F_LLTX;
> SET_NETDEV_DEV(dev, device);
>
> /* Do we support "hardware" checksums? */
Please don't use LLTX in new drivers. We're trying to get rid
of it since it's
1) unnecessary;
2) causes problems with AF_PACKET seeing things twice.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/6] virtio interace
On Friday 21 September 2007, Rusty Russell wrote:
> Hmm, I guess we could have a PCI driver which claims all VIRTIO vendor
> devices.
yes, that was the idea.
> Then it can call virtio_find_driver() (?) at the top of its
> probe function to find if there's a matching virtio driver.
> This PCI driver would have to be initialized after all the virtio
> drivers are registered, but that's easy.
No, just use the driver model, instead of working against it:
struct pci_virtio_device {
struct pci_dev *pdev;
char __iomem *mmio_space;
struct virtio_device vdev;
};
static int __devinit pci_virtio_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
struct pci_virtio_device *dev = kzalloc(sizeof (*dev), GFP_KERNEL);
dev->pdev = pdev;
dev->mmio_space = pcim_iomap(pdev, 0, PCI_VIRTIO_BUFSIZE);
dev->vdev->ops = &pci_virtqueue_ops;
dev->vdev->config = &pci_virtio_config_ops;
dev->vdev->type = ent->device;
dev->vdev->class = ent->class;
dev->vdev.dev.parent = &pdev->dev;
return virtio_device_register(&dev->vdev;
}
> The virtio layer would simply maintain a linked list of drivers and
> implement the virtio_find_driver() matching function.
nonono, just a virtio_bus that all virtio drivers register to:
static int virtio_net_probe(struct device *dev)
{
struct virtio_device *vdev = to_virtio_dev(dev);
struct virtqueue_ops *vq_ops = vdev->ops;
/* same as current code */
...
return 0;
}
static struct virtio_device_id virtio_net_ids[] = {
{ .type = VIRTIO_ID_NET, .class = PCI_CLASS_NETWORK_OTHER },
{ },
};
static struct virtio_driver virtio_net = {
.id_table = &virtio_net_ids,
.driver = {
.name = "virtionet",
.probe = virtio_net_probe,
.remove = virtionet_remove,
.bus = &virtio_bus,/* <- look here */
},
};
static int __init virtio_net_init(void)
{
return driver_register(&virtio_net.driver);
}
module_init(virtio_net_init);
> And since we've suppressed normal PCI driver request_module (since it
> always finds "the driver") then we can implement that in
> virtio_find_driver(), and not use a PCI MODULE_DEVICE_TABLE. Then we
> don't need (full) PCI ids at all.
right, as shown in my example above.
Arnd <><
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/6] virtio net driver
Am Freitag, 21. September 2007 schrieb Herbert Xu: > Please don't use LLTX in new drivers. We're trying to get rid > of it since it's > > 1) unnecessary; > 2) causes problems with AF_PACKET seeing things twice. Ok, but then I cannot reuse the xmit lock in an interrupt handler. Otherwise deadlock can occur because hard_start_xmit has interrupts enabled. Rusty, seems we need an additional lock. Christian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ kvm-Bugs-1799707 ] gentoo minimal installtion cd for amd64 hang after boot.
Bugs item #1799707, was opened at 2007-09-21 17:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1799707&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Izik Eidus (izike) Assigned to: Nobody/Anonymous (nobody) Summary: gentoo minimal installtion cd for amd64 hang after boot. Initial Comment: just after booting the iso file : install-amd64-minimal-2007.0.iso the guest hang and i see: irq 10: nobody cared (try booting with the "irqpoll" option) (with -no-kvm-irqchip it have no problem) i am runing with kvm-43 on core2du 2.6.22 64bits kernel thanks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1799707&group_id=180599 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-43 release
Avi Kivity wrote: > Only one fix, but an important one. It fixes booting of newer Linux > versions, which experienced disk and keyboard problems without > -no-kvm-irqchip. > > As usual, if you have an issue please try with -no-kvm-irqchip and report. Updated from -41. Now my libkvm-using-tool's kvm_callbacks->try_push_interrupts() callback isn't called any more. Hmm. Guess due to the lapic/irqchip changes. Are there any additional initializations I have to do now? As there isn't any real pic-like hardware emulated maybe using try_to_push_interrupts is a bad idea anyway and I should better move the code (checks state and calls kvm_inject_irq() if needed) to the pre_kvm_run() callback? hints anyone? Gerd - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-42 release
On 9/21/07, Avi Kivity <[EMAIL PROTECTED]> wrote: > Luca wrote: > > On 9/20/07, Avi Kivity <[EMAIL PROTECTED]> wrote: > > > >> Not much user visible change besides the OpenBSD regression fix. > >> > >> As usual, if you have an issue please try with -no-kvm-irqchip and report. > >> > > > > 32 bit Fedora7 on a 32 bit host (kvm-intel) dies due to screaming > > interrupts during IDE probe. Same problem with KVM-41 (last known > > working is KVM-36, I haven't tested anything in between). In both > > cases -no-kvm-irqchip fixes the problem. > > > > > > I fixed a couple of bugs in edge-triggered interrupts handling which > resolves this. May also resolve the Ubuntu keyboard issue. > > kvm-43 will be released shortly with this. Both VMs are working fine with 43. thanks, Luca - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ kvm-Bugs-1799961 ] Fresh Solaris install hangs at "Configuring Devices" stage
Bugs item #1799961, was opened at 2007-09-21 15:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1799961&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: kucharsk (kucharsk) Assigned to: Nobody/Anonymous (nobody) Summary: Fresh Solaris install hangs at "Configuring Devices" stage Initial Comment: After a fresh install, the iniital reboot of a freshly installed copy of Solaris will hang at the "Configuring Devices" stage. The boot progresses past the stage if run "--no-kvm." This is with kvm-42 running on kernel 2.6.22.5-76.fc7 on amd64 hardware. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1799961&group_id=180599 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [RESOLVED] kvm-36 losing (tap-based) network connectivity mid-session
As of kvm-43, this is no longer happening. I haven't tested intermediate versions to locate the exact place where the issue ceased. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-43 release
Gerd Hoffmann wrote: > Avi Kivity wrote: > >> Only one fix, but an important one. It fixes booting of newer Linux >> versions, which experienced disk and keyboard problems without >> -no-kvm-irqchip. >> >> As usual, if you have an issue please try with -no-kvm-irqchip and report. >> > > Updated from -41. Now my libkvm-using-tool's > kvm_callbacks->try_push_interrupts() callback isn't called any more. > Hmm. Guess due to the lapic/irqchip changes. Are there any additional > initializations I have to do now? > > As there isn't any real pic-like hardware emulated maybe using > try_to_push_interrupts is a bad idea anyway and I should better move the > code (checks state and calls kvm_inject_irq() if needed) to the > pre_kvm_run() callback? > > hints anyone? > You can call kvm_disable_irqchip_creation() to kill in-kernel pic and friends. (the logic is inverted -- the function should be kvm_enable_irqchip_creation() so that this problem would not occur) -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
