Re: [kvm-devel] kvm-ifup bug with complex default routes
* Dor Laor [EMAIL PROTECTED] [070402 00:43]:
A user just submitted a bug report against the kvm-18 debian package.
You can find the bug report at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=417151
The user has a default route with extra features and the kvm-ifup
script
fails for him, his default route looks like:
default via 10.0.0.138 dev br0 metric 1 realm 10
His suggestion to fix is:
-switch=$(/sbin/ip route list | awk '/^default / { print $NF }')
+switch=$(ip route ls | awk '/^default / { for(i=0;i$NF;i++) { if
($(i) ==
dev) print $(i+1) }}')
Actually using the default route in order to get the bridge name is a
bad thing. The best is to use brctl show and pick the bridge that has
the interface attached.
The current approach has its problems, especially if there is no bridge
defined. But what if I have multiple bridges? You will need to figure
out which one of them to use.
But then, this script can't take care of all situations, only of simple
and common ones, the fix suggested above just improves coverage for a
few more cases.
Baruch
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm-ifup bug with complex default routes
Baruch Even wrote:
* Dor Laor [EMAIL PROTECTED] [070402 00:43]:
A user just submitted a bug report against the kvm-18 debian package.
You can find the bug report at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=417151
The user has a default route with extra features and the kvm-ifup
script
fails for him, his default route looks like:
default via 10.0.0.138 dev br0 metric 1 realm 10
His suggestion to fix is:
-switch=$(/sbin/ip route list | awk '/^default / { print $NF }')
+switch=$(ip route ls | awk '/^default / { for(i=0;i$NF;i++) { if
($(i) ==
dev) print $(i+1) }}')
Actually using the default route in order to get the bridge name is a
bad thing. The best is to use brctl show and pick the bridge that has
the interface attached.
The current approach has its problems, especially if there is no bridge
defined. But what if I have multiple bridges? You will need to figure
out which one of them to use.
But then, this script can't take care of all situations, only of simple
and common ones, the fix suggested above just improves coverage for a
few more cases.
I think the correct solution is to set up the bridge where and when
networking is configured, using the regular configuration files and
supported by the regular tools. That's the only way we can deal with
all the various options. If there's only one bridge, qemu can use it;
if there's more, qemu-ifup should read some configuration file to select
the bridge.
Fedora has some support for bridging in initscripts: I have an ifcfg-sw0
with TYPE=Bridge and ifcfg-eth0 with BRIDGE=sw0. Seems to work fine,
and no need to transfer addresses and routes and dhcp client daemons and
whatnot.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm-ifup bug with complex default routes
Baruch Even wrote:
* Dor Laor [EMAIL PROTECTED] [070402 00:43]:
A user just submitted a bug report against the kvm-18 debian
package.
You can find the bug report at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=417151
The user has a default route with extra features and the kvm-ifup
script
fails for him, his default route looks like:
default via 10.0.0.138 dev br0 metric 1 realm 10
His suggestion to fix is:
-switch=$(/sbin/ip route list | awk '/^default / { print $NF }')
+switch=$(ip route ls | awk '/^default / { for(i=0;i$NF;i++) { if
($(i) ==
dev) print $(i+1) }}')
Actually using the default route in order to get the bridge name is
a
bad thing. The best is to use brctl show and pick the bridge that
has
the interface attached.
The current approach has its problems, especially if there is no
bridge
defined. But what if I have multiple bridges? You will need to figure
out which one of them to use.
But then, this script can't take care of all situations, only of
simple
and common ones, the fix suggested above just improves coverage for a
few more cases.
I think the correct solution is to set up the bridge where and when
networking is configured, using the regular configuration files and
supported by the regular tools. That's the only way we can deal with
all the various options. If there's only one bridge, qemu can use it;
if there's more, qemu-ifup should read some configuration file to
select
the bridge.
Fedora has some support for bridging in initscripts: I have an
ifcfg-sw0
with TYPE=Bridge and ifcfg-eth0 with BRIDGE=sw0. Seems to work fine,
and no need to transfer addresses and routes and dhcp client daemons
and
whatnot.
In general you're right. The only problem is that the ifcfg-XX scripts
do not work well while having bridge over bond interface.
If someone of our Redhat friends and also at debian will pick up the
glove
and fix it we will do the same.
Anyway I think qemu guys use such call to external script because there
are
plenty of distributions.
So first the script should use the existing bridge, then the standard
bridge
creation tools can be used.
--
Do not meddle in the internals of kernels, for they are subtle and
quick to
panic.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm-18 breaks Cisco VPN on WinXP SP1
Leslie Mann wrote: Avi Kivity [EMAIL PROTECTED] writes: The SIGIO means some I/O has occured, but what exactly, we don't know. Can you generate a core, attach it with gdb, and generate a backtrace? Check the backtrace for signs of your password and delete them if found. It shouldn't be there, but then it shouldn't crash either. Avi: I'm a little bit at a loss as to what to do to get a core backtrace. gcore gets me 3 frames with no symbol info and I don't see how that can help you. It's probably the aio thread. But wasn't there a segfault? That should get us a nice core. I have upgraded the Cisco VPN client from 4.6 to a newer version 4.8 and as well have tried using a kvm version from svn pulled today, still locking up. Lockup seems to happen around when the VPN client attempts to establish IKE session. FYI I am using vde_switch for networking. I did manage to get debugging info compiled with no optimization. The backtrace that follows is from attaching to running qemu process after UI lock up. Perhaps there are some clues here? If not, anything else I provide that would help? The backtrace is unhelpful. I guess we should bisect the kvm-17 - kvm-18 changes. This is a bit difficult as the userspace interface changes are in there, meaning that userspace and the kernel have to be updated in step. I'll prepare the first patch. Can you ensure that your upgraded setup still works kvm-17. -- error compiling committee.c: too many arguments to function - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] SVM: enable LBRV virtualization if available
On Mon, Apr 02, 2007 at 12:39:46PM +0300, Avi Kivity wrote: Joerg Roedel wrote: Is struct svm_cpu_data a userspace data structure. I ask because in a previous version of the patch the svm_features variable was part of that struct. Thats why I used this type. No, all userspace stuff is in include/linux/kvm*.h (which uses __u32; uint32_t is for libkvm and qemu). Ok, then the types in that structure should also be fixed :) Joerg -- Joerg Roedel Operating System Research Center AMD Saxony LLC Co. KG - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] SVM: enable LBRV virtualization if available
Joerg Roedel wrote: Is struct svm_cpu_data a userspace data structure. I ask because in a previous version of the patch the svm_features variable was part of that struct. Thats why I used this type. No, all userspace stuff is in include/linux/kvm*.h (which uses __u32; uint32_t is for libkvm and qemu). Ok, then the types in that structure should also be fixed :) Right, done :) -- error compiling committee.c: too many arguments to function - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] QEMU PIC indirection patch for in-kernel APIC work
Hi Dor,
Please find a patch attached for your review which adds support for dynamic
substitution of the PIC/APIC code to QEMU. This will allow us to selectively
chose the KVM in-kernel apic emulation vs the QEMU user-space apic emulation.
Support for both is key to allow --no-kvm type operation to continue working
even after the in-kernel code is deployed.
Note that this is only the part the allows indirection. The code that actually
fills in the slim apic in QEMU, as well as the kernel side changes applied to
git are not included here. Note also that this patch can stand alone. I have
confirmed that I can boot a guest with no discernible difference in
behavior/performance both before and after this patch. YMMV as my test cases
are limited.
Note that this patch only touches the KVM specific portions of QEMU (namely,
x86/i8259/apic support). If we decide that this should be pushed to QEMU
upstream, there is still work to be done to convert the other PIC
implementations (e.g. arm_pic, etc) to use the new interface.
I will continue to work on the kernel/slim-apic side while I await your
feedback. (BTW: Thanks for pointing me towards your branch...it has been most
helpful rather than starting from scratch. I already have most of the
kernel-side code ported already in a separate queue which I will share once I
get a baseline).
Thanks!
-Greg
Index: kvm/qemu/vl.h
===
--- kvm.orig/qemu/vl.h
+++ kvm/qemu/vl.h
@@ -1040,16 +1040,11 @@ ParallelState *parallel_init(int base, i
/* i8259.c */
-typedef struct PicState2 PicState2;
-extern PicState2 *isa_pic;
-void pic_set_irq(int irq, int level);
-void pic_set_irq_new(void *opaque, int irq, int level);
-PicState2 *pic_init(IRQRequestFunc *irq_request, void *irq_request_opaque);
-void pic_set_alt_irq_func(PicState2 *s, SetIRQFunc *alt_irq_func,
- void *alt_irq_opaque);
-int pic_read_irq(PicState2 *s);
-void pic_update_irq(PicState2 *s);
-uint32_t pic_intack_read(PicState2 *s);
+#include pic.h
+
+PIC *pic_init(IRQRequestFunc *irq_request, void *irq_request_opaque);
+void pic_set_alt_irq_func(PIC *pic, SetIRQFunc *alt_irq_func,
+ void *alt_irq_opaque);
void pic_info(void);
void irq_info(void);
@@ -1057,7 +1052,6 @@ void irq_info(void);
typedef struct IOAPICState IOAPICState;
int apic_init(CPUState *env);
-int apic_get_interrupt(CPUState *env);
IOAPICState *ioapic_init(void);
void ioapic_set_irq(void *opaque, int vector, int level);
Index: kvm/qemu/hw/i8259.c
===
--- kvm.orig/qemu/hw/i8259.c
+++ kvm/qemu/hw/i8259.c
@@ -29,6 +29,8 @@
//#define DEBUG_IRQ_LATENCY
//#define DEBUG_IRQ_COUNT
+typedef struct PicState2 PicState2;
+
typedef struct PicState {
uint8_t last_irr; /* edge detection */
uint8_t irr; /* interrupt request register */
@@ -58,6 +60,7 @@ struct PicState2 {
/* IOAPIC callback support */
SetIRQFunc *alt_irq_func;
void *alt_irq_opaque;
+PIC *base;
};
#if defined(DEBUG_PIC) || defined (DEBUG_IRQ_COUNT)
@@ -133,8 +136,9 @@ static int pic_get_irq(PicState *s)
/* raise irq to CPU if necessary. must be called every time the active
irq may change */
/* XXX: should not export it, but it is needed for an APIC kludge */
-void pic_update_irq(PicState2 *s)
+static void i8259_update_irq(PIC *pic)
{
+PicState2 *s = (PicState2*)pic-private;
int irq2, irq;
/* first look at slave pic */
@@ -174,9 +178,9 @@ void pic_update_irq(PicState2 *s)
int64_t irq_time[16];
#endif
-void pic_set_irq_new(void *opaque, int irq, int level)
+static void i8259_set_irq(PIC *pic, int irq, int level)
{
-PicState2 *s = opaque;
+PicState2 *s = (PicState2*)pic-private;
#if defined(DEBUG_PIC) || defined(DEBUG_IRQ_COUNT)
if (level != irq_level[irq]) {
@@ -199,13 +203,7 @@ void pic_set_irq_new(void *opaque, int i
/* used for IOAPIC irqs */
if (s-alt_irq_func)
s-alt_irq_func(s-alt_irq_opaque, irq, level);
-pic_update_irq(s);
-}
-
-/* obsolete function */
-void pic_set_irq(int irq, int level)
-{
-pic_set_irq_new(isa_pic, irq, level);
+pic_update_irq(pic);
}
/* acknowledge interrupt 'irq' */
@@ -231,8 +229,9 @@ static inline void pic_intack(PicState *
}
}
-int pic_read_irq(PicState2 *s)
+static int i8259_read_irq(PIC *pic)
{
+PicState2 *s = (PicState2*)pic-private;
int irq, irq2, intno;
irq = pic_get_irq(s-pics[0]);
@@ -256,7 +255,7 @@ int pic_read_irq(PicState2 *s)
irq = 7;
intno = s-pics[0].irq_base + irq;
}
-pic_update_irq(s);
+pic_update_irq(pic);
#ifdef DEBUG_IRQ_LATENCY
printf(IRQ%d latency=%0.3fus\n,
@@ -333,23 +332,23 @@ static void pic_ioport_write(void *opaqu
s-isr = ~(1 irq);
if (cmd == 5)
s-priority_add = (irq + 1) 7;
-
Re: [kvm-devel] kvm-18 breaks Cisco VPN on WinXP SP1
Avi Kivity [EMAIL PROTECTED] writes: It's probably the aio thread. But wasn't there a segfault? That should get us a nice core. No segfault. I don't believe that qemu has crashed, it just doesn't respond. Only ill effect after killing the process is that the mouse dies. The backtrace is unhelpful. I guess we should bisect the kvm-17 - kvm-18 changes. This is a bit difficult as the userspace interface changes are in there, meaning that userspace and the kernel have to be updated in step. I'll prepare the first patch. Can you ensure that your upgraded setup still works kvm-17. It does, as I use it daily in order to run a Win app that I need. Les - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
