Re: [kvm-devel] [PATCH 2/3] KVM: fix apic timer save/migration when inactive

[Avi Kivity]

He, Qing wrote:
>
 +if (atomic_read(&apic->timer.active))

 
>>> Or here?
>>>
>>>   
 +hrtimer_start(timer, timer->expires,
 +  HRTIMER_MODE_ABS);
  }
  EXPORT_SYMBOL_GPL(kvm_migrate_apic_timer);


 
>> I think you could use the return value of hrtimer_cancel() here:
>>
>>if (hrtimer_cancel(...))
>>hrtimer_start(...);
>> 
>
> Thanks for commenting, previously I have thought of something like:
>   if (hrtimer_active(...)) {
>   hrtimer_cancel(...);
>   hrtimer_start(...);
>   }
>
> But it is not able to handle pending state this way. Seems the return value 
> of hrtimer_cancel is fine. Another question is, when the hrtimer function 
> returns HRTIMER_NORESTART, does the state finally turn to 
> HRTIMER_STATE_INACTIVE?
>   

>From my reading of the hrtimer code, yes. But I would view any code
which depends on the state with suspicion.


-- 
error compiling committee.c: too many arguments to function


-
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] Intel-only or AMD Opteron as well?

[Avi Kivity]

Fernando Cassia wrote:
>
>
> Point #1:
>
> I just wish someone had thought more about the name before selecting 
> "KVM" ... because Sun has been using KVM (the K Virtual Machine) for 
> its Java VM for embedded devices for some time. This just causes 
> confusion on web searches...
>
> The K Virtual Machine (KVM)
> http://java.sun.com/products/cldc/wp/
>
> In any case... choosing somthing like "Kernel-VM" instead of the KVM 
> moniker would have been less confusing. But hey... no big deal... but 
> still if you ever decide to change the name...
>

Hey, don't rub it in.  In any case the name can't be changed now, we 
have to live with it.

>
> Point #3: Xen vs KVM... I'm confused
>
> The above move by RedHat is a bit confusing... what can Xen do that 
> KVM cannot?. In other words, why should anyone even bother with Xen 
> with KVM around ??.  I've read Xen is "more robust" because it has a 
> "one year lead" over KVM. But really, how does this translate, if 
> performance of Xen could be worse due to more paravirtualization?.  Or 
> is Xen more optimized to provide the "greatest possible consolidation" 
> on servers (ie less resource usage, less impact on cpu usage of a high 
> number of VMs?).

kvm is too new to have been included in RHEL 5.  The enterprise distros 
have a long lead time where the technology is tested and fixed, they 
don't pick the latest kernel off kernel.org and ship it the next day.  I 
think RHEL 5 is based on 2.6.18, whereas kvm was first merged in 2.6.20 
and gained guest smp support in 2.6.23.

Xen can also run virtual machines on older processors, but this is 
changing with kvm-lite.

-- 
error compiling committee.c: too many arguments to function


-
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] [Qemu-devel] Re: expose host CPU features to guests

[Avi Kivity]

Jamie Lokier wrote:
> Anthony Liguori wrote:
>   
>> I like this idea but I have some suggestions about the general approach.
>> I think instead of defining another machine type, it would be better to
>> just have a command line option like -cpuid that took a comma separate
>> string of features with "all" meaning all features that the host has.
>> 
>
> I like the idea of a flag to enable specific features, but I think
> "host" would be a better name for the features of the host.
>
> "all" seems more appropriate to enable all the features the emulator
> can support, which can include features which the host does not
> support itself.
>
> If it's a comma separated list, it would be good to be able to write
> something like this example, which selects all the host features but
> then overrides it by disabling the psn feature:
>
>-cpuid host,-psn
>   

Yes, 'host' and 'all' make more sense the way you describe them from the 
emulator perspective.

> Is it intended that these flags will also control the actual features
> which Qemu allows or emulates, or only what cpuid reports to the guest?
>
>   

The cpuid features are sufficient (and there's precedent -- some mobile 
intel processors support pae but don't report it).

>> I also think it would be nicer to use cpuid() directly instead of
>> attempting to parse /proc/cpuinfo.
>> 
>
> Occasionally the features in /proc/cpuinfo differ from what the cpuid
> instruction reports.  They are CPU bug workarounds (features disabled
> intentionally even though cpuid reports them), CPU features which
> aren't properly reported (enabled intentionally in cpuinfo), and boot
> flag requests (features disabled due to request from the boot command
> line).
>
> I'm inclined to think the feature list in /proc/cpuinfo is more
> appropriate, for choosing the best set of host features to make
> available to guests.  It's unlikely that Qemu itself will duplicate
> the logic of known workarounds for specific, obscure, buggy host CPUs.
>
> There is also /dev/cpu/%d/cpuinfo (for %d = 0, 1, etc.) on some Linux
> distros, I think.
>   

Well, the guest will invoke its own workaround logic to disable buggy 
features, so I see no issue here.

-- 
error compiling committee.c: too many arguments to function


-
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] [RFC][PATCH 0/7] guest SMP with in-kernel APIC

[Avi Kivity]

He, Qing wrote:
> Avi,
>   During the rebase to lapic6, I saw two patches missing in this branch. 
> Please see the attachments.
>
>   For the p1 patch, it was Sheng's patch to fix x86_64 windows booting. I 
> believe the commit 948a4b9e4b in kernel side (disable tpr/cr8 sync when 
> in-kernel APIC is used) also addresses this issue, but from code point of 
> view, this user mode patch is just OK, I see no reason to remove it. (btw., 
> my original update on the patch is unnecessary, you can just drop that 
> update).
>
>   For the p2 patch, it was applied by you, and it's necessary for kernel 
> apic SMP. Please reapply it to lapic6, and it can be folded and merged with 
> kvm-userspace commit 314694c464 (conditionally bypass user level init/sipi 
> handling).
>
>   There is also a regression on SMP introduced by hrtimer migration. We 
> are currently working on it and will send it out later as separate patch set.
>
>   

Applied both, thanks.


-- 
error compiling committee.c: too many arguments to function


-
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] AsteriskNOWbeta6 kernel panic at boot

[Avi Kivity]

Marco Menardi wrote:
> * cpu model: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+.
> * kvm version: 36-0.1 from Debian64 Sid
> * host kernel version: 2.6.22-1-amd64
> * host kernel arch: x86_64
> * guest: AsteriskNOW_beta6.5, Linux 32bit,  kernel version
> * command line:
>   kvm -boot d -cdrom asterisk_11599_asterisk-0.9.6.5-x86-disc1.iso -m 
> 1024 -no-acpi
> * with the -no-kvm switch it runs just fine
>
> Call Trace:
>   [] setup_apic_nmi_watchdog+0x51/0xb2
>   [] setup_local_APIC+0x21a/0x224
>   [] init+0x0/0x147
>   [] init+0x0/0x147
>   [] init+0x0/0x147
>   [] APIC_init_uniprocessor+0x9c/0xca
>   [] init+0x32/0x147
>   [] kernel_thread_helper+0x7/0x10
>   

Try adding 'nmi_watchdog=0' to the guest kernel command line (when it is 
running isolinux).

-- 
error compiling committee.c: too many arguments to function


-
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] Using VMChannel to communicate with the host.

[Dor Laor]

Troy Benjegerdes wrote:
> On Fri, Sep 07, 2007 at 04:44:30PM -0600, Cam Macdonell wrote:
>   
>> Hi,
>>
>> I'm trying to get a better understanding of VM-to-host communication 
>> that doesn't involve going over virtual networks.  I understand there 
>> are a couple of developments underway, but I just want to play around a 
>> better sense of things.   I think the current hypercall mechanism is the 
>> current way to do this using the -vmchannel option.  But, I'm not very 
>> experienced with PCI devices and their drivers so I need some help.  All 
>> I want to do is to communicate across a unix domain socket on the host. 
>>   Besides loading the hypercall module in the guest how do things needs 
>> to be configured on the host?
>>
>> Is there a simple tutorial or just a webpage with examples for how to do 
>> this?
>> 
>
> I'm going to suggest that a better way to do VM-to-host or VM-to-VM
> communication would be to write an OpenFabrics (www.openfabrics.org)
> driver that uses hypercalls. There is probably some gotcha I am not
> aware of, but I think this would allow direct userspace to userspace
> communication between a process running on a host, and a process running
> on a VM, while still maintaining isolation.
>
>   
Basically that's true but you need a host glue dirver to connect the two 
+ the hypercall implementation.
It can be easily added to KVM with a small cost.

BTW: does all windows guest will have the guest side driver implemented? 
Including XP, 2k, Vista?

-
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] Intel-only or AMD Opteron as well?

[Farkas Levente]

On Vas, Szeptember 9, 2007 09:48, Avi Kivity wrote:
> kvm is too new to have been included in RHEL 5.  The enterprise distros
> have a long lead time where the technology is tested and fixed, they
> don't pick the latest kernel off kernel.org and ship it the next day.  I
> think RHEL 5 is based on 2.6.18, whereas kvm was first merged in 2.6.20
> and gained guest smp support in 2.6.23.

does this means if i compile the latest kvm as a module for rhel5's 2.6.18
kernel it won't support guest smp? anyway the whole kernel and kvm
versioning and what is required for whicv version is not clear and should
have to be documented! it's a faq for all new kvm users!

> Xen can also run virtual machines on older processors, but this is
> changing with kvm-lite.

is there any info about kvm-lite? is there any docs where can i donwload
and test etc?

-- 


-
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] Intel-only or AMD Opteron as well?

[Izik Eidus]

Farkas Levente wrote:
> On Vas, Szeptember 9, 2007 09:48, Avi Kivity wrote:
>   
>> kvm is too new to have been included in RHEL 5.  The enterprise distros
>> have a long lead time where the technology is tested and fixed, they
>> don't pick the latest kernel off kernel.org and ship it the next day.  I
>> think RHEL 5 is based on 2.6.18, whereas kvm was first merged in 2.6.20
>> and gained guest smp support in 2.6.23.
>> 
>
> does this means if i compile the latest kvm as a module for rhel5's 2.6.18
> kernel it won't support guest smp? anyway the whole kernel and kvm
> versioning and what is required for whicv version is not clear and should
> have to be documented! it's a faq for all new kvm users!
>
>   
no, if you will compile the latest kvm as module to 2.6.18 you will have 
smp support.
(it might be slower than in 2.6.23)
>> Xen can also run virtual machines on older processors, but this is
>> changing with kvm-lite.
>> 
>
> is there any info about kvm-lite? is there any docs where can i donwload
> and test etc?
>
>   


-
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] Intel-only or AMD Opteron as well?

[Fernando Cassia]

On 9/9/07, Avi Kivity <[EMAIL PROTECTED]> wrote:

> Hey, don't rub it in.  In any case the name can't be changed now, we
> have to live with it.


I just hope this is not one of those "we're not changing it, let THEM change
it!" kind of arguments. :)

Software names change all the time... remember before Firefox how it was
initially called "Firebird" ?
And SeaMonkey, the new browser-email suite formerly known as "Mozilla" ?
...or "Windows Mail" the product formerly known as "Outlook Express"?
..and  Adobe Reader, the product formerly known as "Acrobat Reader"...

After all, you don't have to RADICALLY change the name... in fact I think
"Kernel VM" or Kernel-VM not only avoids this confusion, but also describes
the product better.

I should also note that for the end users, "KVM" reminds them of
Keyboard-Video-Mouse switches
if you do a Google web search now (English language) you get "KVM Switch"
first, and "KVM" (this project) as the second hit.
BUT if you repeat the google search in another language (case in point:
Spanish), the results are completely different and while this KVM project is
also the second result, the rest of the results in the first page are KVM
switches...
http://www.google.com.ar/search?hl=es&q=kvm&btnG=Buscar&meta=

In any case... I'm not trying to force any change... just thinking aloud.
Take this as food for thought. :)

And thanks for the rest of your replies, which were really enlightening...

FC
-
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] Using VMChannel to communicate with the host.

[Dor Laor]

Cam Macdonell wrote:
> Hi,
>
> I'm trying to get a better understanding of VM-to-host communication 
> that doesn't involve going over virtual networks.  I understand there 
> are a couple of developments underway, but I just want to play around a 
> better sense of things.   I think the current hypercall mechanism is the 
> current way to do this using the -vmchannel option.  But, I'm not very 
> experienced with PCI devices and their drivers so I need some help.  All 
> I want to do is to communicate across a unix domain socket on the host. 
>   Besides loading the hypercall module in the guest how do things needs 
> to be configured on the host?
>
> Is there a simple tutorial or just a webpage with examples for how to do 
> this?
>
> Thanks,
> Cam
>   
I just tested it, it got a little deprecated over time since it call 
pci_module_init instead of pci_register_* and some more irq function 
deprecation.The sysfs interface in not complete and you can't read/write 
from the device.
The qemu parameters are -vmchannel di:2258,unix:/tmp/file,server
2258 is the vendor id for the device, you can use unix sockets ot even 
tcp for the host end.

In several week we'll publish better version of it. Maybe we'll publish 
a preview before.
-Dor

-
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] Intel-only or AMD Opteron as well?

[Farkas Levente]

Avi Kivity wrote:
> Fernando Cassia wrote:
>>
>> Point #1:
>>
>> I just wish someone had thought more about the name before selecting 
>> "KVM" ... because Sun has been using KVM (the K Virtual Machine) for 
>> its Java VM for embedded devices for some time. This just causes 
>> confusion on web searches...
>>
>> The K Virtual Machine (KVM)
>> http://java.sun.com/products/cldc/wp/
>>
>> In any case... choosing somthing like "Kernel-VM" instead of the KVM 
>> moniker would have been less confusing. But hey... no big deal... but 
>> still if you ever decide to change the name...
>>
> 
> Hey, don't rub it in.  In any case the name can't be changed now, we 
> have to live with it.

anyway it's true, that this name is one of the worst choice:-(

-- 
  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] (long) kvm and virt-manager not ready for daily usage

[Farkas Levente]

Anthony Liguori wrote:
>>> saying that guest SMP isn't working for you?  The host OS definitely
>>> shouldn't crash.  Can you be more specific about what configs you are
>>> using?  There was a host oops fixed in kvm-36 so upgrading may help you.
>> exactly. i've got 4 phisical core (Intel Core 2 Quad) and i try to give
>> 4 cpus for 2 guests and 2 cpus for a third guest and restart libvirtd.
>> the result was that even the host system crash without any stack trace
>> or kernel panic and only the hard reset helps.
> 
> Could you try to reproduce the problem with kvm-36?  Host crash bugs are
> very important to fix especially one so easily reproducible.

yes, when c5-testing will include kvm-36. i already recompile many rpms
to be able to use the latest tools, but since kvm is in centos-extras
i'd rather stay with that and don't mix packages.

-- 
  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

[kvm-devel] [ANNOUNCE] kvm-37 release

[Avi Kivity]

This release merges the pic/lapic/ioapic into mainline.  While some 
known issues exist, we're now at the point where it's better to get some 
wider exposure rather than keep it alone on a branch.

Some regressions are expected; please report them as they appear.  A new 
qmeu option -no-kvm-irqchip is available to disable the new functionality.

While many people are listed in the credits for this effort, I'd like to 
thank Eddie and Qing for persevering and doing the hard work of actually 
getting it in a form suitable for inclusion and fixing the bugs.  This 
release is mostly their work.

Changes since kvm-36:
- in-kernel lapic, ioapic, and pic (Eddie Dong, Qing He, Sheng Yang, 
Gregory Haskins, Dor Laor, me)
- split segment reload (vmx microoptimization) (Laurent Vivier)
- fix vga redraw regression (Izik Eidus)
- fix testsuite compilation with older assemblers (H. Peter Anvin)

Notes:
If you use the modules bundled with kvm-37, you can use any version
of Linux from 2.6.9 upwards.
If you use the modules bundled with Linux 2.6.20, you need to use
kvm-12.
If you use the modules bundled with Linux 2.6.21, you need to use
kvm-17.
Modules from Linux 2.6.22 and up will work with any kvm version from
kvm-22.  Some features may only be available in newer releases.
For best performance, use Linux 2.6.23-rc2 or later as the host.

http://kvm.qumranet.com



-
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/5] Clean up unloved invlpg: remove kvm_arch_ops.invlpg and tweak emulator.

[Avi Kivity]

Rusty Russell wrote:
> On Wed, 2007-09-05 at 18:30 +0300, Avi Kivity wrote:
>   
>> Rusty Russell wrote:
>> 
>>> invlpg shouldn't fetch the "src" address, since it may not be valid,
>>> however SVM's "solution" which neuters emulation of all group 7
>>> instruction is horrible and breaks kvm-lite.  The simplest fix is to
>>> put a special check in for invlpg.
>>>
>>> Also, remove the unused invlpg member of struct kvm_arch_ops.
>>>
>>>   
>>>   
>> One change, one patch.
>> 
>
>
>   

Applied both halves, thanks.

-- 
error compiling committee.c: too many arguments to function


-
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/5] Hoist SVM's get_cs_db_l_bits into core code.

[Avi Kivity]

Rusty Russell wrote:
> SVM gets the DB and L bits for the cs by decoding the segment.  This
> is in fact the completely generic code, so hoist it for kvm-lite to use.
>
>   

Applied this and the cr0/cr4 sync.  Thanks.

-- 
error compiling committee.c: too many arguments to function


-
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/3] Make to round memory to next page

[Avi Kivity]

Anthony Liguori wrote:
> In general, the BIOS, VGA BIOS, and option ROMs are not required to be 
> multiple
> of page sizes.  This means that phys_ram_size may not be a multiple of page.
> Address this at the kvm_create() level to make things simplier for future
> callers.
>
>   

Applied all three, thanks.

-- 
error compiling committee.c: too many arguments to function


-
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] kvm-36 breaks Solaris 10 VM

[Avi Kivity]

Simon Gao wrote:



>> There's a fix for solaris crashes in the git tree, commit ID 3959211b. It'll 
>> be available in kvm-37. If this doesn't fix things for you, let us know your 
>> host CPU type.
>>
>> Amit
>>   
>> 
> thanks, I will try kvm-37 out once it's released.
>
>   

Due to maintainer error this will only be available in kvm-38.

-- 
error compiling committee.c: too many arguments to function


-
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]Try to make some code simplications allowed by the mutex use

[Avi Kivity]

Laurent Vivier wrote:
> Try to make some code simplifications allowed by the use of a mutex instead 
> of a
> spinlock. As we can keep the lock longer, we don't have to release it and then
> have to check if the environment has not been modified before re-taking it. We
> can remove kvm->busy and kvm->memory_config_version.
>
>   

Applied, thanks.

-- 
error compiling committee.c: too many arguments to function


-
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] kvm-36 losing (tap-based) network connectivitymid-session

[Avi Kivity]

Charles Duffy wrote:
> Dor Laor wrote:
>   
>> Can you try it without rtc (either use -no-rtc, I'm not sure we have
>> this flag or just rm /dev/rtc before you run the vm).
>> 
>
> Tried it (and -tdf) without effect.
>
>   
>> What's your host HZ configuration?
>> 
>
> CONFIG_HZ=250
>
>   
>

Can you check with the other emulated nic? (-nic model=...)


-- 
error compiling committee.c: too many arguments to function


-
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/5] Split the emulator: decode & execute

[Avi Kivity]

Laurent Vivier wrote:
> These patches split the emulator in two parts: one to decode the instruction,
> the other to execute it. The decode part is then called only when needed.
>
>   

Patchset looks good, but fails booting FC6 x86-64 on Intel.  It may be a 
merge error (did not apply cleanly due to other changes).  I pushed this 
as a 'split-emulator' branch on the kvm.git repository.

-- 
error compiling committee.c: too many arguments to function


-
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] Boot install CD of Vista 32 Premium Hangs Host

[Haydn Solomon]

This is to report bug where host hangs on boot of vista 32 premium install
CD. After the "loading files" status bar gets to 100% the host pc hangs. I'm
using the following startup parameters.

/usr/local/kvm/bin/qemu-system-x86_64 \
-hda vistahome.img \
-m 400 \
-no-rtc \
-localtime \
-boot d \
-no-reboot \
-cdrom /home/hsolomon/isos/VISTA_32_PREMIUM.iso &


I'm usinig an Intel core 2 duo running on Fedora 7 x86_64. Below is output
/proc/cpuinfo

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Core(TM)2 Duo CPU T7500  @ 2.20GHz
stepping: 10
cpu MHz : 800.000
cache size  : 4096 KB
physical id : 0
siblings: 2
core id : 1
cpu cores   : 2
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm
constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
bogomips: 4387.72
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:


Thanks.

Haydn
-
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] Boot install CD of Vista 32 Premium Hangs Host

[Haydn Solomon]

Forgot to mention that this is on kvm-37

On 9/9/07, Haydn Solomon <[EMAIL PROTECTED]> wrote:
>
> This is to report bug where host hangs on boot of vista 32 premium install
> CD. After the "loading files" status bar gets to 100% the host pc hangs. I'm
> using the following startup parameters.
>
> /usr/local/kvm/bin/qemu-system-x86_64 \
> -hda vistahome.img \
> -m 400 \
> -no-rtc \
> -localtime \
> -boot d \
> -no-reboot \
> -cdrom /home/hsolomon/isos/VISTA_32_PREMIUM.iso &
>
>
> I'm usinig an Intel core 2 duo running on Fedora 7 x86_64. Below is output
> /proc/cpuinfo
>
> processor   : 1
> vendor_id   : GenuineIntel
> cpu family  : 6
> model   : 15
> model name  : Intel(R) Core(TM)2 Duo CPU T7500  @ 2.20GHz
> stepping: 10
> cpu MHz : 800.000
> cache size  : 4096 KB
> physical id : 0
> siblings: 2
> core id : 1
> cpu cores   : 2
> fpu : yes
> fpu_exception   : yes
> cpuid level : 10
> wp  : yes
> flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm
> constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
> bogomips: 4387.72
> clflush size: 64
> cache_alignment : 64
> address sizes   : 36 bits physical, 48 bits virtual
> power management:
>
>
> Thanks.
>
> Haydn
>
-
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] Boot install CD of Vista 32 Premium Hangs Host

[Avi Kivity]

Haydn Solomon wrote:
> This is to report bug where host hangs on boot of vista 32 premium 
> install CD. After the "loading files" status bar gets to 100% the host 
> pc hangs. I'm using the following startup parameters.
>

This is known; I will commit a fix in a few minutes...

-- 
error compiling committee.c: too many arguments to function


-
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/3] KVM paravirtualization framework (v2)

[Avi Kivity]

Anthony Liguori wrote:
> This patchset refactors KVM's paravirtualization support to better support
> guest SMP and cross platform migration.  It also introduces a bare-bones KVM
> paravirt_ops implementation.
>
> I've tested this on VT and it works nicely.  I'm having trouble getting a
> bzImage to boot on SVM so I haven't been able to test on SVM yet.
>
> I've incorporated all of the feedback into this series from posting the
> last series.
>   

Can you send this patchset out again?  There were some updated patches 
posted and I'm not sure I can find the most recent ones.


-- 
error compiling committee.c: too many arguments to function


-
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] [BUG] kvm_lock: inconsistent lock state

[Avi Kivity]

Luca Tettamanti wrote:
> Hi,
> I just got this warning when doing a 'rmmod kvm-intel':
>
> =
> [ INFO: inconsistent lock state ]
> 2.6.23-rc3-libata-g28e8351a-dirty #93
> -
> inconsistent {hardirq-on-W} -> {in-hardirq-W} usage.
> udevd/2800 [HC1[1]:SC0[0]:HE0:SE1] takes:
>  (kvm_lock){+-..}, at: [] hardware_disable+0x31/0xbc [kvm]
> {hardirq-on-W} state was registered at:
>   [] __lock_acquire+0x487/0xbcc
>   [] debug_check_no_locks_freed+0x110/0x11a
>   [] __next_cpu+0x12/0x21
>   [] is_module_address+0x35/0x92
>   [] lock_acquire+0x68/0x80
>   [] kvm_dev_ioctl+0xb5/0x1c8 [kvm]
>   [] _spin_lock+0x36/0x5f
>   [] kvm_dev_ioctl+0xb5/0x1c8 [kvm]
>   [] kvm_dev_ioctl+0xb5/0x1c8 [kvm]
>   [] do_page_fault+0x30d/0x734
>   [] kvm_dev_ioctl+0x0/0x1c8 [kvm]
>   [] do_ioctl+0x1f/0x62
>   [] vfs_ioctl+0x237/0x249
>   [] trace_hardirqs_on+0x11a/0x13d
>   [] sys_ioctl+0x33/0x4d
>   [] syscall_call+0x7/0xb
>   [] 0x
> irq event stamp: 682504
> hardirqs last  enabled at (682503): [] 
> get_page_from_freelist+0x18c/0x35c
> hardirqs last disabled at (682504): [] 
> call_function_interrupt+0x29/0x38
> softirqs last  enabled at (679024): [] do_softirq+0x61/0xd1
> softirqs last disabled at (679017): [] do_softirq+0x61/0xd1
>
> other info that might help us debug this:
> 1 lock held by udevd/2800:
>  #0:  (&inode->i_mutex){--..}, at: [] shmem_file_write+0x7e/0x2a6
>
> stack backtrace:
>  [] print_usage_bug+0x138/0x142
>  [] mark_lock+0xae/0x44a
>  [] _spin_unlock+0x25/0x3b
>  [] __lock_acquire+0x416/0xbcc
>  [] lock_acquire+0x68/0x80
>  [] hardware_disable+0x31/0xbc [kvm]
>  [] _spin_lock+0x36/0x5f
>  [] hardware_disable+0x31/0xbc [kvm]
>  [] hardware_disable+0x0/0xbc [kvm]
>  [] hardware_disable+0x31/0xbc [kvm]
>  [] lock_release_holdtime+0x3d/0x4a
>  [] hardware_disable+0x0/0xbc [kvm]
>  [] smp_call_function_interrupt+0x37/0x52
>  [] call_function_interrupt+0x33/0x38
>  [] p4_rearm+0x4/0xf2c
>  [] get_page_from_freelist+0x295/0x35c
>  [] __alloc_pages+0x5f/0x295
>  [] put_lock_stats+0xa/0x1e
>  [] shmem_getpage+0x38c/0x59a
>  [] __mutex_lock_slowpath+0x290/0x298
>  [] shmem_file_write+0x12b/0x2a6
>  [] shmem_file_write+0x0/0x2a6
>  [] vfs_write+0x8a/0x10c
>  [] sys_write+0x41/0x67
>  [] syscall_call+0x7/0xb
>  ===
>
> (this is kvm-36, but the bug was there in previous versions too)
>
> kvm_lock is taken in kvm_create_vm with interrupts enabled. Later - at
> rmmod time - it's used in decache_vcpus_on_cpu (hardware_disable) with
> interrupts disabled (due to on_each_cpu). In theory it should be
> harmless since the refcount on /dev/kvm prevents the deadlock.
> Switching to irq-safe spin_lock_* seems fine, do you want a patch?
>
>   

Maybe hoisting the lock out of decache_vcpus_on_cpus() onto the callers 
of hardware_disable() will be better.  We can have a 
__hardware_disable() which does not take the lock (for use in 
on_each_cpu or smp_call_function_single) and a hardware_disable() which 
does take the lock.

But there may be better alternatives.

-- 
error compiling committee.c: too many arguments to function


-
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/5] Architecture independence layer - v1 - x86 renaming

[Avi Kivity]

Christian Ehrhardt wrote:
> from Christian Ehrhardt
>
> This patch just renames the current _arch namings to _x86 to ensure 
> better readability when a real arch layer takes place
>
>   


Applied (well, I did the same sed as you).

-- 
error compiling committee.c: too many arguments to function


-
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] [Qemu-devel] Re: expose host CPU features to guests

[Jamie Lokier]

Avi Kivity wrote:
> Well, the guest will invoke its own workaround logic to disable buggy 
> features, so I see no issue here.

The guest can only do this if it has exactly the correct id
information for the host processor (e.g. "This is an Intel Pentium Pro
model XXX"), not just the list of safe to use CPU features.

This isn't possible in a virtualisation cluster of many different CPUs
where the point is to advertise the common set of cpuid features, and
for the guest images to be able to migrate between different CPUs in
the cluster.

Then, the common cpuid features must be found by combining the
/proc/cpuinfo from each node in the cluster.  But I guess that's
separate from the part of Qemu we are discussing; it would be done by
another program, preparing the -cpuid argument.

But sometimes it's good to run a simple guest (e.g. someone's pet OS
project, or anything written for Intel only which was more common in
the past) which doesn't have all the detailed obscure workarounds of
something like Linux, but still be able to take advantage of the
workarounds and obscure knowledge in the host.

The alternative is Qemu itself may end up having to have some of these
obscure workarounds :/

For example, the sysenter instruction is advertised on early Pentium
Pros, but it doesn't work.  Linux removes it from the features in
/proc/cpuinfo, and doesn't use it.  But some guests simply don't get
that obscure, and use it if cpuid advertises it.  Of course, they
don't work on a _real_ early Pentium Pro.  But it would be nice if
they did work without anything special when run in Qemu on such a
host.  That's an old chip which I happen to know about, but I'm sure
there are more modern similar issues.

Perhaps there could be two options then: "-cpuid host-os", and "-cpuid
host-cpuid".  I would suggest making "host" an alias for "host-os",
but I wouldn't object if it were an alias for "host-cpuid" or didn't
exist at all, so you had to choose one.

-- Jamie

-
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-1791032 ] no-kvm segfaults

[SourceForge.net]

Bugs item #1791032, was opened at 2007-09-09 15:48
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=1791032&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: Technologov (technologov)
Assigned to: Nobody/Anonymous (nobody)
Summary: no-kvm segfaults

Initial Comment:
KVM's -no-kvm segfaults.

Host: Fedora7, 64-bit, Intel Core 2 CPU.

-Technologov

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1791032&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] [BUG][PATCH?] kvm: unhandled wrmsr: 0xc0000083

[Avi Kivity]

Luca Tettamanti wrote:
>> Actually 0xfff2 is in the middle of an instruction.
>>
>> I'm guessing an 'out' instruction triggered the reboot, and 
>> skip_emulated_instruction() added 2 to rip.
>> 
>
> I think you're right; the reset is triggered by an outb to 0x64.
>
> Now, with this patch:
>
> diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
> index 491c32c..722d838 100644
> --- a/qemu/qemu-kvm.c
> +++ b/qemu/qemu-kvm.c
> @@ -706,8 +706,12 @@ static void update_regs_for_sipi(CPUState *env)
>  
>  static void update_regs_for_init(CPUState *env)
>  {
> -cpu_reset(env);
> -load_regs(env);
> +if (env->cpu_index) {
> +cpu_reset(env);
> +load_regs(env);
> +} else {
> + vcpu_info[env->cpu_index].init = 0;
> +}
>  }
>   

Can you explain this patch?  Why is the boot cpu treated differently?

I think the only difference should be the halted flag.

>  
>  static void setup_kernel_sigmask(CPUState *env)
>
> I can reboot using the BIOS (reboot=b) without the outb. I fail to see
> why an extra reset causes the vm entry failure though.
>
> Default reboot path (i.e. the outb) still fails:
>
> exception 13 (0)
> rax  rbx  rcx  rdx 
> 0700
> rsi  rdi  rsp  rbp 
> 
> r8   r9   r10  r11 
> 
> r12  r13  r14  r15 
> 
> rip  rflags 00033046
> cs f000 (000f/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
> ds  (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
> es  (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
> ss  (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
> fs  (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
> gs  (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
> tr 0080 (1085/2088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0)
> ldt  (/ p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0)
> gdt 0/
> idt 0/
> cr0 6010 cr2 0 cr3 0 cr4 0 cr8 0 efer 0
> code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 --> 00 00 
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> 00 00
>
> the #GP makes more sense than the vm entry failure if the the emulator
> is jumping to fff2.
>   

Right.  Maybe the processor dropped out of vm86 mode and we're getting 
#gp on ds.


-- 
error compiling committee.c: too many arguments to function


-
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] [Qemu-devel] Re: expose host CPU features to guests

[Avi Kivity]

Jamie Lokier wrote:
> Avi Kivity wrote:
>   
>> Well, the guest will invoke its own workaround logic to disable buggy 
>> features, so I see no issue here.
>> 
>
> The guest can only do this if it has exactly the correct id
> information for the host processor (e.g. "This is an Intel Pentium Pro
> model XXX"), not just the list of safe to use CPU features.
>
> This isn't possible in a virtualisation cluster of many different CPUs
> where the point is to advertise the common set of cpuid features, and
> for the guest images to be able to migrate between different CPUs in
> the cluster.
>   

Well, for a cluster the management software will coordinate all cpuid 
features, perhaps taking into account features removed by the host 
kernel. "-cpu host" is for the gentoo user who wants to enable all the 
nice cpu flags.

> Then, the common cpuid features must be found by combining the
> /proc/cpuinfo from each node in the cluster.  But I guess that's
> separate from the part of Qemu we are discussing; it would be done by
> another program, preparing the -cpuid argument.
>   

Exactly.

> But sometimes it's good to run a simple guest (e.g. someone's pet OS
> project, or anything written for Intel only which was more common in
> the past) which doesn't have all the detailed obscure workarounds of
> something like Linux, but still be able to take advantage of the
> workarounds and obscure knowledge in the host.
>
> The alternative is Qemu itself may end up having to have some of these
> obscure workarounds :/
>
> For example, the sysenter instruction is advertised on early Pentium
> Pros, but it doesn't work.  Linux removes it from the features in
> /proc/cpuinfo, and doesn't use it.  But some guests simply don't get
> that obscure, and use it if cpuid advertises it.  Of course, they
> don't work on a _real_ early Pentium Pro.  But it would be nice if
> they did work without anything special when run in Qemu on such a
> host.  That's an old chip which I happen to know about, but I'm sure
> there are more modern similar issues.
>
> Perhaps there could be two options then: "-cpuid host-os", and "-cpuid
> host-cpuid".  I would suggest making "host" an alias for "host-os",
> but I wouldn't object if it were an alias for "host-cpuid" or didn't
> exist at all, so you had to choose one.
>   

Let's start with '-cpu host' as 'cpu host-cpuid' and implement '-cpu 
host-os' on the first bug report?  I have a feeling we won't ever see it.


-- 
error compiling committee.c: too many arguments to function


-
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] [RFC][PATCH 5/6][KVM VIRTIO] Add the network device code

[Avi Kivity]

Luca wrote:
> On 8/29/07, Cam Macdonell <[EMAIL PROTECTED]> wrote:
>   
>> Dor Laor wrote:
>> 
>>> The code can now be accessed by git:
>>> git://kvm.qumranet.com/home/dor/src/virtio/kvm (kernel) and
>>> git://kvm.qumranet.com/home/dor/src/virtio/kvm-userspace.
>>> branch name virt-final.
>>> --Dor
>>>   
>> I'm really new to git and don't quite grasp it's subtleties.  Do I have
>> to "git clone" your kvm kernel and user-space repos or is there some way
>> to use your branch as a branch off Avi's?  I tried finding an online
>> reference, but none seem to cover this kind of setup.
>> 
>
> If Dor's repository is based on the Avi's one (I think so) you can
> pull virt-final branch as a branch of you existing repository (see
> refspec parameter in git-pull). This is error prone though (after a
> while I tend to pull the wrong tree into the wrong branch ;-) )
> I prefer to clone the whole tree (disk space is cheap...), sharing GIT
> object where possible, e.g.
>
> git clone --reference kvm.avi
> git://kvm.qumranet.com/home/dor/src/virtio/kvm kvm.dor
>
> where kvm.avi is you existing kvm git repository.
>   


My preference pulling random branches and repos is 'git fetch' (or, for 
longer lived branches, 'git remote') which doesn't cause fake merges.

-- 
error compiling committee.c: too many arguments to function


-
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] [RFC][PATCH 5/6][KVM VIRTIO] Add the network device code

[Avi Kivity]

Luca wrote:
> On 8/25/07, Dor Laor <[EMAIL PROTECTED]> wrote:
>
> I just noticed this:
>
>   
>> --- /dev/null
>> +++ b/qemu/hw/paravirt_net.c
>> @@ -0,0 +1,213 @@
>> +/*
>> + * QEMU para virtual network emulation
>> + *
>> + * Copyright (c) 2007 Qumranet
>> + *
>> + * Permission is hereby granted, free of charge, to any person
>> obtaining a copy
>> + * of this software and associated documentation files (the
>> "Software"), to deal
>> + * in the Software without restriction, including without limitation
>> the rights
>> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or
>> sell
>> + * copies of the Software, and to permit persons to whom the Software
>> is
>> + * furnished to do so, subject to the following conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be
>> included in
>> + * all copies or substantial portions of the Software.
>> 
> [cut]
>
> Shouldn't you use the standard GPL boilerplate? (IANAL, so maybe the
> text above is a superset of the GPL and is fine...)
>
>   

My preference is to just add a copyright and refer to some file in the 
top-level, so we don't restrict qemu's licensing unnecessarily (this 
could hinder merging).


-- 
error compiling committee.c: too many arguments to function


-
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] [Qemu-devel] Re: expose host CPU features to guests

[Jamie Lokier]

Avi Kivity wrote:
> Let's start with '-cpu host' as 'cpu host-cpuid' and implement '-cpu 
> host-os' on the first bug report?  I have a feeling we won't ever see it.

I have a feeling you won't ever see it either, but not because it's a
missing feature.

Instead, I think a very small number of users will spend hours
frustrated that some obscure guest doesn't work properly on their
obscure x86 hardware, then they will learn that they should not use
"-cpuid host" for that guest on that hardware, even though it works
fine with other guests, and then their problem will be solved (albeit
at a cost), and seen as such an obscure combination that it might
never be reported to Qemu developers.

In other words, host-os is what _I'd_ implement because I care too
much about the poor obscure users and think it's the safe option, but
I'm not doing the implementing here ;-)

If you are curious what the differences are, do this in a current
Linux source tree:

egrep -R '(set|clear)_bit\(X86_FEATURE' arch/{i386,x86_64}/kernel

-- Jamie

-
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 -rc] KVM: MMU: Fix rare oops on guest context switch

[Avi Kivity]

A guest context switch to an uncached cr3 can require allocation of
shadow pages, but we only recycle shadow pages in kvm_mmu_page_fault().

Move shadow page recycling to mmu_topup_memory_caches(), which is called
from both the page fault handler and from guest cr3 reload.

Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
---

 drivers/kvm/kvm.h |   10 +++---
 drivers/kvm/mmu.c |5 +++--
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 3ac9cbc..336be86 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -619,7 +619,7 @@ unsigned long segment_base(u16 selector);
 void kvm_mmu_pte_write(struct kvm_vcpu *vcpu, gpa_t gpa,
   const u8 *old, const u8 *new, int bytes);
 int kvm_mmu_unprotect_page_virt(struct kvm_vcpu *vcpu, gva_t gva);
-void kvm_mmu_free_some_pages(struct kvm_vcpu *vcpu);
+void __kvm_mmu_free_some_pages(struct kvm_vcpu *vcpu);
 int kvm_mmu_load(struct kvm_vcpu *vcpu);
 void kvm_mmu_unload(struct kvm_vcpu *vcpu);
 
@@ -628,11 +628,15 @@ int kvm_hypercall(struct kvm_vcpu *vcpu, struct kvm_run 
*run);
 static inline int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t gva,
 u32 error_code)
 {
-   if (unlikely(vcpu->kvm->n_free_mmu_pages < KVM_MIN_FREE_MMU_PAGES))
-   kvm_mmu_free_some_pages(vcpu);
return vcpu->mmu.page_fault(vcpu, gva, error_code);
 }
 
+static inline void kvm_mmu_free_some_pages(struct kvm_vcpu *vcpu)
+{
+   if (unlikely(vcpu->kvm->n_free_mmu_pages < KVM_MIN_FREE_MMU_PAGES))
+   __kvm_mmu_free_some_pages(vcpu);
+}
+
 static inline int kvm_mmu_reload(struct kvm_vcpu *vcpu)
 {
if (likely(vcpu->mmu.root_hpa != INVALID_PAGE))
diff --git a/drivers/kvm/mmu.c b/drivers/kvm/mmu.c
index 1a87ba9..23965aa 100644
--- a/drivers/kvm/mmu.c
+++ b/drivers/kvm/mmu.c
@@ -273,12 +273,14 @@ static int mmu_topup_memory_caches(struct kvm_vcpu *vcpu)
int r;
 
r = __mmu_topup_memory_caches(vcpu, GFP_NOWAIT);
+   kvm_mmu_free_some_pages(vcpu);
if (r < 0) {
spin_unlock(&vcpu->kvm->lock);
kvm_arch_ops->vcpu_put(vcpu);
r = __mmu_topup_memory_caches(vcpu, GFP_KERNEL);
kvm_arch_ops->vcpu_load(vcpu);
spin_lock(&vcpu->kvm->lock);
+   kvm_mmu_free_some_pages(vcpu);
}
return r;
 }
@@ -1208,7 +1210,7 @@ int kvm_mmu_unprotect_page_virt(struct kvm_vcpu *vcpu, 
gva_t gva)
return kvm_mmu_unprotect_page(vcpu, gpa >> PAGE_SHIFT);
 }
 
-void kvm_mmu_free_some_pages(struct kvm_vcpu *vcpu)
+void __kvm_mmu_free_some_pages(struct kvm_vcpu *vcpu)
 {
while (vcpu->kvm->n_free_mmu_pages < KVM_REFILL_PAGES) {
struct kvm_mmu_page *page;
@@ -1218,7 +1220,6 @@ void kvm_mmu_free_some_pages(struct kvm_vcpu *vcpu)
kvm_mmu_zap_page(vcpu->kvm, page);
}
 }
-EXPORT_SYMBOL_GPL(kvm_mmu_free_some_pages);
 
 static void free_mmu_pages(struct kvm_vcpu *vcpu)
 {
-- 
1.5.3


-
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] Build of kvm-37 fails

[Avi Kivity]

Pelle wrote:

Hi,

I tried to compile the new kvm-37, and got the following errors:

regards, Pelle


  


Does the attached patch help?

--
error compiling committee.c: too many arguments to function

diff --git a/kernel/external-module-compat.h b/kernel/external-module-compat.h
index 33f1675..00b43f1 100644
--- a/kernel/external-module-compat.h
+++ b/kernel/external-module-compat.h
@@ -12,6 +12,7 @@
 #include "include/linux/kvm.h"
 #include 
 #include 
+#include 
 
 /*
  * 2.6.16 does not have GFP_NOWAIT
@@ -362,3 +363,8 @@ static inline void preempt_notifier_sys_init(void) {}
 static inline void preempt_notifier_sys_exit(void) {}
 
 #endif
+
+/* HRTIMER_MODE_ABS started life with a different name */
+#ifndef HRTIMER_MODE_ABS
+#define HRTIMER_MODE_ABS HRTIMER_ABS
+#endif
-
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] [Qemu-devel] Re: expose host CPU features to guests

[Avi Kivity]

Jamie Lokier wrote:
> Avi Kivity wrote:
>   
>> Let's start with '-cpu host' as 'cpu host-cpuid' and implement '-cpu 
>> host-os' on the first bug report?  I have a feeling we won't ever see it.
>> 
>
> I have a feeling you won't ever see it either, but not because it's a
> missing feature.
>
> Instead, I think a very small number of users will spend hours
> frustrated that some obscure guest doesn't work properly on their
> obscure x86 hardware, then they will learn that they should not use
> "-cpuid host" for that guest on that hardware, even though it works
> fine with other guests, and then their problem will be solved (albeit
> at a cost), and seen as such an obscure combination that it might
> never be reported to Qemu developers.
>
> In other words, host-os is what _I'd_ implement because I care too
> much about the poor obscure users and think it's the safe option, but
> I'm not doing the implementing here ;-)
>
> If you are curious what the differences are, do this in a current
> Linux source tree:
>
> egrep -R '(set|clear)_bit\(X86_FEATURE' arch/{i386,x86_64}/kernel
>
>   

Some of these are Linux issues, not host cpu issues (for example, it 
looks like VMI disables global pages).

Some of these issues may not impact the guest and we'd be removing them 
unnecessarily.  Also, kvm doesn't run on obscure hardware (although 
kqemu does; qemu itself is not a candidate for -cpu host).


-- 
error compiling committee.c: too many arguments to function


-
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] Build of kvm-37 fails

[Alexey Eremenko]

Excuse me, but I have the same problem with FC6, AMD, 64-bit, kernel 2.6.19.

I don't understand, where should I put the file you attached ?

-- 
-Alexey Eremenko "Technologov"

-
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] Build of kvm-37 fails

[Pelle]

Hi,

I tried to compile the new kvm-37, and got the following errors:

regards, Pelle



$ make
make -C kernel
make[1]: Entering directory `/home/ellep/Install/kvm-37/kernel'
make -C /lib/modules/2.6.20-16-generic/build M=`pwd` "$@"
make[2]: Entering directory `/usr/src/linux-headers-2.6.20-16-generic'
LD /home/ellep/Install/kvm-37/kernel/built-in.o
CC [M] /home/ellep/Install/kvm-37/kernel/svm.o
CC [M] /home/ellep/Install/kvm-37/kernel/vmx.o
CC [M] /home/ellep/Install/kvm-37/kernel/vmx-debug.o
CC [M] /home/ellep/Install/kvm-37/kernel/kvm_main.o
/home/ellep/Install/kvm-37/kernel/kvm_main.c: In function 
‘kvm_vcpu_ioctl_get_sregs’:
/home/ellep/Install/kvm-37/kernel/kvm_main.c:2183: warning: passing 
argument 2 of ‘set_bit’ from incompatible pointer type
CC [M] /home/ellep/Install/kvm-37/kernel/mmu.o
CC [M] /home/ellep/Install/kvm-37/kernel/x86_emulate.o
CC [M] /home/ellep/Install/kvm-37/kernel/anon_inodes.o
CC [M] /home/ellep/Install/kvm-37/kernel/irq.o
CC [M] /home/ellep/Install/kvm-37/kernel/i8259.o
CC [M] /home/ellep/Install/kvm-37/kernel/lapic.o
/home/ellep/Install/kvm-37/kernel/lapic.c: In function ‘start_apic_timer’:
/home/ellep/Install/kvm-37/kernel/lapic.c:608: error: ‘HRTIMER_MODE_ABS’ 
undeclared (first use in this function)
/home/ellep/Install/kvm-37/kernel/lapic.c:608: error: (Each undeclared 
identifier is reported only once
/home/ellep/Install/kvm-37/kernel/lapic.c:608: error: for each function 
it appears in.)
/home/ellep/Install/kvm-37/kernel/lapic.c: In function ‘kvm_create_lapic’:
/home/ellep/Install/kvm-37/kernel/lapic.c:952: error: ‘HRTIMER_MODE_ABS’ 
undeclared (first use in this function)
/home/ellep/Install/kvm-37/kernel/lapic.c:953: warning: assignment from 
incompatible pointer type
/home/ellep/Install/kvm-37/kernel/lapic.c: In function 
‘kvm_migrate_apic_timer’:
/home/ellep/Install/kvm-37/kernel/lapic.c:1042: error: 
‘HRTIMER_MODE_ABS’ undeclared (first use in this function)
make[3]: *** [/home/ellep/Install/kvm-37/kernel/lapic.o] Error 1
make[2]: *** [_module_/home/ellep/Install/kvm-37/kernel] Error 2
make[2]: Leaving directory `/usr/src/linux-headers-2.6.20-16-generic'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/ellep/Install/kvm-37/kernel'
make: *** [kernel] Error 2


-
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] Build of kvm-37 fails

[Avi Kivity]

Alexey Eremenko wrote:
> Excuse me, but I have the same problem with FC6, AMD, 64-bit, kernel 2.6.19.
>
> I don't understand, where should I put the file you attached ?
>
>   

Please don't trim the cc list and quote previous messages.  It's 
impossible to guess what this message refers to.


-- 
error compiling committee.c: too many arguments to function


-
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] [Qemu-devel] Re: expose host CPU features to guests

[Paul Brook]

On Sunday 09 September 2007, Jamie Lokier wrote:
> Avi Kivity wrote:
> > Let's start with '-cpu host' as 'cpu host-cpuid' and implement '-cpu
> > host-os' on the first bug report?  I have a feeling we won't ever see it.
>
> In other words, host-os is what _I'd_ implement because I care too
> much about the poor obscure users and think it's the safe option, but
> I'm not doing the implementing here ;-)

I agree. If the host OS has disabled a feature, it's a fair bet it's done that 
for a reason.

What you really want to do is ask your virtualization module what features it 
supports.

Paul

-
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-1791090 ] Fedora 7 64-bit crashes

[SourceForge.net]

Bugs item #1791090, was opened at 2007-09-09 18:28
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=1791090&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: Technologov (technologov)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fedora 7 64-bit crashes

Initial Comment:
Guest: Fedora 7 64-bit crashes.

Host: Fedora 7 64-bit, KVM-37, Intel Core 2.

It always worked before.

Command:
./qemu-my -hda /isos/disks/Fedora7-64.vmdk -m 512 &

Note: Fedora 7 32-bit and Debian 4.0 64-bit guests work fine.

-Alexey

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1791090&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] [Qemu-devel] Re: expose host CPU features to guests

[Avi Kivity]

Paul Brook wrote:
> On Sunday 09 September 2007, Jamie Lokier wrote:
>   
>> Avi Kivity wrote:
>> 
>>> Let's start with '-cpu host' as 'cpu host-cpuid' and implement '-cpu
>>> host-os' on the first bug report?  I have a feeling we won't ever see it.
>>>   
>> In other words, host-os is what _I'd_ implement because I care too
>> much about the poor obscure users and think it's the safe option, but
>> I'm not doing the implementing here ;-)
>> 
>
> I agree. If the host OS has disabled a feature, it's a fair bet it's done 
> that 
> for a reason.
>
>   

The reason may not be relevant to the guest.


> What you really want to do is ask your virtualization module what features it 
> supports.
>   

Yes, that needs to be an additional filter.


-- 
error compiling committee.c: too many arguments to function


-
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-37 problem w/ 64-bit division in lapic.c

[Jindrich Makovicka]

On Sun, 09 Sep 2007 14:05:13 +0300
Avi Kivity  wrote:

> This release merges the pic/lapic/ioapic into mainline.  While some 
> known issues exist, we're now at the point where it's better to get
> some wider exposure rather than keep it alone on a branch.
> 
> Some regressions are expected; please report them as they appear.  A
> new qmeu option -no-kvm-irqchip is available to disable the new
> functionality.

(message seems to get stuck at gmane, sorry if it appears twice
eventually)

My experience so far:

On 32-bit Intel host, lapic fails to link due to missing 64bit
division. I tried the attached patch to fix the build, but Windows
XP froze before showing the booting screen. With -no-kvm-irqchip
they work, except the IE plugins like Flash & Java, which are broken
since kvm-29. With -no-kvm, qemu-system-x86_64 segfaults immediately.

Regards,
-- 
Jindrich Makovicka
--- lapic.c~	2007-09-09 12:51:09.0 +0200
+++ lapic.c	2007-09-09 16:12:38.0 +0200
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "irq.h"
 
 #define PRId64 "d"
@@ -511,8 +512,8 @@
 	} else
 		passed = ktime_sub(now, apic->timer.last_update);
 
-	counter_passed = ktime_to_ns(passed) /
-	(APIC_BUS_CYCLE_NS * apic->timer.divide_count);
+	counter_passed = div64_64(ktime_to_ns(passed),
+  (APIC_BUS_CYCLE_NS * apic->timer.divide_count));
 	tmcct -= counter_passed;
 
 	if (tmcct <= 0) {
-
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] kvm-37 problem w/ 64-bit division in lapic.c

[Avi Kivity]

Jindrich Makovicka wrote:
> On Sun, 09 Sep 2007 14:05:13 +0300
> Avi Kivity  wrote:
>
>   
>> This release merges the pic/lapic/ioapic into mainline.  While some 
>> known issues exist, we're now at the point where it's better to get
>> some wider exposure rather than keep it alone on a branch.
>>
>> Some regressions are expected; please report them as they appear.  A
>> new qmeu option -no-kvm-irqchip is available to disable the new
>> functionality.
>> 
>
> (message seems to get stuck at gmane, sorry if it appears twice
> eventually)
>
> My experience so far:
>
> On 32-bit Intel host, lapic fails to link due to missing 64bit
> division. I tried the attached patch to fix the build, but Windows
> XP froze before showing the booting screen. With -no-kvm-irqchip
> they work, except the IE plugins like Flash & Java, which are broken
> since kvm-29. With -no-kvm, qemu-system-x86_64 segfaults immediately.
>
>   

Applied, thanks.  Please supply a signed-off-by line with future patches.

-- 
error compiling committee.c: too many arguments to function


-
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] [Qemu-devel] Re: expose host CPU features to guests

[Jamie Lokier]

Avi Kivity wrote:
> >I agree. If the host OS has disabled a feature, it's a fair bet it's done 
> >that for a reason.
> 
> The reason may not be relevant to the guest.

For most guests the relevant features are those which work correctly
and efficiently on the virtual CPU.

If the host OS has disabled a feature, most often that's because the
feature doesn't work on the specific host CPU model, but not always.
It might be emulated well, but probably not efficiently.

In some cases, you might want a guest to see features supported by the
host CPU which the host OS has disabled, but I imagine those are
unusual - it doesn't seem very likely.  Can you give an example?

They can be enabled explicitly by the -cpuid flag if needed.

-- Jamie

-
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] [Qemu-devel] Re: expose host CPU features to guests

[Paul Brook]

> > What you really want to do is ask your virtualization module what
> > features it supports.
>
> Yes, that needs to be an additional filter.

I'd have thought that would be the *only* interesting set for autodetection.

Paul

-
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] [Qemu-devel] Re: expose host CPU features to guests

[Avi Kivity]

Paul Brook wrote:
>>> What you really want to do is ask your virtualization module what
>>> features it supports.
>>>   
>> Yes, that needs to be an additional filter.
>> 
>
> I'd have thought that would be the *only* interesting set for autodetection.
>
>   

Yes, you're right.  It's pointless to issue cpuid in userspace and mask 
it in the kernel; rather we can issue it in the kernel , mask out 
unsupported features, and return it to userspace.

-- 
error compiling committee.c: too many arguments to function


-
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] [BUG][PATCH?] kvm: unhandled wrmsr: 0xc0000083

[Luca Tettamanti]

Il Sun, Sep 09, 2007 at 03:51:20PM +0300, Avi Kivity ha scritto: 
> Luca Tettamanti wrote:
>>> Actually 0xfff2 is in the middle of an instruction.
>>>
>>> I'm guessing an 'out' instruction triggered the reboot, and 
>>> skip_emulated_instruction() added 2 to rip.
>>> 
>>
>> I think you're right; the reset is triggered by an outb to 0x64.
>>
>> Now, with this patch:
>>
>> diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
>> index 491c32c..722d838 100644
>> --- a/qemu/qemu-kvm.c
>> +++ b/qemu/qemu-kvm.c
>> @@ -706,8 +706,12 @@ static void update_regs_for_sipi(CPUState *env)
>>   static void update_regs_for_init(CPUState *env)
>>  {
>> -cpu_reset(env);
>> -load_regs(env);
>> +if (env->cpu_index) {
>> +cpu_reset(env);
>> +load_regs(env);
>> +} else {
>> + vcpu_info[env->cpu_index].init = 0;
>> +}
>>  }
>>   
>
> Can you explain this patch?  Why is the boot cpu treated differently?
> I think the only difference should be the halted flag.

The reset has already been done by qmeu_system_reset(), so it's
superfluous. Furthermore, the extra reset causes the vmentry failure. I
still don't understand which check is failing though...

>>   static void setup_kernel_sigmask(CPUState *env)
>>
>> I can reboot using the BIOS (reboot=b) without the outb. I fail to see
>> why an extra reset causes the vm entry failure though.
>>
>> Default reboot path (i.e. the outb) still fails:
>>
>> exception 13 (0)
>> rax  rbx  rcx  rdx 
>> 0700
>> rsi  rdi  rsp  rbp 
>> 
>> r8   r9   r10  r11 
>> 
>> r12  r13  r14  r15 
>> 
>> rip  rflags 00033046
>> cs f000 (000f/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
>> ds  (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
>> es  (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
>> ss  (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
>> fs  (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
>> gs  (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
>> tr 0080 (1085/2088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0)
>> ldt  (/ p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0)
>> gdt 0/
>> idt 0/
>> cr0 6010 cr2 0 cr3 0 cr4 0 cr8 0 efer 0
>> code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 --> 00 
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
>> 00 00 00 00
>>
>> the #GP makes more sense than the vm entry failure if the the emulator
>> is jumping to fff2.
>
> Right.  Maybe the processor dropped out of vm86 mode and we're getting #gp 
> on ds.

Ok, the culprit really is skip_emulated_instruction: skipping the
increment when EIP is 0xfff0 allows rebooting (yes, it's disgusting...)

So I think that there are two different issues:

1) Extra reset in update_regs_for_init causes vm entry failure due to
   invalid guest state

2) The emulator is doing something wrong since it used to handle the
   reset just fine

Luca
-- 
Una donna sposa un uomo sperando che cambi, e lui non cambiera`. Un
uomo sposa una donna sperando che non cambi, e lei cambiera`.

-
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] [BUG][PATCH?] kvm: unhandled wrmsr: 0xc0000083

[Avi Kivity]

Luca Tettamanti wrote:
> Il Sun, Sep 09, 2007 at 03:51:20PM +0300, Avi Kivity ha scritto: 
>   
>> Luca Tettamanti wrote:
>> 
 Actually 0xfff2 is in the middle of an instruction.

 I'm guessing an 'out' instruction triggered the reboot, and 
 skip_emulated_instruction() added 2 to rip.
 
 
>>> I think you're right; the reset is triggered by an outb to 0x64.
>>>
>>> Now, with this patch:
>>>
>>> diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
>>> index 491c32c..722d838 100644
>>> --- a/qemu/qemu-kvm.c
>>> +++ b/qemu/qemu-kvm.c
>>> @@ -706,8 +706,12 @@ static void update_regs_for_sipi(CPUState *env)
>>>   static void update_regs_for_init(CPUState *env)
>>>  {
>>> -cpu_reset(env);
>>> -load_regs(env);
>>> +if (env->cpu_index) {
>>> +cpu_reset(env);
>>> +load_regs(env);
>>> +} else {
>>> + vcpu_info[env->cpu_index].init = 0;
>>> +}
>>>  }
>>>   
>>>   
>> Can you explain this patch?  Why is the boot cpu treated differently?
>> I think the only difference should be the halted flag.
>> 
>
> The reset has already been done by qmeu_system_reset(), so it's
> superfluous. Furthermore, the extra reset causes the vmentry failure. 

I just committed a patch which prevented .init from being set to 1 on 
cpu_index == 0.

> I
> still don't understand which check is failing though...
>
>   

These are tough...

>>> the #GP makes more sense than the vm entry failure if the the emulator
>>> is jumping to fff2.
>>>   
>> Right.  Maybe the processor dropped out of vm86 mode and we're getting #gp 
>> on ds.
>> 
>
> Ok, the culprit really is skip_emulated_instruction: skipping the
> increment when EIP is 0xfff0 allows rebooting (yes, it's disgusting...)
>
> So I think that there are two different issues:
>
> 1) Extra reset in update_regs_for_init causes vm entry failure due to
>invalid guest state
>
> 2) The emulator is doing something wrong since it used to handle the
>reset just fine
>   

It may have been timing.  kvm continued to run for a bit, reaching a 
non-emulated instruction, and then the reset hit it in the face.  The 
reset is much quicker now.

We should probably both fix the kernel to handle reset-during-emulation 
correctly (one ugly way is to zero the instruction length if we're 
setting rip), and fix userspace to delay reset like it used to for 
compatibility with older kernels.

-- 
error compiling committee.c: too many arguments to function


-
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] [BUG] GPF on hardware breakpoints (preempt_notifier)

[Luca Tettamanti]

Hi,
while debugging a program with GDB I got a GPF which seems related to
KVM. Note that I was *not* using the debugger inside the guest nor on
the virtual machine. The target was an unrelated userspace program.

This is the GPF:

general protection fault:  [#1]
PREEMPT SMP
Modules linked in: kvm_intel kvm bridge llc tun radeon drm binfmt_misc
nfs cpufreq_stats cpufreq_userspace cpufreq_powersave
cpufreq_conservative microcode firmware_class cls_u32 cls_route sch_sfq
sch_cbq des cbc blkcipher sha1 md5 hmac crypto_hash cryptomgr
crypto_algapi nfsd exportfs lockd sunrpc fuse cpufreq_ondemand
acpi_cpufreq freq_table ipv6 usblp snd_hda_intel snd_pcm_oss ohci1394
snd_mixer_oss atl1 ieee1394 iTCO_wdt parport_pc parport i2c_i801 rtc
e100 snd_pcm snd_timer button mii ehci_hcd snd uhci_hcd intel_agp
usbcore soundcore snd_page_alloc agpgart dm_snapshot dm_mod thermal
processor fan vfat fat nls_cp850 nls_iso8859_15 ntfs nls_base pata_ali
sata_uli pata_jmicron reiserfs xfs
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 00010002   (2.6.23-rc5-libata-gb21010ed-dirty #96)
EIP is at preempt_notifier_trigger+0x7/0x7a [kvm]
eax: f9cff460   ebx: b7f29ff4   ecx: bf91aa60   edx: bf91aa80
esi: b7f61ce0   edi:    ebp: bf91aa48   esp: e03e9fb8
ds: 007b   es: 007b   fs:   gs: 0033  ss: 0068
Process p (pid: 13319, ti=e03e9000 task=f5d02530 task.ti=e03e9000)
Stack: b7f29ff4 b7f61ce0 f9cfa8be  b7f61ce0 bf91aa48 e03e9fe4 b7f29ff4
   bf91aa80 bf91aa60 0001 0804835f 0073 0202 bf91aa44 007b
    
Call Trace:
 [] pn_int1_handler+0x12/0x22 [kvm]
 ===
Code: b8 01 00 00 00 e8 7e 43 42 c6 89 e0 25 00 f0 ff ff 8b 40 08 a8 04
74 08 5b 5e 5f e9 93 51 5f c6 5b 5e 5f c3 56 b8 60 f4 cf f9 53 <64> 8b
35 08 20 42 c0 e8 48 77 5f c6 8b 1d 84 f4 cf f9 89 c2 eb
EIP: [] preempt_notifier_trigger+0x7/0x7a [kvm] SS:ESP 0068:e03e9fb8

To reproduce just set a hw breakpoint (e.g. watch inside GDB) while a VM
is running. As soon as the breakpoint is hit you get at GPF...

Host userspace and kernel are 32bit, the CPU is a Core2:

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Core(TM)2 CPU  6400  @ 2.13GHz
stepping: 6
cpu MHz : 1596.000
cache size  : 2048 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 2
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat
  pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
  constant_tsc arch_perfmon pebs bts pni monitor ds_cpl vmx est 
tm2
  ssse3 cx16 xtpr lahf_lm
bogomips: 4274.53
clflush size: 64

Luca
-- 
Quando un uomo porta dei fiori a sua moglie senza motivo, 
un motivo c'e`.

-
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] [BUG] GPF on hardware breakpoints (preempt_notifier)

[Avi Kivity]

Luca Tettamanti wrote:
> Hi,
> while debugging a program with GDB I got a GPF which seems related to
> KVM. Note that I was *not* using the debugger inside the guest nor on
> the virtual machine. The target was an unrelated userspace program.
>
>   

Yes, kvm is dirtily misappropriating the debug registers on older 
kernels.  We really should context switch them more carefully.


-- 
error compiling committee.c: too many arguments to function


-
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] [BUG] GPF on hardware breakpoints (preempt_notifier)

[Luca]

On 9/9/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
> Luca Tettamanti wrote:
> > Hi,
> > while debugging a program with GDB I got a GPF which seems related to
> > KVM. Note that I was *not* using the debugger inside the guest nor on
> > the virtual machine. The target was an unrelated userspace program.
> >
>
> Yes, kvm is dirtily misappropriating the debug registers on older
> kernels.

I'm runninng the current Linus' git tree, shall I test kvm.git?

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-37 results

[Jorge Lucángeli Obes]

UP:
==

Windows XP 32-bit guest: OK

Windows 2003 Server 32-bit guest: OK

Windows Vista Ultimate 32-bit guest: hangs during boot.
*Command line:
-net nic,model=8139 -m 512 -localtime
*Nothing in dmesg besides processor 1 inicialization SIPI messages
*Still hangs during boot with 'no-kvm-irqchip'

SMP:
===

Slackware 12 32-bit guest: OK

Windows XP 32-bit guest: doesn't boot.
*Command line:
-localtime -m 512 -smp 2
*Nothing in dmesg besides processor 1 inicialization SIPI messages
*Works with 'no-kvm-irqchip'

-
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] [BUG] GPF on hardware breakpoints (preempt_notifier)

[Anthony Liguori]

Luca wrote:
> On 9/9/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
>   
>> Luca Tettamanti wrote:
>> 
>>> Hi,
>>> while debugging a program with GDB I got a GPF which seems related to
>>> KVM. Note that I was *not* using the debugger inside the guest nor on
>>> the virtual machine. The target was an unrelated userspace program.
>>>
>>>   
>> Yes, kvm is dirtily misappropriating the debug registers on older
>> kernels.
>> 
>
> I'm runninng the current Linus' git tree, shall I test kvm.git?
>   

Do you have CONFIG_PREEMPT_NOTIFIERS enabled?

Regards,

Anthony Liguori

> 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
>
>   


-
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] [BUG] GPF on hardware breakpoints (preempt_notifier)

[Luca]

On 9/9/07, Anthony Liguori <[EMAIL PROTECTED]> wrote:
> Luca wrote:
> > On 9/9/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
> >
> >> Luca Tettamanti wrote:
> >>
> >>> Hi,
> >>> while debugging a program with GDB I got a GPF which seems related to
> >>> KVM. Note that I was *not* using the debugger inside the guest nor on
> >>> the virtual machine. The target was an unrelated userspace program.
> >>>
> >>>
> >> Yes, kvm is dirtily misappropriating the debug registers on older
> >> kernels.
> >>
> >
> > I'm runninng the current Linus' git tree, shall I test kvm.git?
> >
>
> Do you have CONFIG_PREEMPT_NOTIFIERS enabled?

No, it's disabled.

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

Re: [kvm-devel] kvm-36 losing (tap-based) network connectivitymid-session

[Charles Duffy]

Avi Kivity wrote:
> Can you check with the other emulated nic? (-nic model=...)
Happens with both ne2k_pci and rtl8139; I haven't tried with others.

-
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] [BUG] GPF on hardware breakpoints (preempt_notifier)

[Anthony Liguori]

Luca wrote:
> On 9/9/07, Anthony Liguori <[EMAIL PROTECTED]> wrote:
>   
>> Luca wrote:
>> 
>>> On 9/9/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
>>>
>>>   
 Luca Tettamanti wrote:

 
> Hi,
> while debugging a program with GDB I got a GPF which seems related to
> KVM. Note that I was *not* using the debugger inside the guest nor on
> the virtual machine. The target was an unrelated userspace program.
>
>
>   
 Yes, kvm is dirtily misappropriating the debug registers on older
 kernels.

 
>>> I'm runninng the current Linus' git tree, shall I test kvm.git?
>>>
>>>   
>> Do you have CONFIG_PREEMPT_NOTIFIERS enabled?
>> 
>
> No, it's disabled.
>   

If you enable it, you probably won't see this problem.  KVM emulates 
PREEMPT_NOTIFIERS using debug registers.

Regards,

Anthony Liguori

> 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] build failure on master branch

[Zhao, Yunfeng]

I meet the following error when I build latest kvm master against kernel
2.6.22 as external modules.

And it's ok if I build it against kvm kernel either build-in or as
external modules.

 

/kvm-userspace/BUILD/kernel/lapic.c: In function 'start_apic_timer':

/kvm-userspace/BUILD/kernel/lapic.c:609: error: 'HRTIMER_ABS' undeclared
(first use in this function)

/kvm-userspace/BUILD/kernel/lapic.c:609: error: (Each undeclared
identifier is reported only once

/kvm-userspace/BUILD/kernel/lapic.c:609: error: for each function it
appears in.)

/kvm-userspace/BUILD/kernel/lapic.c: In function 'kvm_create_lapic':

/kvm-userspace/BUILD/kernel/lapic.c:953: error: 'HRTIMER_ABS' undeclared
(first use in this function)

/kvm-userspace/BUILD/kernel/lapic.c: In function
'kvm_migrate_apic_timer':

/kvm-userspace/BUILD/kernel/lapic.c:1043: error: 'HRTIMER_ABS'
undeclared (first use in this function)

/kvm-userspace/BUILD/kernel/lapic.o] Error 1

make[3]: *** Waiting for unfinished jobs

make[2]: ***
[_module_/workspace/ia32e/nightly/kvm-master-2.6.22-rc4-2007091009011464
0/kvm-userspace/BUILD/kernel] Error 2

make[2]: Leaving directory
`/usr/src/redhat/BUILD/kernel-2.6.22rc4g85f6038f'

make[1]: *** [all] Error 2

make[1]: Leaving directory
`/workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20070910090114640/kvm-us
erspace/BUILD/kernel'

error: Bad exit status from /var/tmp/rpm-tmp.70011 (%build)

 

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] build failure on master branch

[He, Qing]

Well, it seems hrtimer-compat patch breaks the build.

 

HRTIMER_MOD_ABS is declared in enum, so we can’t say:

 

  #ifndef HRTIMER_MOD_ABS

  #define HRTIMER_MOD_ABS HRTIMER_ABS

  #endif

 

maybe something like

  #if LINUX_VERSION_CODE >= KERNEL_VERSION(2.6.?)

 

should be OK.

 



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zhao, Yunfeng
Sent: 2007年9月10日 10:41
To: kvm-devel@lists.sourceforge.net
Subject: [kvm-devel] build failure on master branch

 

I meet the following error when I build latest kvm master against kernel 2.6.22 
as external modules.

And it’s ok if I build it against kvm kernel either build-in or as external 
modules.

 

/kvm-userspace/BUILD/kernel/lapic.c: In function 'start_apic_timer':

/kvm-userspace/BUILD/kernel/lapic.c:609: error: 'HRTIMER_ABS' undeclared (first 
use in this function)

/kvm-userspace/BUILD/kernel/lapic.c:609: error: (Each undeclared identifier is 
reported only once

/kvm-userspace/BUILD/kernel/lapic.c:609: error: for each function it appears 
in.)

/kvm-userspace/BUILD/kernel/lapic.c: In function 'kvm_create_lapic':

/kvm-userspace/BUILD/kernel/lapic.c:953: error: 'HRTIMER_ABS' undeclared (first 
use in this function)

/kvm-userspace/BUILD/kernel/lapic.c: In function 'kvm_migrate_apic_timer':

/kvm-userspace/BUILD/kernel/lapic.c:1043: error: 'HRTIMER_ABS' undeclared 
(first use in this function)

/kvm-userspace/BUILD/kernel/lapic.o] Error 1

make[3]: *** Waiting for unfinished jobs

make[2]: *** 
[_module_/workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20070910090114640/kvm-userspace/BUILD/kernel]
 Error 2

make[2]: Leaving directory `/usr/src/redhat/BUILD/kernel-2.6.22rc4g85f6038f'

make[1]: *** [all] Error 2

make[1]: Leaving directory 
`/workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20070910090114640/kvm-userspace/BUILD/kernel'

error: Bad exit status from /var/tmp/rpm-tmp.70011 (%build)

 

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

[kvm-devel] [PATCH] passing smp cpu count from CMOS

[He, Qing]

As discussed previously, this patch directly passes SMP CPU count to the
guest BIOS from CMOS by qemu, instead of sending SIPI and wait. CMOS
offset 0x7f is used.

This is the last functional piece for in-kernel APIC merge in kvm-37.

Signed-off-by: Qing He <[EMAIL PROTECTED]>


bios/BIOS-bochs-latest |  Bin
 bios/BIOS-bochs-legacy |  Bin
 bios/rombios32.c   |7 +++
 qemu/hw/mc146818rtc.c  |6 ++
 qemu/pc-bios/bios.bin  |  Bin
 5 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/bios/BIOS-bochs-latest b/bios/BIOS-bochs-latest
index eb76dc7..99b78bf 100644
Binary files a/bios/BIOS-bochs-latest and b/bios/BIOS-bochs-latest
differ
diff --git a/bios/BIOS-bochs-legacy b/bios/BIOS-bochs-legacy
index f5947f6..423ea50 100644
Binary files a/bios/BIOS-bochs-legacy and b/bios/BIOS-bochs-legacy
differ
diff --git a/bios/rombios32.c b/bios/rombios32.c
index faf771e..3bb5e00 100755
--- a/bios/rombios32.c
+++ b/bios/rombios32.c
@@ -41,6 +41,9 @@ typedef unsigned long long uint64_t;
 /* define it if the (emulated) hardware supports SMM mode */
 #define BX_USE_SMM
 
+/* read CPU count from CMOS directly instead of probing */
+#define BX_CMOS_CPU_COUNT
+
 #define cpuid(index, eax, ebx, ecx, edx) \
   asm volatile ("cpuid" \
 : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx) \
@@ -442,9 +445,13 @@ void smp_probe(void)
 sipi_vector = AP_BOOT_ADDR >> 12;
 writel(APIC_BASE + APIC_ICR_LOW, 0x000C4600 | sipi_vector);
 
+#ifdef BX_CMOS_CPU_COUNT
+smp_cpus = cmos_readb(0x7f);
+#else
 delay_ms(10);
 
 smp_cpus = readw((void *)CPU_COUNT_ADDR);
+#endif
 }
 BX_INFO("Found %d cpu(s)\n", smp_cpus);
 }
diff --git a/qemu/hw/mc146818rtc.c b/qemu/hw/mc146818rtc.c
index bad4cbd..3c4c25d 100644
--- a/qemu/hw/mc146818rtc.c
+++ b/qemu/hw/mc146818rtc.c
@@ -33,6 +33,9 @@
 #define RTC_HOURS_ALARM 5
 #define RTC_ALARM_DONT_CARE0xC0
 
+/* KVM specific extension: smp cpu count passing */
+#define RTC_CMOS_CPU_COUNT 0x7f
+
 #define RTC_DAY_OF_WEEK 6
 #define RTC_DAY_OF_MONTH7
 #define RTC_MONTH   8
@@ -356,6 +359,9 @@ static uint32_t cmos_ioport_read(void *opaque,
uint32_t addr)
 pic_set_irq(s->irq, 0);
 s->cmos_data[RTC_REG_C] = 0x00; 
 break;
+case RTC_CMOS_CPU_COUNT:
+ret = smp_cpus;
+break;
 default:
 ret = s->cmos_data[s->cmos_index];
 break;
diff --git a/qemu/pc-bios/bios.bin b/qemu/pc-bios/bios.bin
index eb76dc7..99b78bf 100644
Binary files a/qemu/pc-bios/bios.bin and b/qemu/pc-bios/bios.bin differ


bios-cmos-cpus-passing.patch
Description: bios-cmos-cpus-passing.patch
-
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] unhandled vm exit on kvm36 with Etch 32 guest on AMD64

[Joseph Wolff]

Hello,

I'm getting "unhandled vm exit:0xb8002" running a Debian Etch guest 
under kvm36 on AMD64.

The host is a 4-core dual-dual AMD, and I was able to create the Debian 
Etch (4.0) guest image just fine, using a standard install, from the 
standard Debian DVD disc1: debian-40r0-i386-DVD-1.iso

Distro is Ubuntu Gutsy, kernel is brand-new 2.6.22-11-server from the 
Gutsy repo. The KVM36 was installed via apt-pinning from the Debian 
(sid) repo (they're compatible - dependencies all met). The KVM36 is the 
only thing from the sid repo.

I originally upgraded to kvm36 because I was having this problem on the 
default Gutsy kvm28, and the Guest Status page for Etch says kvm29 works 
(albeit with Intel), but this is the same error I was getting with kvm28.


Here's the commandline and the subsequent regdump:

[EMAIL PROTECTED]:/vm/143#  kvm -vnc :1 -k en-us -net 
nic,macaddr=de:ad:be:ef:01:43 -net tap -monitor 
telnet::23143,server,nowait,nodelay -cdrom 
/iso/debian-40r0-i386-DVD-1.iso -append vga=771 debian-40r0-i386.8G.qc2

In /etc/kvm/kvm-ifup, adding: tap0

unhandled vm exit:  0xb8002
rax c0318000 rbx 0fa0 rcx 0fa0 rdx 
c00b8000
rsi c00b8000 rdi c110a980 rsp c0319fb8 rbp 
c110a980
r8   r9   r10  r11 

r12  r13  r14  r15 

rip c01bc276 rflags 0206
cs 0060 (/ p 1 dpl 0 db 1 s 1 type b l 0 g 0 avl 0)
ds 007b (/ p 1 dpl 3 db 1 s 1 type 2 l 0 g 1 avl 0)
es 007b (/ p 1 dpl 3 db 1 s 1 type 3 l 0 g 1 avl 0)
ss 0068 (/ p 1 dpl 0 db 1 s 1 type 2 l 0 g 1 avl 0)
fs  (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0)
gs  (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0)
tr 0080 (c11006c0/2073 p 1 dpl 0 db 0 s 0 type 9 l 0 g 0 avl 0)
ldt 0088 (c0352020/0027 p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0)
gdt c1109000/ff
idt c030f000/7ff
cr0 80050033 cr2 0 cr3 34f000 cr4 690 cr8 0 efer 0
Aborted
[EMAIL PROTECTED]:/vm/143#



Let me know,

Cheers,
joe



-
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] build failure on master branch

[He, Qing]

You can try the attached patch to see if it works

 

 



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of He, Qing
Sent: 2007年9月10日 10:55
To: Zhao, Yunfeng; kvm-devel@lists.sourceforge.net
Subject: Re: [kvm-devel] build failure on master branch

 

Well, it seems hrtimer-compat patch breaks the build.

 

HRTIMER_MOD_ABS is declared in enum, so we can’t say:

 

  #ifndef HRTIMER_MOD_ABS

  #define HRTIMER_MOD_ABS HRTIMER_ABS

  #endif

 

maybe something like

  #if LINUX_VERSION_CODE >= KERNEL_VERSION(2.6.?)

 

should be OK.

 



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zhao, Yunfeng
Sent: 2007年9月10日 10:41
To: kvm-devel@lists.sourceforge.net
Subject: [kvm-devel] build failure on master branch

 

I meet the following error when I build latest kvm master against kernel 2.6.22 
as external modules.

And it’s ok if I build it against kvm kernel either build-in or as external 
modules.

 

/kvm-userspace/BUILD/kernel/lapic.c: In function 'start_apic_timer':

/kvm-userspace/BUILD/kernel/lapic.c:609: error: 'HRTIMER_ABS' undeclared (first 
use in this function)

/kvm-userspace/BUILD/kernel/lapic.c:609: error: (Each undeclared identifier is 
reported only once

/kvm-userspace/BUILD/kernel/lapic.c:609: error: for each function it appears 
in.)

/kvm-userspace/BUILD/kernel/lapic.c: In function 'kvm_create_lapic':

/kvm-userspace/BUILD/kernel/lapic.c:953: error: 'HRTIMER_ABS' undeclared (first 
use in this function)

/kvm-userspace/BUILD/kernel/lapic.c: In function 'kvm_migrate_apic_timer':

/kvm-userspace/BUILD/kernel/lapic.c:1043: error: 'HRTIMER_ABS' undeclared 
(first use in this function)

/kvm-userspace/BUILD/kernel/lapic.o] Error 1

make[3]: *** Waiting for unfinished jobs

make[2]: *** 
[_module_/workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20070910090114640/kvm-userspace/BUILD/kernel]
 Error 2

make[2]: Leaving directory `/usr/src/redhat/BUILD/kernel-2.6.22rc4g85f6038f'

make[1]: *** [all] Error 2

make[1]: Leaving directory 
`/workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20070910090114640/kvm-userspace/BUILD/kernel'

error: Bad exit status from /var/tmp/rpm-tmp.70011 (%build)

 

thanks

Yunfeng



hrtimer-compat-wa.patch
Description: hrtimer-compat-wa.patch
-
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] build failure on master branch

[Zhao, Yunfeng]

The issue is fixed after applied the patch.

Thanks a lot!
Yunfeng


From: He, Qing 
Sent: 2007年9月10日 11:35
To: He, Qing; Zhao, Yunfeng; kvm-devel@lists.sourceforge.net
Subject: RE: [kvm-devel] build failure on master branch

You can try the attached patch to see if it works



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of He, Qing
Sent: 2007年9月10日 10:55
To: Zhao, Yunfeng; kvm-devel@lists.sourceforge.net
Subject: Re: [kvm-devel] build failure on master branch

Well, it seems hrtimer-compat patch breaks the build.

HRTIMER_MOD_ABS is declared in enum, so we can’t say:

  #ifndef HRTIMER_MOD_ABS
  #define HRTIMER_MOD_ABS HRTIMER_ABS
  #endif

maybe something like
  #if LINUX_VERSION_CODE >= KERNEL_VERSION(2.6.?)

should be OK.


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zhao, Yunfeng
Sent: 2007年9月10日 10:41
To: kvm-devel@lists.sourceforge.net
Subject: [kvm-devel] build failure on master branch

I meet the following error when I build latest kvm master against kernel 2.6.22 
as external modules.
And it’s ok if I build it against kvm kernel either build-in or as external 
modules.

/kvm-userspace/BUILD/kernel/lapic.c: In function 'start_apic_timer':
/kvm-userspace/BUILD/kernel/lapic.c:609: error: 'HRTIMER_ABS' undeclared (first 
use in this function)
/kvm-userspace/BUILD/kernel/lapic.c:609: error: (Each undeclared identifier is 
reported only once
/kvm-userspace/BUILD/kernel/lapic.c:609: error: for each function it appears 
in.)
/kvm-userspace/BUILD/kernel/lapic.c: In function 'kvm_create_lapic':
/kvm-userspace/BUILD/kernel/lapic.c:953: error: 'HRTIMER_ABS' undeclared (first 
use in this function)
/kvm-userspace/BUILD/kernel/lapic.c: In function 'kvm_migrate_apic_timer':
/kvm-userspace/BUILD/kernel/lapic.c:1043: error: 'HRTIMER_ABS' undeclared 
(first use in this function)
/kvm-userspace/BUILD/kernel/lapic.o] Error 1
make[3]: *** Waiting for unfinished jobs
make[2]: *** 
[_module_/workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20070910090114640/kvm-userspace/BUILD/kernel]
 Error 2
make[2]: Leaving directory `/usr/src/redhat/BUILD/kernel-2.6.22rc4g85f6038f'
make[1]: *** [all] Error 2
make[1]: Leaving directory 
`/workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20070910090114640/kvm-userspace/BUILD/kernel'
error: Bad exit status from /var/tmp/rpm-tmp.70011 (%build)

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 2/3] KVM: fix apic timer save/migration when inactive

[He, Qing]

Avi,
This is the updated patch, which avoids inactive hrtimers from 
unintended migrations.

save/restore timer logic is not included because it does not call 
hrtimer_cancel (hrtimer_active is different). It has relatively small impact, 
for it only affects save/restore at maybe guest BIOS time, maybe we can defer 
it to some later time

>-Original Message-
>From: Avi Kivity [mailto:[EMAIL PROTECTED]
>Sent: 2007年9月9日 15:39
>To: He, Qing
>Cc: kvm-devel@lists.sourceforge.net
>Subject: Re: [kvm-devel] [PATCH 2/3] KVM: fix apic timer save/migration when 
>inactive
>
>He, Qing wrote:
>>
> +if (atomic_read(&apic->timer.active))
>
>
 Or here?


> +hrtimer_start(timer, timer->expires,
> +  HRTIMER_MODE_ABS);
>  }
>  EXPORT_SYMBOL_GPL(kvm_migrate_apic_timer);
>
>
>
>>> I think you could use the return value of hrtimer_cancel() here:
>>>
>>>if (hrtimer_cancel(...))
>>>hrtimer_start(...);
>>>
>>
>> Thanks for commenting, previously I have thought of something like:
>>  if (hrtimer_active(...)) {
>>  hrtimer_cancel(...);
>>  hrtimer_start(...);
>>  }
>>
>> But it is not able to handle pending state this way. Seems the return value 
>> of
>hrtimer_cancel is fine. Another question is, when the hrtimer function returns
>HRTIMER_NORESTART, does the state finally turn to HRTIMER_STATE_INACTIVE?
>>
>
>From my reading of the hrtimer code, yes. But I would view any code
>which depends on the state with suspicion.
>
>
>--
>error compiling committee.c: too many arguments to function


hrtimer-compat-wa.patch
Description: hrtimer-compat-wa.patch
-
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 2/3] KVM: fix apic timer save/migration wheninactive

[He, Qing]

resended, due to wrong attachment

>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of He, Qing
>Sent: 2007年9月10日 13:59
>To: Avi Kivity
>Cc: kvm-devel@lists.sourceforge.net
>Subject: Re: [kvm-devel] [PATCH 2/3] KVM: fix apic timer save/migration 
>wheninactive
>
>Avi,
>   This is the updated patch, which avoids inactive hrtimers from 
> unintended
>migrations.
>
>save/restore timer logic is not included because it does not call 
>hrtimer_cancel
>(hrtimer_active is different). It has relatively small impact, for it only 
>affects save/restore
>at maybe guest BIOS time, maybe we can defer it to some later time
>
>>-Original Message-
>>From: Avi Kivity [mailto:[EMAIL PROTECTED]
>>Sent: 2007年9月9日 15:39
>>To: He, Qing
>>Cc: kvm-devel@lists.sourceforge.net
>>Subject: Re: [kvm-devel] [PATCH 2/3] KVM: fix apic timer save/migration when 
>>inactive
>>
>>He, Qing wrote:
>>>
>> +if (atomic_read(&apic->timer.active))
>>
>>
> Or here?
>
>
>> +hrtimer_start(timer, timer->expires,
>> +  HRTIMER_MODE_ABS);
>>  }
>>  EXPORT_SYMBOL_GPL(kvm_migrate_apic_timer);
>>
>>
>>
 I think you could use the return value of hrtimer_cancel() here:

if (hrtimer_cancel(...))
hrtimer_start(...);

>>>
>>> Thanks for commenting, previously I have thought of something like:
>>> if (hrtimer_active(...)) {
>>> hrtimer_cancel(...);
>>> hrtimer_start(...);
>>> }
>>>
>>> But it is not able to handle pending state this way. Seems the return value 
>>> of
>>hrtimer_cancel is fine. Another question is, when the hrtimer function returns
>>HRTIMER_NORESTART, does the state finally turn to HRTIMER_STATE_INACTIVE?
>>>
>>
>>From my reading of the hrtimer code, yes. But I would view any code
>>which depends on the state with suspicion.
>>
>>
>>--
>>error compiling committee.c: too many arguments to function


kvm-hrtimer-migration-fix.patch
Description: kvm-hrtimer-migration-fix.patch
-
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