Subject: Re: Mac-Address uniqueness - msg#00018

Previous Message by Date:

Re: Kernel panic when loading kvm-amd

On Friday 01 June 2007 07:55:32 you wrote: > Pär, > > Your CPU is AMD Athlon Rev G, which should support SVM. I happened to > have a Rev G CPU at hand. I will install Ubuntu 64 myself tomorrow and > see whether I can re-produce the problem. > > By any chance, could you can try the following tests? > > 1. Try other Linux distributions. > 2. Try Ubuntu 32Bit instead of 64Bit. My laptop has Turion x2, which > runs KVM 24 on Ubuntu 32bit without any problem. > > Thanks, > > -Wei Testing with other Linux distributions was already on my TODO list as I mentioned before. However this won't be necessary any more as I yesterday got KVM to work with my normal kernel. :-) I went through my BIOS settings and found: "Advanced BIOS Features" -> "CPU Feature" -> Virtualization However this was already set to "Enabled". I tried changing the value to "Disabled" and now KVM works fine. Stupid ABIT... If you try to change KVM to detect BIOS disabled SVM (or Enabled, in ABITs case...) instead of panicing I will be glad to help test that. regards Pär Andersson ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/

Next Message by Date:

Re: [PATCH 6/9] KVM: Adds support for real NMIinjection onVMX processors

>>> On Fri, Jun 1, 2007 at 12:29 AM, in message <B30DA1341B0CFA4893EF8A36B40B5C5D0134E12F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, "Li, Xin B" <xin.b.li@xxxxxxxxx> wrote: >> > I don't think this patch is complete to add NMIP support to KVM >> >>Could you be more specific on whats left to be done? From >>what I could read in the doc, this seemed complete. >> > > This is a good start, and we also need to add a vmexit handler to handle > exit reason 8, NMI pending. Ah, yes. Thank you for finding that. > And the major issue, I think, is how guest uses NMI, although from > virtualization view, we should not think from that, but we need make > sure all possible guest NMI usage model works well. Note that the guest can (and does) use NMI today independent of this patch and it works fine. In fact, some version of linux do this on a regular basis (they map LINT0 to NMI). This patch only affects whether NMIs are injected using the standard event-injection (INTR_TYPE_EXT_INTR) technique on vector 2, or using the VNMI facility (INTR_TYPE_NMI) instead. My impression is that the guest dispatches the IRQ-2 to the IDT in the same way in either case. The only difference is that VNMI method allows the event to be injected even if RFLAGS.IF is masking normal interrupts, thus more closely modeling the real world counterpart. So that being said, if you think there is a problem with injecting NMIs to guests in general then we have a bigger problem. This patch really only affects *how* they are delivered, not *if* they are delivered. The counterpoint to all this is that I have been testing with plenty of guests that take NMIs and they seem to be working normally. Please advise if you think there is a bigger problem we need to address. Regards -Greg ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/

Previous Message by Thread:

Re: Mac-Address uniqueness

Avi Kivity wrote: > H. Peter Anvin wrote: >> Axel Kittenberger wrote: >> >>> Unfortunally all machines detect the same ethernet address >>> '52:54:00:12:34:56'. Which you can guess what i means, networking comes >>> and goes whatever machine last the ethernet address got hold of from the >>> gateway. I tried specifing an ethernet-adress with "-net >>> nic,macaddr=$MAC" but this also didn't work through. >>> >>> For now I just hardseted the mac in all machines to 52:54:00:12:34:57, >>> 52:54:00:12:34:58 and so on. >>> >>> >> This is a Qemuism. I always thought it was dumb, but I guess Qemu >> wanted reproducibility over everything. >> >> IMNSHO it would have been much better to default to a random value >> (meaning that all except the bottom 2 bits of the first octet are >> random, those bits should be set to 10 binary.) >> >> > > That tends to consume dhcp leases quickly, if you start guests often (as > I do). Also, some distributions use the mac address as a key for naming > interfaces; if it changes, the guest gets confused > The right solution to that, of course, is a VM definitions file, so the random Ethernet address is only generated once. For Qemu/KVM, that could at least in theory simply be a shell script. -hpa ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/

Next Message by Thread:

Re: Mac-Address uniqueness

> That tends to consume dhcp leases quickly, if you start guests often (as > I do). Also, some distributions use the mac address as a key for naming > interfaces; if it changes, the guest gets confused > Couldn't we do some sort of hash on the image path+filename? So same image starts always with same MAC, different images -> different mac adresses. I guess I am supposed to post this suggestion on the qemu mailinglist. ;-) - Axel PS: Other topic, I still wonder how a guest can bevahe totally different on networking (unable to use network) when macaddr is set by kvm parameters? For me this sounds like a bug, not? ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/