[kvm-devel] is renaming qcow2 images prohibited?
Hello, Kindly CC me in your replies, I'm not a subscriber. Is renaming qcow2 images prohibited? My VM behaves differently (hangs when boot is complete) after copying the image. sudo taskset 3 /usr/bin/kvm -m 1024 -hda test2-deb32-net.qcow -net nic,model=rtl8139,macaddr=52:54:00:00:00:15 -net tap,vlan=0,ifname=tap15 - Original image, this works fine. cp test2-deb32-net.qcow nxserver.qcow - Only after the image was shut down of course... sudo taskset 3 /usr/bin/kvm -m 1024 -hda nxserver.qcow -net nic,model=rtl8139,macaddr=52:54:00:00:00:15 -net tap,vlan=0,ifname=tap15 - Completes full boot sequence, but instead of throwing getty it somehow freezes (still unsure as to why) rm nxserver.qcow qemu-img convert test2-deb32-net.qcow -O qcow2 nxserver.qcow2 - This new nxserver.qcow2 image works perfectly once again. All images were created as qcow2 (ignore file extensions), but interestingly the original image is somehow recognised as raw format... image: test2-deb32-net.qcow file format: raw virtual size: 10G (10737418240 bytes) disk size: 652M I've also noticed this with win2003 guest images. I'm probably missing something or doing something stupid - I'd be glad if someone can point it out. Kind regards, Joris - 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] 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] [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. */
+
+ if (ctxt-mode == X86EMUL_MODE_PROT64) {
+ c-dst.bytes =
[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).
-*/
- switch ((c-b 15) 1) {
-
[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);
if (rc != 0)
return rc;
- *_eflags |= EFLG_ZF;
+ ctxt-eflags |= EFLG_ZF;
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 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=detailatid=893831aid=1799596group_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=detailatid=893831aid=1799596group_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 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
[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=detailaid=1799590group_ id=180599atid=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=detailaid=1799596group_ id=180599atid=893831 One issue fixed: 1. booting 64bit vista causes host to hang https://sourceforge.net/tracker/?func=detailatid=893831aid=1798550gro up_id=180599 Old issues: 1. 64bit guest with 1.5GBmem cannot start network https://sourceforge.net/tracker/index.php?func=detailaid=1792984group_ id=180599atid=893831 2. Cannot boot win2k guest https://sourceforge.net/tracker/?func=detailatid=893831aid=1768187gro up_id=180599 3. Network issue of 64bit linux guest https://sourceforge.net/tracker/index.php?func=detailaid=1796939group_ id=180599atid=893831 4. blue screen while install 64bit vista https://sourceforge.net/tracker/?func=detailatid=893831aid=1796941gro up_id=180599 5. Create multiple guests simultaneously or create one guest many times may fail https://sourceforge.net/tracker/index.php?func=detailaid=1741312group_ id=180599atid=893831 6. Can not boot IA32e RHEL 4u3 guest with -no-acpi https://sourceforge.net/tracker/index.php?func=detailaid=1741314group_ id=180599atid=893831 7. Some ltp test cases fail https://sourceforge.net/tracker/index.php?func=detailaid=1741316group_ id=180599atid=893831 8. Linux guest crash without nolapic, 2.6.22 kernel. https://sourceforge.net/tracker/?func=detailatid=893831aid=1769884gro 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 ~{PmVHI~} [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=detailatid=893831aid=1799707group_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=detailatid=893831aid=1799707group_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=detailatid=893831aid=1799961group_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=detailatid=893831aid=1799961group_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
