Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

[Carsten Otte]

Izik Eidus wrote:
> btw, if you look at kvmctl, we already do it,
> so it is good question if it better to leave this work to userspace 
> (like it do now)
> or do the mapping to userspace from the kernel to userspace (using the 
> mmap syscall)
> 
> (i like the secoend option beacuse it would be easier to work with qemu 
> like this)
I think we should leave it to userland. This was userland is free to 
use whatever it wants:
- malloc() to get anonymous memory
- mmap() to get file backed memory
- posix or sysv shared memory
- hugetlbfs to save translation steps

so long,
Carsten

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [RFT] kvm with Windows optimization

[Avi Kivity]

Anthony Liguori wrote:
> Avi Kivity wrote:
>   
>> Anthony Liguori wrote:
>> 
> static int mmu_topup_memory_caches(struct kvm_vcpu *vcpu)
> {
> int r;
>
> kvm_mmu_free_some_pages(vcpu);
> r = mmu_topup_memory_cache(&vcpu->mmu_pte_chain_cache,
>pte_chain_cache, 4);
> if (r)
> goto out;
> r = mmu_topup_memory_cache(&vcpu->mmu_rmap_desc_cache,
>rmap_desc_cache, 1);
> if (r)
> goto out;
> r = mmu_topup_memory_cache_page(&vcpu->mmu_page_cache, 8);
> if (r)
> goto out;
> r = mmu_topup_memory_cache(&vcpu->mmu_page_header_cache,
>mmu_page_header_cache, 4);
> out:
> return r;
> }
>   
 These are the (4, 1, 8, 4) values in the call to 
 mmu_topup_memory_cache.  Perhaps one of them is too low.
 
>>> Sure.  Would this be affected at all by your tpr patch?  
>>>   
>> I believe not, but the code doesn't care what I believe.
>>
>> 
>>> IIUC, if this is the problem, it should be reproducible with the 
>>> latest git too?
>>>   
>> One difference is that the tpr patch disables nx.  That causes Windows 
>> to go into 32-bit paging mode (nice that it has both pae and nonpae in 
>> the same kernel), which may change things.
>>
>> You can try booting your host with nx disabled to get the same effect 
>> (or disable nx cpuid in kvm).
>> 
>
> I've disabled NX in KVM and that didn't reproduce the issue in the 
> current git.
>
> If I double all of the memory caches, I can't seem to reproduce.  
> However, as soon as I reduce rmap_desc_cache down to 1, I can reproduce.
>
> I'll try to see if just setting the rmap_desc_cache line to 2 is enough 
> to make the problem go away.
>
> How can the guest provoke this BUG() based on the cache size?  Should 
> the cache size only affect performance?
>
>   

The memory caches are a little misnamed; they're really preallocation 
buffers.

They serve two purposes: to avoid allocation in atomic contexts (that's 
no longer needed since preempt notifiers) and to avoid complex error 
recovery paths.  We make sure there are enough objects to satisfy worst 
case behavior and assume all allocations will work.

Regarding the rmap memory cache failure, I can't think of a reason why 
we'll need to add more than one rmap entry per fault.

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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

[Avi Kivity]

Hollis Blanchard wrote:
> On Fri, 2007-10-26 at 00:12 +0200, Izik Eidus wrote:
>   
>> ok i was thinking,
>> maybe we can rewrite the way kvm hold memory so more code would be shared,
>> lets say we throw away all the slots and arch depended stuff, and we let kvm
>> just hold the userspace allocated memory address,
>> 
>
> With that approach, how would you create a sparse (guest physical)
> memory map in userspace? I guess you would need to use repeated
> mmap(MAP_FIXED), and that's starting to look very brittle.
>
>   

It can't work on i386 due to the limited host virtual address space.

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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] High vm-exit latencies during kvm boot-up/shutdown

[Avi Kivity]

Dong, Eddie wrote:
>> There's a two-liner required to make it work.  I'll add it soon.
>>
>> 
> But you still needs to issue WBINVD to all pCPUs which just move 
> non-response time from one place to another, not?
>   

You don't actually need to emulate wbinvd, you can just ignore it.

The only reason I can think of to use wbinvd is if you're taking a cpu 
down (for a deep sleep state, or if you're shutting it off).  A guest 
need not do that.

Any other reason? dma?  all dma today is cache-coherent, no?

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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

[Carsten Otte]

Avi Kivity wrote:
> Hollis Blanchard wrote:
>> On Fri, 2007-10-26 at 00:12 +0200, Izik Eidus wrote:
>>   
>>> ok i was thinking,
>>> maybe we can rewrite the way kvm hold memory so more code would be shared,
>>> lets say we throw away all the slots and arch depended stuff, and we let kvm
>>> just hold the userspace allocated memory address,
>>> 
>> With that approach, how would you create a sparse (guest physical)
>> memory map in userspace? I guess you would need to use repeated
>> mmap(MAP_FIXED), and that's starting to look very brittle.
>>
>>   
> 
> It can't work on i386 due to the limited host virtual address space.
That's why memory allocation/preparation needs to be arch dependent: 
i386 needs a memory layout different from userspace page table due to 
your argument, and s390 needs to use the userspace page table due to 
hardware features we want to exploit.
As Xiantao pointed out, x86 and ia64 can share the same memory setup 
code. But s390 and ppc don't. Therefore, I vote for putting it into 
x86 for now, and come up with an approach to share between x86 and 
ia64 later on.

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

[Carsten Otte]

Carsten Otte wrote:
> That's why memory allocation/preparation needs to be arch dependent: 
> i386 needs a memory layout different from userspace page table due to 
> your argument, and s390 needs to use the userspace page table due to 
> hardware features we want to exploit.
> As Xiantao pointed out, x86 and ia64 can share the same memory setup 
> code. But s390 and ppc don't. Therefore, I vote for putting it into 
> x86 for now, and come up with an approach to share between x86 and 
> ia64 later on.
After reading Izik's idea: Maybe we should go Izik's way, and have an 
i386 special case that we can deprecate later on?

so long,
Carsten

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] High vm-exit latencies during kvm boot-up/shutdown

[Dong, Eddie]

Avi Kivity wrote:
> Dong, Eddie wrote:
>>> There's a two-liner required to make it work.  I'll add it soon.
>>> 
>>> 
>> But you still needs to issue WBINVD to all pCPUs which just move
>> non-response time from one place to another, not?
>> 
> 
> You don't actually need to emulate wbinvd, you can just ignore it.
> 
> The only reason I can think of to use wbinvd is if you're taking a cpu
> down (for a deep sleep state, or if you're shutting it off).  A guest
> need not do that. 
> 
> Any other reason? dma?  all dma today is cache-coherent, no?
> 
For legacy PCI device, yes it is cache-cohetent, but for PCIe devices,
it is no longer a must. A PCIe device may not generate snoopy cycle
and thus require OS to flush cache.

For example, a guest with direct device, say audio, can copy 
data to dma buffer and then wbinvd to flush cache out and ask HW 
DMA to output.

Thx,Eddie

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

[Dong, Eddie]

Avi Kivity wrote:
> [we can try to improve it by using vm86 interrupt redirection
> which may
> allow event injection using VT instead of writing to the guest stack].
> 
Avi:
I did an investigation to try to find a way if we can deliver
IRQ to guest real mode using VM_ENTRY_INTR_INFO like what
is did in protect mode with minimal changes. It looks like we can't
do that without a VMXassist similar VM86 monitor in guest.

I guess this is too big change for us to solve this small
purpose, right? And it looks like we can still survive with current
approach :-)

thx,eddie

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v2

[Carsten Otte]

Izik Eidus wrote:
> ok i was thinking,
> maybe we can rewrite the way kvm hold memory so more code would be shared,
> lets say we throw away all the slots and arch depended stuff, and we let kvm
> just hold the userspace allocated memory address,
> 
> then we will will have to each arch "arch specific" functions that will 
> map the memory as it will need.
> for example for x86 we will make gfn_to_page map on the fly how the 
> memory should look.
> i think i will write patch to example this, but it might take me some time,
> 
> anyway what do you think about this idea?
I do strongly vote for it. This way, we'd have memory handling common 
over all architectures. For a sane end result of a real portably 
hypervisor, this is very preferable over "have every arch to its own 
thing". After reading your suggestion, I think memory allocation needs 
more engineering work to be done until we find a proper arch split 
then just move it to x86.c. Therefore, I'll modify the patch to leave 
memory handling in common for now. This way, the rest of the patch can 
be picked up for the time being.

so long,
Carsten

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

[Carsten Otte]

Avi Kivity wrote:
> I was talking about x86.
> 
> On x86, you need contiguous userspace, contiguous guest, but again, 
> what's the problem with one memory slot?
There is no problem with one memory slot: it works. It's just that 
Izik's idea gives us the opportunity to have common code for all four 
architectures here.

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [RFT] kvm with Windows optimization

[Avi Kivity]

Gildas wrote:
>>>   
>> Right, installs seem not to like this release, but running an existing
>> VM seems to work fine (mostly).
>> 
>
> A windows 2000 sp4 installation crashes as well (this time with
> WORKER_THREAD_RETURNED_A_BAD_IRQL). This was reproduceable. I've
> restarted the installation with -no-kvm-irq and it seems to work fine
> so long (it didn't crash where it crashed previously).
>   

no-kvm-irq kills the optimization, though.

> I've restarted windows xp install and this time I had the following:
> [86852.991254] [ cut here ]
> [86852.991260] kernel BUG at /home/gl03/sources/tpr-opt-1/kernel/mmu.c:308!
>   



Anthony posted a fix for this (which I don't understand yet).

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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [RFT] kvm with Windows optimization

[Gildas]

2007/10/26, Avi Kivity <[EMAIL PROTECTED]>:
> Gildas wrote:
> > 2007/10/25, Avi Kivity <[EMAIL PROTECTED]>:
> >
> >> This is a request for testing of an experimental kvm feature that
> >> dramatically accelerates some Windows releases (when running with the
> >> ACPI HAL, and especially with guest SMP).  The feature detects accesses
> >> by the guest to the Task Priority Register (TPR) and patches them at
> >> runtime to a kvm-friendly code snipped that is provided by the BIOS.
> >>
> >> The upshot of all that is that
> >> http://kvm.qumranet.com/kvmwiki/Windows_ACPI_Workaround is no longer
> >> required, and Windows SMP no longer runs like a dog; it's quite snappy
> >> from my very limited testing.
> >>
> >> Please download the test release from
> >> http://people.qumranet.com/avi/tpr-opt-1.tar.gz and give it a spin.
> >> Once it has received some exposure, I'll merge it into mainline.
> >>
> >> Credit for the original idea is due to Ben Serebrin.
> >>
> >> --
> >> error compiling committee.c: too many arguments to function
> >>
> >
> > Hi Avi,
> >
> > On an intel machine running 64 bits ubuntu with kernel 2.6.20, using
> > the archive downloaded this morning at 10 o'clock GMT with the
> > following md5sum:
> >
> >
>
> Right, installs seem not to like this release, but running an existing
> VM seems to work fine (mostly).

A windows 2000 sp4 installation crashes as well (this time with
WORKER_THREAD_RETURNED_A_BAD_IRQL). This was reproduceable. I've
restarted the installation with -no-kvm-irq and it seems to work fine
so long (it didn't crash where it crashed previously).

I've restarted windows xp install and this time I had the following:
[86852.991254] [ cut here ]
[86852.991260] kernel BUG at /home/gl03/sources/tpr-opt-1/kernel/mmu.c:308!
[86852.991262] invalid opcode:  [1] SMP
[86852.991265] CPU 1
[86852.991267] Modules linked in: kvm_intel kvm binfmt_misc rfcomm
l2cap bluetooth ppdev i915 drm acpi_cpufreq cpufreq_ondemand
cpufreq_powersave cpufreq_stats freq_table cpufreq_userspace
cpufreq_conservative dev_acpi sony_acpi tc1100_wmi pcc_acpi sbs i2c_ec
i2c_core battery ac video asus_acpi button backlight dock container
ipv6 nls_utf8 ntfs sbp2 lp fuse joydev pcmcia snd_hda_intel
snd_hda_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy
snd_seq_oss snd_seq_midi snd_rawmidi yenta_socket rsrc_nonstatic
pcmcia_core iTCO_wdt iTCO_vendor_support af_packet snd_seq_midi_event
snd_seq ipw3945 tifm_7xx1 parport_pc parport sdhci snd_timer
snd_seq_device pcspkr tpm_infineon tpm tpm_bios serio_raw ieee80211
ieee80211_crypt mmc_core intel_agp psmouse tifm_core snd soundcore
snd_page_alloc shpchp pci_hotplug tsdev evdev sr_mod cdrom generic
ext3 jbd mbcache sg sd_mod ohci1394 ieee1394 ata_piix tg3 ahci
ehci_hcd uhci_hcd usbcore ata_generic libata scsi_mod thermal
processor fan dm_mod fbcon tileblit font bitblit softcursor vesafb
cfbcopyarea cfbimgblt cfbfillrect capability commoncap
[86852.991337] Pid: 12492, comm: qemu-system-x86 Not tainted
2.6.20-16-generic #2
[86852.991340] RIP: 0010:[]  []
:kvm:mmu_memory_cache_alloc+0x7/0x30
[86852.991354] RSP: 0018:810024b039c8  EFLAGS: 00010246
[86852.991356] RAX:  RBX: c282a868 RCX: 810033c54080
[86852.991359] RDX: 810033c54088 RSI: 0028 RDI: 810025232820
[86852.991361] RBP: 810034771750 R08:  R09: 0004
[86852.991363] R10: 145cd963 R11:  R12: 810025232440
[86852.991366] R13:  R14: 810034771750 R15: 810025232440
[86852.991369] FS:  2acc64f8a5b0() GS:81007dbd8ec0()
knlGS:
[86852.991372] CS:  0010 DS: 002b ES: 002b CR0: 8005003b
[86852.991374] CR2: 01001ad8 CR3: 08b86000 CR4: 26e0
[86852.991377] Process qemu-system-x86 (pid: 12492, threadinfo
810024b02000, task 8100713c9820)
[86852.991379] Stack:  c282a868 883aa95c
2a6c6043 0002
[86852.991384]  2a6c6000 883ab2ab 0001
000145cd
[86852.991388]    145cd000
145cd000
[86852.991391] Call Trace:
[86852.991402]  [] :kvm:rmap_add+0xac/0x130
[86852.991414]  [] :kvm:paging32_set_pte_common+0x1fb/0x270
[86852.991434]  [] :kvm:paging32_set_pte+0x49/0x50
[86852.991448]  [] :kvm:kvm_mmu_pte_write+0x273/0x380
[86852.991472]  []
:kvm:emulator_write_emulated_onepage+0x85/0x100
[86852.991485]  [] :kvm:x86_emulate_insn+0x2b9a/0x4200
[86852.991497]  [] :kvm_intel:vmcs_readl+0x17/0x20
[86852.991512]  [] :kvm:emulate_instruction+0x174/0x2d0
[86852.991524]  [] :kvm_intel:handle_exception+0x18f/0x290
[86852.991532]  [] :kvm:apic_update_ppr+0x29/0x60
[86852.991546]  [] :kvm:kvm_vcpu_ioctl+0x411/0x1120
[86852.991553]  [] __activate_task+0x38/0x60
[86852.991560]  [] try_to_wake_up+0x3dc/0x400
[86852.991577]  [] __wake_up_common+0x44/0x80
[86852.991587]  [] __wake_up+0x43/0x70
[86852.991598]  [] cor

Re: [kvm-devel] FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

[Dong, Eddie]

>-Original Message-
>From: Avi Kivity [mailto:[EMAIL PROTECTED] 
>Sent: 2007年10月26日 18:14
>To: Dong, Eddie
>Cc: kvm-devel@lists.sourceforge.net
>Subject: Re: [kvm-devel] FW: [kvm-commits] KVM: Move interrupt 
>injection out of interruptdisabled section
>
>Dong, Eddie wrote:
>>> I didn't see anything in 20.8.3 regarding injection of software
>>> interrupts to vm86 mode.  And other sections in the manual (22.5.1)
>>> imply that it is possible. 
>>>
>>> Maybe it's failing on something else?  VM-entry instruction 
>length?  I
>>> see that it must be in the range 1-15.
>>>
>>> 
>> It is VM instruction failure with error # 7, which means bad 
>VM control.
>> Also one difference for software interrupt is that HW will 
>adjust guest 
>> IP automatically. 
>>   
>
>So you could set instruction length to 1 and adjust rip 
>backwards by 1 :)
>
>Though you may need to remember the adjustment and undo it if 
>you get a 
>page fault on the IVT.
>
>
What I mean is HW implicitly take SW interrupt as what it should be.
And check exception #.

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

[Avi Kivity]

Dong, Eddie wrote:
>> I didn't see anything in 20.8.3 regarding injection of software
>> interrupts to vm86 mode.  And other sections in the manual (22.5.1)
>> imply that it is possible. 
>>
>> Maybe it's failing on something else?  VM-entry instruction length?  I
>> see that it must be in the range 1-15.
>>
>> 
> It is VM instruction failure with error # 7, which means bad VM control.
> Also one difference for software interrupt is that HW will adjust guest 
> IP automatically. 
>   

So you could set instruction length to 1 and adjust rip backwards by 1 :)

Though you may need to remember the adjustment and undo it if you get a 
page fault on the IVT.


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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

[Dong, Eddie]

> 
> I didn't see anything in 20.8.3 regarding injection of software
> interrupts to vm86 mode.  And other sections in the manual (22.5.1)
> imply that it is possible. 
> 
> Maybe it's failing on something else?  VM-entry instruction length?  I
> see that it must be in the range 1-15.
> 
It is VM instruction failure with error # 7, which means bad VM control.
Also one difference for software interrupt is that HW will adjust guest 
IP automatically. 
Eddie

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [RFT] kvm with Windows optimization

[Avi Kivity]

Dong, Eddie wrote:
>>>
>>>   
>> Thanks for the hint; I'll add that.  I think Vista hits the tpr much
>> less frequently, so it can work well without the optimization.
>>
>> 
> Curious: How do u know ROM is mapped 0xf in Windows?
> Eddie
>
>
> kvm_get_sregs(kvm_context, env->cpu_index, &sregs);
>
> probe = (rip & 0xf000) + 0xe;
> phys = map_addr(&sregs, probe, &perms);
> if (phys != 0xe)
>   return 0;
> printf("bios ok at %lx\n", (long)probe);
>   

I checked :)

It's actually not mapped at 0xf000.  On normal Windows XP it is 
mapped at 0x8000, with /3GB it is mapped at 0xe000.  The code 
checks it is within the same 256MB segment as the code that's hitting 
tpr.  It could probably be improved.

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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

[Avi Kivity]

Dong, Eddie wrote:
> Avi Kivity wrote:
>   
>> Dong, Eddie wrote:
>> 
>>> Avi Kivity wrote:
>>>
>>>   
 [we can try to improve it by using vm86 interrupt redirection which
 may allow event injection using VT instead of writing to the guest
 stack]. 


 
>>> Avi:
>>> I did an investigation to try to find a way if we can deliver
>>> IRQ to guest real mode using VM_ENTRY_INTR_INFO like what
>>> is did in protect mode with minimal changes. It looks like we can't
>>> do that without a VMXassist similar VM86 monitor in guest.
>>>
>>>
>>>   
>> Can you explain why a monitor is needed?  I thought of using the VME
>> interrupt redirection bitmap, does this approach not work?
>> 
>
> Yes I think so at beginning. But then I realized there are tricky:
> VMX will restore guest state first and then inject HW IRQ if there is.
> (SDM 22.5)
>
> SDM 3 16.3 & 16.3.1.1 says the processor will switch to protect mode
> exception interrupt & exception handler instead of 8086 program IVT
> which we want in this case, where the VM86 monitor resides:-(
>
> Only software interrupt can let processor directly refer IVT per 
> manual 16.3.1.1 & 22.5. So I tried to inject a software interrupt 
> for guest external interrupt, but it violatesSDM 20.8.3 and 
> VM Resume fails. 
>
>   

I didn't see anything in 20.8.3 regarding injection of software 
interrupts to vm86 mode.  And other sections in the manual (22.5.1) 
imply that it is possible.

Maybe it's failing on something else?  VM-entry instruction length?  I 
see that it must be in the range 1-15.

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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [RFT] kvm with Windows optimization

[Gildas]

2007/10/25, Avi Kivity <[EMAIL PROTECTED]>:
> This is a request for testing of an experimental kvm feature that
> dramatically accelerates some Windows releases (when running with the
> ACPI HAL, and especially with guest SMP).  The feature detects accesses
> by the guest to the Task Priority Register (TPR) and patches them at
> runtime to a kvm-friendly code snipped that is provided by the BIOS.
>
> The upshot of all that is that
> http://kvm.qumranet.com/kvmwiki/Windows_ACPI_Workaround is no longer
> required, and Windows SMP no longer runs like a dog; it's quite snappy
> from my very limited testing.
>
> Please download the test release from
> http://people.qumranet.com/avi/tpr-opt-1.tar.gz and give it a spin.
> Once it has received some exposure, I'll merge it into mainline.
>
> Credit for the original idea is due to Ben Serebrin.
>
> --
> error compiling committee.c: too many arguments to function

Hi Avi,

On an intel machine running 64 bits ubuntu with kernel 2.6.20, using
the archive downloaded this morning at 10 o'clock GMT with the
following md5sum:

6a793d217a067ede35b41684395446e9  ../sources/tpr-opt-1.tar.gz

I tried to install windows xp sp2 with the following command line:
qemu-system-x86_64 -smp 2 -m 1024 -hda /dev/vg1/winxp -cdrom
/home/gl03/iso/xpsp2_install_cd.iso

First part of the install goes fine but after the reboot it BSOD with
DRIVER_IRQL_NOT_LESS_OR_EQUAL (see snapshot included).

Latest lines of dmesg:

[83827.197075] Fault when IDT_Vectoring
[83827.209680] Fault when IDT_Vectoring
[83827.209733] Fault when IDT_Vectoring
[83827.769998] Fault when IDT_Vectoring
[83827.770056] Fault when IDT_Vectoring
[83828.703089] Fault when IDT_Vectoring
[83828.705896] Fault when IDT_Vectoring
[83828.710527] Fault when IDT_Vectoring
[83828.718736] Fault when IDT_Vectoring
[83828.747251] Fault when IDT_Vectoring
[83828.774862] Fault when IDT_Vectoring
[83830.262231] Fault when IDT_Vectoring
[83838.101244] Fault when IDT_Vectoring
[83841.053300] Fault when IDT_Vectoring
[83841.053359] Fault when IDT_Vectoring
[83858.432652] Fault when IDT_Vectoring
[83858.432693] Fault when IDT_Vectoring

Latest lines in the console:

check insn
rip: 807033de
insn: c7 05
instruction ok at 807033e4 tpr fffe0080
check bios
bios ok at 800e
vapic_phys e2000
patching insn at 807033de
insn: c7 05
patched code: 807033de 68 41 00 00 00 e8 fc dc 9d ff
check insn
rip: 80703b39
insn: 8b 0d
instruction ok at 80703b3f tpr fffe0080
check bios
bios ok at 800e
vapic_phys e2000
patching insn at 80703b39
insn: 8b 0d
patched code: 80703b39 90 e8 71 d5 9d ff a3 80 00 fe
check insn
rip: 80703b3f
insn: a3 80
instruction ok at 80703b44 tpr fffe0080
check bios
bios ok at 800e
vapic_phys e2000
patching insn at 80703b3f
insn: a3 80
patched code: 80703b3f e8 99 d5 9d ff 9d 83 c4 08 c1
check insn
rip: 807039cc
insn: 89 0d
instruction ok at 807039d2 tpr fffe0080
check bios
bios ok at 800e
vapic_phys e2000
patching insn at 807039cc
insn: 89 0d
patched code: 807039cc 51 e8 12 d7 9d ff a1 80 00 fe
check insn
rip: 807039d2
insn: a1 80
instruction ok at 807039d7 tpr fffe0080
check bios
bios ok at 800e
vapic_phys e2000
patching insn at 807039d2
insn: a1 80
patched code: 807039d2 e8 a9 d6 9d ff 33 c0 f3 90 c3

Regards,
Gildas
<>-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [RFT] kvm with Windows optimization

[Dong, Eddie]

Avi Kivity wrote:
> Dong, Eddie wrote:
>>> BTW, is it wise to enable this by default for all guests?
>>> Ignoring the
>>> fact that we're modifying guest's memory without its knowledge, if a
>>> guest unmaps the VA mappings for the BIOS then all sorts of
>>> problems could occur. 
>>> 
>>> 
>> Good movement!
>> 
>> But, Vista won't work with patching. The memory guard in vista
>> will make the system refuse to service. Maybe we need a option to
>> check if it is vista. 
>> 
>> 
> 
> Thanks for the hint; I'll add that.  I think Vista hits the tpr much
> less frequently, so it can work well without the optimization.
> 
Curious: How do u know ROM is mapped 0xf in Windows?
Eddie


kvm_get_sregs(kvm_context, env->cpu_index, &sregs);

probe = (rip & 0xf000) + 0xe;
phys = map_addr(&sregs, probe, &perms);
if (phys != 0xe)
return 0;
printf("bios ok at %lx\n", (long)probe);

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] High vm-exit latencies during kvm boot-up/shutdown

[Dong, Eddie]

Avi Kivity wrote:
> Dong, Eddie wrote:
>> Avi Kivity wrote:
>> 
>>> Dong, Eddie wrote:
>>> 
> There's a two-liner required to make it work.  I'll add it soon.
> 
> 
> 
 But you still needs to issue WBINVD to all pCPUs which just move
 non-response time from one place to another, not?
 
 
>>> You don't actually need to emulate wbinvd, you can just ignore it.
>>> 
>>> The only reason I can think of to use wbinvd is if you're taking a
>>> cpu down (for a deep sleep state, or if you're shutting it off).  A
>>> guest need not do that. 
>>> 
>>> Any other reason? dma?  all dma today is cache-coherent, no?
>>> 
>>> 
>> For legacy PCI device, yes it is cache-cohetent, but for PCIe
>> devices, it is no longer a must. A PCIe device may not generate
>> snoopy cycle and thus require OS to flush cache.
>> 
>> For example, a guest with direct device, say audio, can copy
>> data to dma buffer and then wbinvd to flush cache out and ask HW DMA
>> to output. 
>> 
> 
> Okay.  In that case the host can emulate wbinvd by using the clflush
> instruction, which is much faster (although overall execution time may
> be higher), maintaining real-time response times.

Faster? maybe.
The issue is clflush take va parameter. So KVM needs to map gpa first
and
then do flush.

WIth this additional overhead. I am not sure which one is faster. But
yes,
this is the trend we may walk toward to reduce Deny of Service. 
(flush host or other VM's cache will slowdown whole system).

Eddie

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] High vm-exit latencies during kvm boot-up/shutdown

[Dor Laor]

Dong, Eddie wrote:
>
> Jan Kiszka wrote:
> >
> > So if you want the higher performance of PCIe you need
> > performance-killing wbindv (not to speak of latency)? That sounds a
> > bit contradictory to me. So this is also true for native PCIe usage?
> >
>
> Mmm, I won't say so. When you want to get RT performance, you
> won't use unknown OS such as Windows. If you use your RT
> linux, the OS (guest) itself should not use wbinvd.
>
The idea is to have a RT-Linux on the host that runs RT jobs but also
use it to run mgmt/other code on windows guests.
This way you can better utilize an idle RT linux while keeping
short latencies for the RT jobs.
Dor.
>
> For the Bochs BIOS case, like Avi mentioned, we can simply remove it.
>
>
> > What really frightens me about wbinvd is that its latency "nicely"
> > scales with the cache sizes. And I think my observed latency
> > is far from
> > being the worst case. In a different experiment, I once measured
> > wbinvd latencies of a few milliseconds... :(
> >
> I don't know details, but it could be. While RT usage can easily remove
> this instruction.
>
> thx,eddie
>
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> ___
> kvm-devel mailing list
> kvm-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] wbinvd

[Andi Kleen]

[no direct reply because gmane still breaks it]

WBINVD or CLFLUSH is also needed to safely change caching attributes
of pages that are already mapped. Since CLFLUSH is somewhat hard to use 
for this near all Linux kernels use WBINVD for this. Examples where this 
happens are  ioremap() using PAT, AGP allocations, 3d drivers.

For the PCI-E case typically CLFLUSH can be used instead of WBINVD too 
(on CPUs that support it) but again it's harder to use.

Another case where the kernel uses it is reboot but there you can
likely ignore it. But might be hard to distingush from legitimate
cases.

If you allow uncached pages in guests it is probably not safe to nop
completely (on SVM). You might be able to emulate it by doing CLFLUSH
on all guest mappings or rather on all mappings that alias an uncached
mapping. That might be even slower than wbinvd though, but should be
at least potentially preemptible.

-Andi

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

[Dong, Eddie]

Avi Kivity wrote:
> Dong, Eddie wrote:
>> Avi Kivity wrote:
>> 
>>> [we can try to improve it by using vm86 interrupt redirection which
>>> may allow event injection using VT instead of writing to the guest
>>> stack]. 
>>> 
>>> 
>> Avi:
>>  I did an investigation to try to find a way if we can deliver
>> IRQ to guest real mode using VM_ENTRY_INTR_INFO like what
>> is did in protect mode with minimal changes. It looks like we can't
>> do that without a VMXassist similar VM86 monitor in guest.
>> 
>> 
> 
> Can you explain why a monitor is needed?  I thought of using the VME
> interrupt redirection bitmap, does this approach not work?

Yes I think so at beginning. But then I realized there are tricky:
VMX will restore guest state first and then inject HW IRQ if there is.
(SDM 22.5)

SDM 3 16.3 & 16.3.1.1 says the processor will switch to protect mode
exception interrupt & exception handler instead of 8086 program IVT
which we want in this case, where the VM86 monitor resides:-(

Only software interrupt can let processor directly refer IVT per 
manual 16.3.1.1 & 22.5. So I tried to inject a software interrupt 
for guest external interrupt, but it violatesSDM 20.8.3 and 
VM Resume fails. 

This could be one of the major reason why Xen implemented a VMXAssist.

> 
>>  I guess this is too big change for us to solve this small
>> purpose, right? And it looks like we can still survive with current
>> approach :-) 
>> 
>> 
> 
> Yes, but I rather liked the reduction in code and simplification from
> eliminating the special case for injecting real mode interrupts.

Yes, I wanna too :-)

Eddie

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH 1/2]KVM: x86_emulator: Decode the memory operand for 'mov'

[Yang, Sheng]

>From 3ceb677ffee889880020d8ccb6b9f2c5bfb05644 Mon Sep 17 00:00:00 2001
From: Sheng Yang <[EMAIL PROTECTED]>
Date: Fri, 26 Oct 2007 17:15:36 +0800
Subject: [PATCH 1/2] KVM: x86_emulator: Decode the memory operand for
'mov'

For the following TPR patch, we must get gva for executing instructions.
Most
memory operands are decoded in ModR/M part, except some kinds of 'mov'.
This
patch decoded the memory operand for these 'mov' instructions, instead
of using
CR2.

Signed-off-by: Sheng Yang <[EMAIL PROTECTED]>
---
 drivers/kvm/x86_emulate.c |   11 +++
 1 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index f858c01..5f6a40c 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -837,6 +837,9 @@ modrm_done:
&& c->modrm_reg == 7)
break;
  srcmem_common:
+   /* Decode memory operand for mov(0xa0 ... 0xa1)*/
+   if ((c->b == 0xa0) || (c->b == 0xa1))
+   ctxt->cr2 = insn_fetch(u32, c->src.bytes,
c->eip);
/*
 * For instructions with a ModR/M byte, switch to
register
 * access if Mod = 3.
@@ -906,6 +909,7 @@ modrm_done:
}
break;
case DstMem:
+   c->dst.bytes = (c->d & ByteOp) ? 1 : c->op_bytes;
/*
 * For instructions with a ModR/M byte, switch to
register
 * access if Mod = 3.
@@ -914,6 +918,9 @@ modrm_done:
c->dst.type = OP_REG;
else
c->dst.type = OP_MEM;
+   /* Decode memory operand for mov(0xa2 ... 0xa3)*/
+   if ((c->b == 0xa2) || (c->b == 0xa3))
+   ctxt->cr2 = insn_fetch(u32, c->dst.bytes,
c->eip);
break;
}
 
@@ -1337,13 +1344,9 @@ x86_emulate_insn(struct x86_emulate_ctxt *ctxt,
struct x86_emulate_ops *ops)
case 0xa0 ... 0xa1: /* mov */
c->dst.ptr = (unsigned long *)&c->regs[VCPU_REGS_RAX];
c->dst.val = c->src.val;
-   /* skip src displacement */
-   c->eip += c->ad_bytes;
break;
case 0xa2 ... 0xa3: /* mov */
c->dst.val = (unsigned long)c->regs[VCPU_REGS_RAX];
-   /* skip c->dst displacement */
-   c->eip += c->ad_bytes;
break;
case 0xc0 ... 0xc1:
emulate_grp2(ctxt);
-- 
1.5.2


0001-KVM-x86_emulator-Decode-the-memory-operand-for-mo.patch
Description: 0001-KVM-x86_emulator-Decode-the-memory-operand-for-mo.patch
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] High vm-exit latencies during kvm boot-up/shutdown

[Avi Kivity]

Jan Kiszka wrote:
> Dong, Eddie wrote:
>   
>> Avi Kivity wrote:
>> 
>>> Dong, Eddie wrote:
>>>   
> There's a two-liner required to make it work.  I'll add it soon.
>
>
>   
 But you still needs to issue WBINVD to all pCPUs which just move
 non-response time from one place to another, not?

 
>>> You don't actually need to emulate wbinvd, you can just ignore it.
>>>
>>> The only reason I can think of to use wbinvd is if you're taking a cpu
>>> down (for a deep sleep state, or if you're shutting it off).  A guest
>>> need not do that. 
>>>
>>> Any other reason? dma?  all dma today is cache-coherent, no?
>>>
>>>   
>> For legacy PCI device, yes it is cache-cohetent, but for PCIe devices,
>> it is no longer a must. A PCIe device may not generate snoopy cycle
>> and thus require OS to flush cache.
>>
>> For example, a guest with direct device, say audio, can copy 
>> data to dma buffer and then wbinvd to flush cache out and ask HW 
>> DMA to output.
>> 
>
> So if you want the higher performance of PCIe you need
> performance-killing wbindv (not to speak of latency)? That sounds a bit
> contradictory to me. So this is also true for native PCIe usage?
>
>   

Yes, good point.  wbinvd is not only expensive in that it takes a long 
time to execute, it blows your caches so that anything that executes 
afterwards takes a huge hit.


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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

[Avi Kivity]

Carsten Otte wrote:
> Carsten Otte wrote:
>   
>> That's why memory allocation/preparation needs to be arch dependent: 
>> i386 needs a memory layout different from userspace page table due to 
>> your argument, and s390 needs to use the userspace page table due to 
>> hardware features we want to exploit.
>> As Xiantao pointed out, x86 and ia64 can share the same memory setup 
>> code. But s390 and ppc don't. Therefore, I vote for putting it into 
>> x86 for now, and come up with an approach to share between x86 and 
>> ia64 later on.
>> 
> After reading Izik's idea: Maybe we should go Izik's way, and have an 
> i386 special case that we can deprecate later on?
>
>   

I don't really see a big difference between what we have now (sparse 
userspace, sparse guest) and Izik's idea (contiguous userspace, sparse 
guest).  In both cases you need something like memory slots to describe 
the different sections.

Moreover, on x86 you may want different properties for different 
sections (4K pages for the framebuffer, large pages for main memory), so 
you can't allocate memory in one big chunk.

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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] High vm-exit latencies during kvm boot-up/shutdown

[Avi Kivity]

Dong, Eddie wrote:
> Avi Kivity wrote:
>   
>> Dong, Eddie wrote:
>> 
 There's a two-liner required to make it work.  I'll add it soon.


 
>>> But you still needs to issue WBINVD to all pCPUs which just move
>>> non-response time from one place to another, not?
>>>
>>>   
>> You don't actually need to emulate wbinvd, you can just ignore it.
>>
>> The only reason I can think of to use wbinvd is if you're taking a cpu
>> down (for a deep sleep state, or if you're shutting it off).  A guest
>> need not do that. 
>>
>> Any other reason? dma?  all dma today is cache-coherent, no?
>>
>> 
> For legacy PCI device, yes it is cache-cohetent, but for PCIe devices,
> it is no longer a must. A PCIe device may not generate snoopy cycle
> and thus require OS to flush cache.
>
> For example, a guest with direct device, say audio, can copy 
> data to dma buffer and then wbinvd to flush cache out and ask HW 
> DMA to output.
>   

Okay.  In that case the host can emulate wbinvd by using the clflush 
instruction, which is much faster (although overall execution time may 
be higher), maintaining real-time response times.

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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] High vm-exit latencies during kvm boot-up/shutdown

[Dong, Eddie]

Jan Kiszka wrote:
> 
> So if you want the higher performance of PCIe you need
> performance-killing wbindv (not to speak of latency)? That sounds a
> bit contradictory to me. So this is also true for native PCIe usage?
> 

Mmm, I won't say so. When you want to get RT performance, you
won't use unknown OS such as Windows. If you use your RT
linux, the OS (guest) itself should not use wbinvd.

For the Bochs BIOS case, like Avi mentioned, we can simply remove it.


> What really frightens me about wbinvd is that its latency "nicely"
> scales with the cache sizes. And I think my observed latency
> is far from
> being the worst case. In a different experiment, I once measured
> wbinvd latencies of a few milliseconds... :(
> 
I don't know details, but it could be. While RT usage can easily remove
this instruction.

thx,eddie

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

[Avi Kivity]

Dong, Eddie wrote:
> Avi Kivity wrote:
>   
>> [we can try to improve it by using vm86 interrupt redirection
>> which may
>> allow event injection using VT instead of writing to the guest stack].
>>
>> 
> Avi:
>   I did an investigation to try to find a way if we can deliver
> IRQ to guest real mode using VM_ENTRY_INTR_INFO like what
> is did in protect mode with minimal changes. It looks like we can't
> do that without a VMXassist similar VM86 monitor in guest.
>
>   

Can you explain why a monitor is needed?  I thought of using the VME 
interrupt redirection bitmap, does this approach not work?

>   I guess this is too big change for us to solve this small
> purpose, right? And it looks like we can still survive with current
> approach :-)
>
>   

Yes, but I rather liked the reduction in code and simplification from 
eliminating the special case for injecting real mode interrupts.

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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] compile kvm on fc6

[Avi Kivity]

Zhao, Yunfeng wrote:
> Kvm cannot be compiled on fc6 which doesn't define CONFIG_HAS_IOMEM.
>
>   

I added a fix in kernel/external-module-compat.h.  Should work now.


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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [RFT] kvm with Windows optimization

[Avi Kivity]

Dong, Eddie wrote:
>> BTW, is it wise to enable this by default for all guests?
>> Ignoring the
>> fact that we're modifying guest's memory without its knowledge, if a
>> guest unmaps the VA mappings for the BIOS then all sorts of problems
>> could occur. 
>>
>> 
> Good movement!
>
> But, Vista won't work with patching. The memory guard in vista 
> will make the system refuse to service. Maybe we need a option
> to check if it is vista.
>
>   

Thanks for the hint; I'll add that.  I think Vista hits the tpr much 
less frequently, so it can work well without the optimization.


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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] somthing new for shared memory???

[Carsten Otte]

Izik Eidus wrote:
> beside moving the memory allocation to userspace (this is first step in 
> share memory between VMs using smart file system)
> there is not much advance.
> 
> about sharing memory between VM and host, we improved it by adding 
> partial swapping support,
> so the host can take memory from the guest in demand.
Oooh shared memory :-), my old passion before I started on kvm.
We've put a very nice infrastructure for that into the kernel which I 
would like to advertise here: We have arch/s390/mm/extmem.c, which 
implements primitives like segment_load, segment_unload etc. Sysfs 
attributes, and a kernel parameter are used to configure what segments 
are to be used.
On top of that, we have drivers/s390/dcssblk.c, a block driver for 
shared memory segments that provides an extra block device operation 
direct_access() which hands out a page pointer to a specific disk block.
Furthermore, we modified the memory management (mm/filemap_xip.c) and 
the ext2 file system (fs/ext2/xip.c) to support a new address space 
operation get_xip_page(), which is used by ext2 to fullfill all file 
operations.
The beauty of this solution comes with the execute in place effect. 
Binary executable files and libraries (glibc is a very good candidate) 
can be used by multiple user programs on multiple guests, while being 
present in host memory only once. For that, ext2 needs to be mounted 
read only on a shared memory segment with -o xip. And target binaries 
and libraries need to be installed on that file system. The rest is 
transparent to userland.
We also played with writable shared memory between user programs on 
different guests, but did'nt find a good use for that. A prototype 
2.6. driver that provides it on top of extmem.c segment_* functions 
can be found here:
http://www.ussg.iu.edu/hypermail/linux/kernel/0412.3/0617.html

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

[Avi Kivity]

Carsten Otte wrote:
> Avi Kivity wrote:
>   
>> Hollis Blanchard wrote:
>> 
>>> On Fri, 2007-10-26 at 00:12 +0200, Izik Eidus wrote:
>>>   
>>>   
 ok i was thinking,
 maybe we can rewrite the way kvm hold memory so more code would be shared,
 lets say we throw away all the slots and arch depended stuff, and we let 
 kvm
 just hold the userspace allocated memory address,
 
 
>>> With that approach, how would you create a sparse (guest physical)
>>> memory map in userspace? I guess you would need to use repeated
>>> mmap(MAP_FIXED), and that's starting to look very brittle.
>>>
>>>   
>>>   
>> It can't work on i386 due to the limited host virtual address space.
>> 
> That's why memory allocation/preparation needs to be arch dependent: 
> i386 needs a memory layout different from userspace page table due to 
> your argument, and s390 needs to use the userspace page table due to 
> hardware features we want to exploit.
> As Xiantao pointed out, x86 and ia64 can share the same memory setup 
> code. But s390 and ppc don't. Therefore, I vote for putting it into 
> x86 for now, and come up with an approach to share between x86 and 
> ia64 later on.
>   

But can't s390 and ppc use a subset?  If you limit the number of memory 
slots to one, it's equivalent to base + limit.

No?

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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH 1/2]KVM: x86_emulator: Decode the memory operand for 'mov'

[Yang, Sheng]

Avi Kivity wrote:
> Yang, Sheng wrote:
>>> From ebfc23b71051e5ab19d22fb3f9c3d57721566ea9 Mon Sep 17 00:00:00
2001
>> From: Sheng Yang <[EMAIL PROTECTED]>
>> Date: Fri, 26 Oct 2007 13:41:28 +0800
>> Subject: [PATCH] KVM: x86_emulator: Decode the memory operand for
'mov'
>> 
>> For the following TPR patch, we must get gva for executing
instructions.
>> Most memory operands are decoded in ModR/M part, except some kinds of
>> 'mov'. This patch decoded the memory operand for these 'mov'
instructions,
>> instead of using CR2.
>> 
>> Signed-off-by: Sheng Yang <[EMAIL PROTECTED]>
>> ---
>>  drivers/kvm/x86_emulate.c |   11 +++
>>  1 files changed, 11 insertions(+), 0 deletions(-)
>> 
>> diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index
>> f858c01..f75f75a 100644 --- a/drivers/kvm/x86_emulate.c
>> +++ b/drivers/kvm/x86_emulate.c
>> @@ -837,6 +837,11 @@ modrm_done:
>>  && c->modrm_reg == 7)
>>  break;
>>srcmem_common:
>> +/* Decode memory operand for mov(0xa0 ... 0xa1)*/
>> +if ((c->b == 0xa0) || (c->b == 0xa1)) {
>> +ctxt->cr2 = insn_fetch(u32, c->src.bytes,
>> c->eip);
>> +c->eip -= c->src.bytes;
>> +}
>> 
> 
> We're moving eip backwards here, then forwards in
x86_emulate_insn()...
> I'm getting dizzy.
> 
> How about add a MemAbs bitflag in decode it outside, similar to the
> ModRM flag and decoding?

Oops...

In current condition, no eip move required. I will remove these
movement...

Thanks
Yang, Sheng

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH 1/2]KVM: x86_emulator: Decode the memory operand for 'mov'

[Avi Kivity]

Yang, Sheng wrote:
> >From ebfc23b71051e5ab19d22fb3f9c3d57721566ea9 Mon Sep 17 00:00:00 2001
> From: Sheng Yang <[EMAIL PROTECTED]>
> Date: Fri, 26 Oct 2007 13:41:28 +0800
> Subject: [PATCH] KVM: x86_emulator: Decode the memory operand for 'mov'
>
> For the following TPR patch, we must get gva for executing instructions.
> Most
> memory operands are decoded in ModR/M part, except some kinds of 'mov'.
> This
> patch decoded the memory operand for these 'mov' instructions, instead
> of using
> CR2.
>
> Signed-off-by: Sheng Yang <[EMAIL PROTECTED]>
> ---
>  drivers/kvm/x86_emulate.c |   11 +++
>  1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
> index f858c01..f75f75a 100644
> --- a/drivers/kvm/x86_emulate.c
> +++ b/drivers/kvm/x86_emulate.c
> @@ -837,6 +837,11 @@ modrm_done:
>   && c->modrm_reg == 7)
>   break;
> srcmem_common:
> + /* Decode memory operand for mov(0xa0 ... 0xa1)*/
> + if ((c->b == 0xa0) || (c->b == 0xa1)) {
> + ctxt->cr2 = insn_fetch(u32, c->src.bytes,
> c->eip);
> + c->eip -= c->src.bytes;
> + }
>   

We're moving eip backwards here, then forwards in x86_emulate_insn()... 
I'm getting dizzy.

How about add a MemAbs bitflag in decode it outside, similar to the 
ModRM flag and decoding?


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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] High vm-exit latencies during kvm boot-up/shutdown

[Jan Kiszka]

Dong, Eddie wrote:
> Avi Kivity wrote:
>> Dong, Eddie wrote:
 There's a two-liner required to make it work.  I'll add it soon.


>>> But you still needs to issue WBINVD to all pCPUs which just move
>>> non-response time from one place to another, not?
>>>
>> You don't actually need to emulate wbinvd, you can just ignore it.
>>
>> The only reason I can think of to use wbinvd is if you're taking a cpu
>> down (for a deep sleep state, or if you're shutting it off).  A guest
>> need not do that. 
>>
>> Any other reason? dma?  all dma today is cache-coherent, no?
>>
> For legacy PCI device, yes it is cache-cohetent, but for PCIe devices,
> it is no longer a must. A PCIe device may not generate snoopy cycle
> and thus require OS to flush cache.
> 
> For example, a guest with direct device, say audio, can copy 
> data to dma buffer and then wbinvd to flush cache out and ask HW 
> DMA to output.

So if you want the higher performance of PCIe you need
performance-killing wbindv (not to speak of latency)? That sounds a bit
contradictory to me. So this is also true for native PCIe usage?

What really frightens me about wbinvd is that its latency "nicely"
scales with the cache sizes. And I think my observed latency is far from
being the worst case. In a different experiment, I once measured wbinvd
latencies of a few milliseconds... :(

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH] kvm-userspace: Make tests compile on x86_64

[Laurent Vivier]

These modification are needed to allow me to compile kvm-userspace
on my x86_64 system.

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
 user/config-x86-common.mak |2 +-
 user/config-x86_64.mak |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/user/config-x86-common.mak b/user/config-x86-common.mak
index c4eb034..3230311 100644
--- a/user/config-x86-common.mak
+++ b/user/config-x86-common.mak
@@ -19,7 +19,7 @@ $(TEST_DIR)/%.o: CFLAGS += -std=gnu99 -ffreestanding
 $(TEST_DIR)/bootstrap: $(TEST_DIR)/bootstrap.o
$(CC) -nostdlib -o $@ -Wl,-T,bootstrap.lds $^
  
-$(TEST_DIR)/irq.flat: $(TEST_DIR)/test/print.o
+$(TEST_DIR)/irq.flat: $(TEST_DIR)/print.o
  
 $(TEST_DIR)/access.flat: $(cstart.o) $(TEST_DIR)/access.o \
$(TEST_DIR)/printf.o $(TEST_DIR)/print.o $(TEST_DIR)/smp.o
diff --git a/user/config-x86_64.mak b/user/config-x86_64.mak
index 6edcdc9..09501d8 100644
--- a/user/config-x86_64.mak
+++ b/user/config-x86_64.mak
@@ -7,6 +7,6 @@ CFLAGS += -m64
 CFLAGS += -D__x86_64__
 CFLAGS += -I $(KERNELDIR)/include
 
-tests = test/access.flat test/irq.flat test/sieve.flat test/simple.flat 
test/stringio.flat test/memtest1.flat
+tests = $(TEST_DIR)/access.flat $(TEST_DIR)/irq.flat $(TEST_DIR)/sieve.flat 
$(TEST_DIR)/simple.flat $(TEST_DIR)/stringio.flat $(TEST_DIR)/memtest1.flat
 
 include config-x86-common.mak
-- 
1.5.2.4


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] High vm-exit latencies during kvm boot-up/shutdown

[Avi Kivity]

Dong, Eddie wrote:
>>>   
>> Okay.  In that case the host can emulate wbinvd by using the clflush
>> instruction, which is much faster (although overall execution time may
>> be higher), maintaining real-time response times.
>> 
>
> Faster? maybe.
> The issue is clflush take va parameter. So KVM needs to map gpa first
> and
> then do flush.
>
> WIth this additional overhead. I am not sure which one is faster. But
> yes,
> this is the trend we may walk toward to reduce Deny of Service. 
> (flush host or other VM's cache will slowdown whole system).
>   

The issue is not total time to execute (wbinvd is probably faster), but 
the time where interrupts are blocked.  wbinvd can block interrupts for 
milliseconds, and if your industrial control machine needs service every 
100 microsecond, something breaks.

[Background: this is for running Linux with realtime extensions as host, 
with realtime processes on the host doing the control tasks and a guest 
doing the GUI and perhaps communications.]


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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [RFT] kvm with Windows optimization

[Avi Kivity]

Gildas wrote:
> 2007/10/25, Avi Kivity <[EMAIL PROTECTED]>:
>   
>> This is a request for testing of an experimental kvm feature that
>> dramatically accelerates some Windows releases (when running with the
>> ACPI HAL, and especially with guest SMP).  The feature detects accesses
>> by the guest to the Task Priority Register (TPR) and patches them at
>> runtime to a kvm-friendly code snipped that is provided by the BIOS.
>>
>> The upshot of all that is that
>> http://kvm.qumranet.com/kvmwiki/Windows_ACPI_Workaround is no longer
>> required, and Windows SMP no longer runs like a dog; it's quite snappy
>> from my very limited testing.
>>
>> Please download the test release from
>> http://people.qumranet.com/avi/tpr-opt-1.tar.gz and give it a spin.
>> Once it has received some exposure, I'll merge it into mainline.
>>
>> Credit for the original idea is due to Ben Serebrin.
>>
>> --
>> error compiling committee.c: too many arguments to function
>> 
>
> Hi Avi,
>
> On an intel machine running 64 bits ubuntu with kernel 2.6.20, using
> the archive downloaded this morning at 10 o'clock GMT with the
> following md5sum:
>
>   

Right, installs seem not to like this release, but running an existing 
VM seems to work fine (mostly).


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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [RFT] kvm with Windows optimization

[Avi Kivity]

Avi Kivity wrote:

Jindrich Makovicka wrote:
  

On Thu, 25 Oct 2007 13:39:33 -0400
"Haydn Solomon" <[EMAIL PROTECTED]> wrote:

  


Thanks, that was quick.

  

Finally, this (pre)release solved the long standing Java IE Plugin
lockup problem for me. Thanks a lot!

  



No, this release is meant to cause problems, not fix them.

(but thanks for the reminder)

  


It's probably due to disabling NX (which is an unwanted side effect of 
this).  Java generates executable code, so it probably needs to modify 
protection attributes.  Maybe we're bad at this.


Can you check the attached patch?  Against normal kvm, not the windows 
accelerator.


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

diff --git a/drivers/kvm/x86.c b/drivers/kvm/x86.c
index 1fe209d..e08e749 100644
--- a/drivers/kvm/x86.c
+++ b/drivers/kvm/x86.c
@@ -194,7 +194,7 @@ static void cpuid_fix_nx_cap(struct kvm_vcpu *vcpu)
 			break;
 		}
 	}
-	if (entry && (entry->edx & (1 << 20)) && !(efer & EFER_NX)) {
+	if (entry) {
 		entry->edx &= ~(1 << 20);
 		printk(KERN_INFO "kvm: guest NX capability removed\n");
 	}
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

[Avi Kivity]

Dong, Eddie wrote:
>>>   
>>>   
>> So you could set instruction length to 1 and adjust rip 
>> backwards by 1 :)
>>
>> Though you may need to remember the adjustment and undo it if 
>> you get a 
>> page fault on the IVT.
>>
>>
>> 
> What I mean is HW implicitly take SW interrupt as what it should be.
> And check exception #.
>   

Sorry, I don't understand. Exception number for software interrupt can
be anything?

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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

[Carsten Otte]

Avi Kivity wrote:
> I don't really see a big difference between what we have now (sparse 
> userspace, sparse guest) and Izik's idea (contiguous userspace, sparse 
> guest).  In both cases you need something like memory slots to describe 
> the different sections.
We don't on s390: we receive a page fault by the guest once it 
accesses a sparse hole in its address space. We check the user space's 
VMA and either page it in or submit an addressing exception to the guest.

> Moreover, on x86 you may want different properties for different 
> sections (4K pages for the framebuffer, large pages for main memory), so 
> you can't allocate memory in one big chunk.
That's right. On s390, we can live with whatever properties a section 
has with regard to page size, backing device and such. So memory may 
well come to live by different alloations, and different allocation 
methods. All we need is a permanent contiguous mapping of the guest 
physical addresses to host user addresses. So Izik's idea would work 
for us even if we have different sections.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

[Avi Kivity]

Carsten Otte wrote:
> Avi Kivity wrote:
>> I don't really see a big difference between what we have now (sparse 
>> userspace, sparse guest) and Izik's idea (contiguous userspace, 
>> sparse guest).  In both cases you need something like memory slots to 
>> describe the different sections.
> We don't on s390: we receive a page fault by the guest once it 
> accesses a sparse hole in its address space. We check the user space's 
> VMA and either page it in or submit an addressing exception to the guest.

I was talking about x86.

On x86, you need contiguous userspace, contiguous guest, but again, 
what's the problem with one memory slot?


>
>> Moreover, on x86 you may want different properties for different 
>> sections (4K pages for the framebuffer, large pages for main memory), 
>> so you can't allocate memory in one big chunk.
> That's right. On s390, we can live with whatever properties a section 
> has with regard to page size, backing device and such. So memory may 
> well come to live by different alloations, and different allocation 
> methods. All we need is a permanent contiguous mapping of the guest 
> physical addresses to host user addresses. So Izik's idea would work 
> for us even if we have different sections.

So would the current memory slot thing, no?

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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

[Avi Kivity]

Carsten Otte wrote:
> Avi Kivity wrote:
>> I was talking about x86.
>>
>> On x86, you need contiguous userspace, contiguous guest, but again, 
>> what's the problem with one memory slot?
> There is no problem with one memory slot: it works. It's just that 
> Izik's idea gives us the opportunity to have common code for all four 
> architectures here.

Why aren't memory slots common too?  Only their number is different, 
while the implementation is the same.


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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

[Avi Kivity]

Carsten Otte wrote:
> Avi Kivity wrote:
>> Why aren't memory slots common too?  Only their number is different, 
>> while the implementation is the same.
> Your approach makes the meaning of memory slot somewhat useless on 
> s390, if that one may be sparse and may be result of different 
> allocations: On x86, there has to be one memory slot per allocation, 
> versus on s390 there has to be exactly one memory slot with multiple 
> allocations behind.

No, a memory slot can span multiple backing stores.  But it must be 
contiguous in both the host userspace and guest physical address spaces.

>
> For userspace that means, with your approach it has to do total 
> different memory setup for different archs _if_ it wants to use 
> multiple allocations and/or sparse:
> - on x86 it does allocations to random userspace address, and 
> registers each of them as memory slot
> - on s390 it does allocations to a specific address layout similar to 
> the guest, and registers only one memory slot for the whole thing
>
> With Izik's approach however, this is transparent to userspace: it has 
> multiple memory slots, one per allocation. Regardless of the CPU 
> architecture.

You can do this with the current memory slots as well.  Although I'm 
feeling that I misunderstood Izik's idea.  I'll go talk to him.

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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

[Carsten Otte]

Avi Kivity wrote:
> Why aren't memory slots common too?  Only their number is different, 
> while the implementation is the same.
Your approach makes the meaning of memory slot somewhat useless on 
s390, if that one may be sparse and may be result of different 
allocations: On x86, there has to be one memory slot per allocation, 
versus on s390 there has to be exactly one memory slot with multiple 
allocations behind.

For userspace that means, with your approach it has to do total 
different memory setup for different archs _if_ it wants to use 
multiple allocations and/or sparse:
- on x86 it does allocations to random userspace address, and 
registers each of them as memory slot
- on s390 it does allocations to a specific address layout similar to 
the guest, and registers only one memory slot for the whole thing

With Izik's approach however, this is transparent to userspace: it has 
multiple memory slots, one per allocation. Regardless of the CPU 
architecture.

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] High vm-exit latencies during kvm boot-up/shutdown

[Avi Kivity]

Dong, Eddie wrote:
> Jan Kiszka wrote:
>   
>> So if you want the higher performance of PCIe you need
>> performance-killing wbindv (not to speak of latency)? That sounds a
>> bit contradictory to me. So this is also true for native PCIe usage?
>>
>> 
>
> Mmm, I won't say so. When you want to get RT performance, you
> won't use unknown OS such as Windows. If you use your RT
> linux, the OS (guest) itself should not use wbinvd.
>
>   

Well, virtualization lets you use an unknown OS without fear of 
compromising host security, so a real-time capable hypervisor (which kvm 
is, or very nearly) should be able to let you use an unknown OS without 
fear of compromising real-time response times.  Right now the only 
unresolvable issue I see is wbinvd.

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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH] kvm-userspace: Make tests compile on x86_64

[Avi Kivity]

Laurent Vivier wrote:
> These modification are needed to allow me to compile kvm-userspace
> on my x86_64 system.
>   
oops, saw this too late and worked out a similar fix.

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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

[Carsten Otte]

Avi Kivity wrote:
> Carsten Otte wrote:
>> Avi Kivity wrote:
>>> Why aren't memory slots common too?  Only their number is different, 
>>> while the implementation is the same.
>> Your approach makes the meaning of memory slot somewhat useless on 
>> s390, if that one may be sparse and may be result of different 
>> allocations: On x86, there has to be one memory slot per allocation, 
>> versus on s390 there has to be exactly one memory slot with multiple 
>> allocations behind.
> 
> No, a memory slot can span multiple backing stores.  But it must be 
> contiguous in both the host userspace and guest physical address spaces.
I was not preceise enough: I meant to state that x86 demands one 
memory slot per contiguous allocation. But with your "s390 has only 
one memory slot" idea, this introduces a severe restriction for us: 
our "single memory slot" does not need to be contiguous, neither in 
guest physical nor in host userspace. All we need, is a certain 
1:1+offset relationship between guest physical and host user. Page 
size, backing, sparse are all variable.
Izik's idea, at least how I understood him, makes the best of both 
worlds: we keep above addressing relationship intact, and have 
multiple memory slots for all architectures.

>> For userspace that means, with your approach it has to do total 
>> different memory setup for different archs _if_ it wants to use 
>> multiple allocations and/or sparse:
>> - on x86 it does allocations to random userspace address, and 
>> registers each of them as memory slot
>> - on s390 it does allocations to a specific address layout similar to 
>> the guest, and registers only one memory slot for the whole thing
>>
>> With Izik's approach however, this is transparent to userspace: it has 
>> multiple memory slots, one per allocation. Regardless of the CPU 
>> architecture.
> 
> You can do this with the current memory slots as well.  Although I'm 
> feeling that I misunderstood Izik's idea.  I'll go talk to him.
No we can't: because current memory slots don't have a permanent 
relationship between user and guest physical addresses that we do need 
on s390. We cannot guarantee that over multiple slots, and we cannot 
keep the guest from addressing memory around the memory slots unless 
we refuse to use more than only one slot which has to start at guest 
physical zero.

so long,
Carsten

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

[Avi Kivity]

Carsten Otte wrote:
> Avi Kivity wrote:
>   
>> Carsten Otte wrote:
>> 
>>> Avi Kivity wrote:
>>>   
 Why aren't memory slots common too?  Only their number is different, 
 while the implementation is the same.
 
>>> Your approach makes the meaning of memory slot somewhat useless on 
>>> s390, if that one may be sparse and may be result of different 
>>> allocations: On x86, there has to be one memory slot per allocation, 
>>> versus on s390 there has to be exactly one memory slot with multiple 
>>> allocations behind.
>>>   
>> No, a memory slot can span multiple backing stores.  But it must be 
>> contiguous in both the host userspace and guest physical address spaces.
>> 
> I was not preceise enough: I meant to state that x86 demands one 
> memory slot per contiguous allocation. But with your "s390 has only 
> one memory slot" idea, this introduces a severe restriction for us: 
> our "single memory slot" does not need to be contiguous, neither in 
> guest physical nor in host userspace. All we need, is a certain 
> 1:1+offset relationship between guest physical and host user. Page 
> size, backing, sparse are all variable.
>   

Well, a slot may be sparse (though I don't think that's supported now).

To me, a slot is exactly a guest offset, size, and host offset.  How the 
memory is populated (or not) is up to the user.

> Izik's idea, at least how I understood him, makes the best of both 
> worlds: we keep above addressing relationship intact, and have 
> multiple memory slots for all architectures.
>   

Can you explain the idea again.  Izik's not here so I can't ask him.

>   
>>> For userspace that means, with your approach it has to do total 
>>> different memory setup for different archs _if_ it wants to use 
>>> multiple allocations and/or sparse:
>>> - on x86 it does allocations to random userspace address, and 
>>> registers each of them as memory slot
>>> - on s390 it does allocations to a specific address layout similar to 
>>> the guest, and registers only one memory slot for the whole thing
>>>
>>> With Izik's approach however, this is transparent to userspace: it has 
>>> multiple memory slots, one per allocation. Regardless of the CPU 
>>> architecture.
>>>   
>> You can do this with the current memory slots as well.  Although I'm 
>> feeling that I misunderstood Izik's idea.  I'll go talk to him.
>> 
> No we can't: because current memory slots don't have a permanent 
> relationship between user and guest physical addresses that we do need 
> on s390. We cannot guarantee that over multiple slots, and we cannot 
> keep the guest from addressing memory around the memory slots unless 
> we refuse to use more than only one slot which has to start at guest 
> physical zero.
>   

Well, you could allow multiple slots and return -EINVAL if they don't 
fit the "host = guest + offset formula".  I'm not sure how that's 
different from one big, possibly sparse, slot.

But again, I don't think I understood Izik's idea, so I'm not sure 
what's the alternative.

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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3

[Carsten Otte]

This patch splits kvm_vm_ioctl into archtecture independent parts, and
x86 specific parts which go to kvm_arch_vcpu_ioctl in x86.c. 
The patch has been updated to current git, and it leaves out memory slot
registration work which is currently subject to a detailed discussion.

Common ioctls for all architectures are:
KVM_CREATE_VCPU, KVM_GET_DIRTY_LOG, KVM_SET_USER_MEMORY_REGION

KVM_SET_USER_MEMORY_REGION implementation is no longer moved to x86.c.
It seems to me that more fine-grained refinement then just moving the
code is required here.

x86 specific ioctls are:
KVM_SET_MEMORY_REGION, 
KVM_GET/SET_NR_MMU_PAGES, KVM_SET_MEMORY_ALIAS, KVM_CREATE_IRQCHIP,
KVM_CREATE_IRQ_LINE, KVM_GET/SET_IRQCHIP
KVM_SET_TSS_ADDR

KVM_SET_TSS_ADDR has been added to the list of x86 specifics, as Izik's
commit states it is used for emulating real mode on intel.


 kvm.h  |7 +
 kvm_main.c |  255
+---
 x86.c  |  258
+
 3 files changed, 271 insertions(+), 249 deletions(-)
Signed-off-by: Carsten Otte <[EMAIL PROTECTED]>
---
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index b08fc9e..438d4a9 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -621,6 +621,13 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
 unsigned int ioctl, unsigned long arg);
 void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu);
 void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu);
+int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
+  struct
+  kvm_userspace_memory_region *mem,
+  int user_alloc);
+long kvm_arch_vm_ioctl(struct file *filp,
+  unsigned int ioctl, unsigned long arg);
+void kvm_arch_destroy_vm(struct kvm *kvm);
 
 __init void kvm_arch_init(void);
 
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 9a3d663..7a85be9 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -792,36 +792,16 @@ out:
 }
 EXPORT_SYMBOL_GPL(kvm_set_memory_region);
 
-static int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
- struct
- kvm_userspace_memory_region *mem,
- int user_alloc)
+int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
+  struct
+  kvm_userspace_memory_region *mem,
+  int user_alloc)
 {
if (mem->slot >= KVM_MEMORY_SLOTS)
return -EINVAL;
return kvm_set_memory_region(kvm, mem, user_alloc);
 }
 
-static int kvm_vm_ioctl_set_nr_mmu_pages(struct kvm *kvm,
- u32 kvm_nr_mmu_pages)
-{
-   if (kvm_nr_mmu_pages < KVM_MIN_ALLOC_MMU_PAGES)
-   return -EINVAL;
-
-   mutex_lock(&kvm->lock);
-
-   kvm_mmu_change_mmu_pages(kvm, kvm_nr_mmu_pages);
-   kvm->n_requested_mmu_pages = kvm_nr_mmu_pages;
-
-   mutex_unlock(&kvm->lock);
-   return 0;
-}
-
-static int kvm_vm_ioctl_get_nr_mmu_pages(struct kvm *kvm)
-{
-   return kvm->n_alloc_mmu_pages;
-}
-
 /*
  * Get (and clear) the dirty memory log for a memory slot.
  */
@@ -867,111 +847,6 @@ out:
return r;
 }
 
-/*
- * Set a new alias region.  Aliases map a portion of physical memory into
- * another portion.  This is useful for memory windows, for example the PC
- * VGA region.
- */
-static int kvm_vm_ioctl_set_memory_alias(struct kvm *kvm,
-struct kvm_memory_alias *alias)
-{
-   int r, n;
-   struct kvm_mem_alias *p;
-
-   r = -EINVAL;
-   /* General sanity checks */
-   if (alias->memory_size & (PAGE_SIZE - 1))
-   goto out;
-   if (alias->guest_phys_addr & (PAGE_SIZE - 1))
-   goto out;
-   if (alias->slot >= KVM_ALIAS_SLOTS)
-   goto out;
-   if (alias->guest_phys_addr + alias->memory_size
-   < alias->guest_phys_addr)
-   goto out;
-   if (alias->target_phys_addr + alias->memory_size
-   < alias->target_phys_addr)
-   goto out;
-
-   mutex_lock(&kvm->lock);
-
-   p = &kvm->aliases[alias->slot];
-   p->base_gfn = alias->guest_phys_addr >> PAGE_SHIFT;
-   p->npages = alias->memory_size >> PAGE_SHIFT;
-   p->target_gfn = alias->target_phys_addr >> PAGE_SHIFT;
-
-   for (n = KVM_ALIAS_SLOTS; n > 0; --n)
-   if (kvm->aliases[n - 1].npages)
-   break;
-   kvm->naliases = n;
-
-   kvm_mmu_zap_all(kvm);
-
-   mutex_unlock(&kvm->lock);
-
-   return 0;
-
-out:
-   return r;
-}
-
-static int kvm_vm_ioctl_get_irqchip(struct kvm *kvm, struct kvm_irqchip *chip)
-{
-   int r;
-
-   r = 0;
-   switch (chip->chip_id) {
-   case KVM_IRQCHIP_PIC_MASTER:
- 

[kvm-devel] Remove hardware from host and add to guest?

[Back, Michael (ext)]

Hi,
is it with kvm possible to remove a hardware (for example: a second
PCI-E Graphiccard)- mybe on boottime like by xen.
And add dedicated this removed hardware (for example: a second PCI-E
Graphiccard) to a guest system (for example: to improve the 3D-Graphic).

With best regards,
Michael

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [RFT] kvm with Windows optimization

[Anthony Liguori]

Dong, Eddie wrote:
>> BTW, is it wise to enable this by default for all guests?
>> Ignoring the
>> fact that we're modifying guest's memory without its knowledge, if a
>> guest unmaps the VA mappings for the BIOS then all sorts of problems
>> could occur. 
>>
>> 
> Good movement!
>
> But, Vista won't work with patching. The memory guard in vista 
> will make the system refuse to service. Maybe we need a option
> to check if it is vista.
>   

Are you sure that Vista isn't just verifying memory during 
startup/driver load?  Seems odd to periodically scan memory.

In the recently released Windows Hypervisor specification, in section 
13.2.2 (Local APIC Memory-mapped Accesses), it's dictated that the APIC 
can only be accessed through 6 instructions.  They are all >= 5 byte 
instructions.  When I first saw that, I figured they were also patching.

Regards,

Anthony Liguori

> Eddie
>
>   


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [RFT] kvm with Windows optimization

[Avi Kivity]

Anthony Liguori wrote:
> Avi Kivity wrote:
>> Anthony Liguori wrote:

 Good movement!

 But, Vista won't work with patching. The memory guard in vista will 
 make the system refuse to service. Maybe we need a option
 to check if it is vista.
   
>>>
>>> Are you sure that Vista isn't just verifying memory during 
>>> startup/driver load?  Seems odd to periodically scan memory.
>>>
>>> In the recently released Windows Hypervisor specification, in 
>>> section 13.2.2 (Local APIC Memory-mapped Accesses), it's dictated 
>>> that the APIC can only be accessed through 6 instructions.  They are 
>>> all >= 5 byte instructions.  When I first saw that, I figured they 
>>> were also patching.
>>>   
>>
>> Six?  My hack patches five.  Which one did I miss?
>
> FF /6  PUSH m32
>

Thanks.  That's easy to add.

> Also note, that it says that all addresses are required to be 4-byte 
> aligned.

Which addresses?  The tpr address is obviously 4 byte aligned.

The instruction pointer?!

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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [RFT] kvm with Windows optimization

[Anthony Liguori]

Avi Kivity wrote:
> Anthony Liguori wrote:
>> Avi Kivity wrote:
>>> Anthony Liguori wrote:
>
> Good movement!
>
> But, Vista won't work with patching. The memory guard in vista 
> will make the system refuse to service. Maybe we need a option
> to check if it is vista.
>   

 Are you sure that Vista isn't just verifying memory during 
 startup/driver load?  Seems odd to periodically scan memory.

 In the recently released Windows Hypervisor specification, in 
 section 13.2.2 (Local APIC Memory-mapped Accesses), it's dictated 
 that the APIC can only be accessed through 6 instructions.  They 
 are all >= 5 byte instructions.  When I first saw that, I figured 
 they were also patching.
   
>>>
>>> Six?  My hack patches five.  Which one did I miss?
>>
>> FF /6  PUSH m32
>>
>
> Thanks.  That's easy to add.
>
>> Also note, that it says that all addresses are required to be 4-byte 
>> aligned.
>
> Which addresses?  The tpr address is obviously 4 byte aligned.

The tpr address.

Regards,

Anthony Liguori

> The instruction pointer?!
>


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [RFT] kvm with Windows optimization

[Anthony Liguori]

Avi Kivity wrote:
> Anthony Liguori wrote:
>> Avi Kivity wrote:
>>  
>>> Anthony Liguori wrote:
>>>
>> static int mmu_topup_memory_caches(struct kvm_vcpu *vcpu)
>> {
>> int r;
>>
>> kvm_mmu_free_some_pages(vcpu);
>> r = mmu_topup_memory_cache(&vcpu->mmu_pte_chain_cache,
>>pte_chain_cache, 4);
>> if (r)
>> goto out;
>> r = mmu_topup_memory_cache(&vcpu->mmu_rmap_desc_cache,
>>rmap_desc_cache, 1);
>> if (r)
>> goto out;
>> r = mmu_topup_memory_cache_page(&vcpu->mmu_page_cache, 8);
>> if (r)
>> goto out;
>> r = mmu_topup_memory_cache(&vcpu->mmu_page_header_cache,
>>mmu_page_header_cache, 4);
>> out:
>> return r;
>> }
>>   
> These are the (4, 1, 8, 4) values in the call to 
> mmu_topup_memory_cache.  Perhaps one of them is too low.
> 
 Sure.  Would this be affected at all by your tpr patch?
>>> I believe not, but the code doesn't care what I believe.
>>>
>>>
 IIUC, if this is the problem, it should be reproducible with the 
 latest git too?
   
>>> One difference is that the tpr patch disables nx.  That causes 
>>> Windows to go into 32-bit paging mode (nice that it has both pae and 
>>> nonpae in the same kernel), which may change things.
>>>
>>> You can try booting your host with nx disabled to get the same 
>>> effect (or disable nx cpuid in kvm).
>>> 
>>
>> I've disabled NX in KVM and that didn't reproduce the issue in the 
>> current git.
>>
>> If I double all of the memory caches, I can't seem to reproduce.  
>> However, as soon as I reduce rmap_desc_cache down to 1, I can reproduce.
>>
>> I'll try to see if just setting the rmap_desc_cache line to 2 is 
>> enough to make the problem go away.
>>
>> How can the guest provoke this BUG() based on the cache size?  Should 
>> the cache size only affect performance?
>>
>>   
>
> The memory caches are a little misnamed; they're really preallocation 
> buffers.
>
> They serve two purposes: to avoid allocation in atomic contexts 
> (that's no longer needed since preempt notifiers) and to avoid complex 
> error recovery paths.  We make sure there are enough objects to 
> satisfy worst case behavior and assume all allocations will work.

FWIW, two people in IRC just reported the same BUG in kvm-48 and the 
nightly snapshot.  I asked them both to post more thorough descriptions 
here.  That leads me to suspect that the problem wasn't introduced by 
your TPR optimization.

Regards,

Anthony Liguori

> Regarding the rmap memory cache failure, I can't think of a reason why 
> we'll need to add more than one rmap entry per fault.
>


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH 4/4] Let gcc to choose which registers to save (vmx-i386)

[Avi Kivity]

Laurent Vivier wrote:
> This patch lets GCC to determine which registers to save when we
> switch to/from a VCPU in the case of intel i386.
>
>   
 I don't know if its patch is really usefull as it replaces <<<
 a popa/pusha by several pop/push.  <<<
 

In general this is useful.  pusha/popa are not heavily used and are thus 
less optimized than push/pop.

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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [RFT] kvm with Windows optimization

[Anthony Liguori]

Dong, Eddie wrote:
>> BTW, is it wise to enable this by default for all guests?
>> Ignoring the
>> fact that we're modifying guest's memory without its knowledge, if a
>> guest unmaps the VA mappings for the BIOS then all sorts of problems
>> could occur. 
>>
>> 
> Good movement!
>
> But, Vista won't work with patching. The memory guard in vista 
> will make the system refuse to service. Maybe we need a option
> to check if it is vista.
>   

FWIW, I successfully installed and booted Vista Enterprise Edition with 
the TPR optimization patch.

Regards,

Anthony Liguori

> Eddie
>
>   


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] Testing Results for TPR optimization tarball

[Anthony Liguori]

With the patch to increase the minimum rmap cache, I've been able to 
successful install and boot with kvm-test:

Windows XP Professional (i386)
Windows Vista Enterprise Edition (i386)
Fedora 8 test 3 (i386)
openSUSE 10.3 (x86_64)
RHEL5 Server (x86_64)
SLES10 (x86_64)
Ubuntu 6.06.1 server (i386)
Ubuntu 7.04 desktop (x86_64)
Ubuntu 7.10 desktop (i386)

It's looking pretty good to me.

Regards,

Anthony Liguori

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [RFT] kvm with Windows optimization

[Avi Kivity]

Anthony Liguori wrote:
>>
>> Good movement!
>>
>> But, Vista won't work with patching. The memory guard in vista 
>> will make the system refuse to service. Maybe we need a option
>> to check if it is vista.
>>   
>> 
>
> Are you sure that Vista isn't just verifying memory during 
> startup/driver load?  Seems odd to periodically scan memory.
>
> In the recently released Windows Hypervisor specification, in section 
> 13.2.2 (Local APIC Memory-mapped Accesses), it's dictated that the APIC 
> can only be accessed through 6 instructions.  They are all >= 5 byte 
> instructions.  When I first saw that, I figured they were also patching.
>   

Six?  My hack patches five.  Which one did I miss?


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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [RFT] kvm with Windows optimization

[Anthony Liguori]

Avi Kivity wrote:
> Anthony Liguori wrote:
>>>
>>> Good movement!
>>>
>>> But, Vista won't work with patching. The memory guard in vista will 
>>> make the system refuse to service. Maybe we need a option
>>> to check if it is vista.
>>>   
>>
>> Are you sure that Vista isn't just verifying memory during 
>> startup/driver load?  Seems odd to periodically scan memory.
>>
>> In the recently released Windows Hypervisor specification, in section 
>> 13.2.2 (Local APIC Memory-mapped Accesses), it's dictated that the 
>> APIC can only be accessed through 6 instructions.  They are all >= 5 
>> byte instructions.  When I first saw that, I figured they were also 
>> patching.
>>   
>
> Six?  My hack patches five.  Which one did I miss?

FF /6  PUSH m32

Also note, that it says that all addresses are required to be 4-byte 
aligned.

Regards,

Anthony LIguori


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] kvm-48: kernel BUG at mmu.c:307! - invalid opcode: 0000 [#1]

[Pedro Alves]

Hello.

I've been using kvm for a while, and it's been working great so far. Today
I got a kernel error pasted below.

Some system infos:

Host: Slackware

$ uname -a
Linux nicola 2.6.23.1-smp #2 SMP Mon Oct 15 17:49:01 CDT 2007 i686 Intel(R) 
Core(TM)2 Duo CPU T7300  @ 2.00GHz GenuineIntel GNU/Linux

kvm-48

launch instructions: sudo /opt/kvm-46/bin/qemu-system-x86_64 -hda 
/shared/vm/xp_pro_sp2.qcow2 -cdrom /dev/cdrom -usb -m 1250 -L 
/opt/kvm-46/share/qemu/ -redir tcp:1433::1433 -redir tcp:3389::3389 -redir 
tcp:8022::22


Cliene:

Windows xp pro xp2


I had booted the VM and was doing nothing - AVG antivirus was running. 



Here is the paste:

[ cut here ]
kernel BUG at /home/pedro/can2/kvm-48/kernel/mmu.c:307!
invalid opcode:  [#1]
SMP 
Modules linked in: i915 drm sch_ingress cls_u32 sch_sfq sch_cbq fuse tun 
kvm_intel kvm snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq 
snd_seq_device snd_pcm_oss snd_mixer_oss ipv6 cifs capability commoncap lp 
parport_pc parport pcmcia e1000 intel_agp agpgart rtc_cmos sdhci rtc_core 
yenta_socket rtc_lib rsrc_nonstatic mmc_core tifm_7xx1 serio_raw pcmcia_core 
tifm_core thermal video output ac button battery processor snd_hda_intel 
psmouse mac80211 snd_pcm cfg80211 snd_timer snd soundcore snd_page_alloc evdev 
pcspkr sg
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246   (2.6.23.1-smp #2)
EIP is at mmu_memory_cache_alloc+0x32/0x40 [kvm]
eax:    ebx: f95658ec   ecx: d7a621b0   edx: 0014
esi: f7daf838   edi: d7a62000   ebp:    esp: f6de5b28
ds: 007b   es: 007b   fs: 00d8  gs:   ss: 0068
Process qemu-system-x86 (pid: 3688, ti=f6de4000 task=f270 task.ti=f6de4000)
Stack: d7a62000 f95658ec d7a62000 f931a271 0002  2d8ff043 f931a683 
   392fb000  000392fb    0002  
   392fb000  f7daf838 d7a62000 392fb000  2d8ff000  
Call Trace:
 [] rmap_add+0xe1/0x100 [kvm]
 [] paging32_set_pte_common+0x163/0x310 [kvm]
 [] paging32_set_pte+0x65/0x80 [kvm]
 [] kvm_mmu_pte_write+0x37e/0x3e0 [kvm]
 [] kvm_write_guest_page+0x71/0xa0 [kvm]
 [] xfs_fs_geometry+0x21c/0x2d0
 [] emulator_write_emulated_onepage+0x9b/0x120 [kvm]
 [] x86_emulate_insn+0x525/0x3630 [kvm]
 [] emulator_read_std+0x3f/0x90 [kvm]
 [] xfs_fs_geometry+0x21c/0x2d0
 [] x86_decode_insn+0x7ab/0xad0 [kvm]
 [] xfs_fs_geometry+0x21c/0x2d0
 [] emulate_instruction+0x16c/0x2a0 [kvm]
 [] handle_exception+0x25a/0x2c0 [kvm_intel]
 [] vmx_set_cr3+0xd/0x20 [kvm_intel]
 [] xfs_fs_geometry+0x21c/0x2d0
 [] kvm_handle_exit+0x79/0xc0 [kvm_intel]
 [] kvm_vcpu_ioctl_run+0x123/0x440 [kvm]
 [] kvm_vcpu_ioctl+0x0/0xba0 [kvm]
 [] kvm_vcpu_ioctl+0xb44/0xba0 [kvm]
 [] sock_common_recvmsg+0x45/0x70
 [] sock_recvmsg+0x123/0x140
 [] skb_dequeue+0x40/0x60
 [] unix_stream_recvmsg+0x24e/0x580
 [] resched_task+0x55/0x60
 [] core_sys_select+0x23b/0x2d0
 [] update_curr+0x141/0x150
 [] __dequeue_signal+0x10/0x170
 [] recalc_sigpending+0xb/0x20
 [] dequeue_signal+0x48/0x140
 [] getnstimeofday+0x36/0xd0
 [] enqueue_hrtimer+0x5f/0x80
 [] hrtimer_start+0xba/0x120
 [] kvm_vcpu_ioctl+0x0/0xba0 [kvm]
 [] do_ioctl+0x2b/0x90
 [] vfs_ioctl+0x5c/0x290
 [] sys_ioctl+0x72/0x90
 [] syscall_call+0x7/0xb
 ===
Code: 8b 00 85 c0 74 25 48 8b 5c 81 04 89 01 89 d1 31 c0 c1 e9 02 89 df f3 ab 
f6 c2 02 74 02 66 ab f6 c2 01 74 01 aa 5a 89 d8 5b 5f c3 <0f> 0b eb fe 8d 76 00 
8d bc 27 00 00 00 00 05 b0 01 00 00 ba 14 
EIP: [] mmu_memory_cache_alloc+0x32/0x40 [kvm] SS:ESP 0068:f6de5b28






-- 
Pedro Alves

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH 0/4] Let gcc to choose which registers to save

[Avi Kivity]

Laurent Vivier wrote:
> This patch lets GCC to determine which registers to save when we
> switch to/from a VCPU.
>   

Applied all, thanks.  Hopefully all the gccs out there will like it.

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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

[Hollis Blanchard]

On Fri, 2007-10-26 at 10:21 +0200, Carsten Otte wrote:
> 
> As Xiantao pointed out, x86 and ia64 can share the same memory setup 
> code. But s390 and ppc don't. Therefore, I vote for putting it into 
> x86 for now, and come up with an approach to share between x86 and 
> ia64 later on.

The only thing in the current ioctl code that doesn't make sense for
PowerPC is the rmap stuff. The concept of "slots" as memory extents is
just fine.

Originally, I think the only question was how to register the slots on
the kernel side. Today that is done with separate
KVM_SET_USER_MEMORY_REGION ioctls, one for each guest physical region.

Izik's idea (as I understand it) is to have one ioctl registering all of
RAM, and then multiple "configure slot" ioctls that tell the kernel how
to divide that area into the guest physical address space. That seems
more awkward to me and I don't seem a benefit.

-- 
Hollis Blanchard
IBM Linux Technology Center


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

[Carsten Otte]

Hollis Blanchard wrote:
> Izik's idea (as I understand it) is to have one ioctl registering all of
> RAM, and then multiple "configure slot" ioctls that tell the kernel how
> to divide that area into the guest physical address space. That seems
> more awkward to me and I don't seem a benefit.
I think we need to wait for Izik to explain more. In this 
interpretation it really does'nt make sense for s390 as well. My 
interpretation of Izik's idea was just like memory slots are today. 
Avi clarified my misunderstanding of memory slots on x86.

so long,
Carsten

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v2

[Carsten Otte]

Zhang, Xiantao wrote:
> I don't think we can move the whole function to arch-specific part,
> because  it should work well (or with few issues) for most archs.
> Basically, IA64 mostly can use it directly. If we move them as
> arch-specific, it will introduces many duplicates. As you said, S390 has
> quite difference about this side, but I think maybe we can use macros,
> such as #ifndef CONFIG_S390 to comment out them, and S390 define it in
> your arch-specific portions. Any other good ideas ?
I really dislike CONFIG_ARCH sections. They are usually a strong 
indication that proper interfaces between arch dependent and arch 
independent code have not been found just yet. If you look at old 
subsystems where lots of engineers had time to optimize the code, like 
memory management for example, you rarely find #ifdefs at all. I think 
that should be our goal.
As for KVM_SET_USER_MEMORY_REGION, the function you pointed at, I've 
left it in common for now in patch version 3.

thanks for your review,
Carsten

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] kvm-48: kernel BUG at mmu.c:307! - invalid opcode: 0000 [#1]

[Aurelien Jarno]

On Fri, Oct 26, 2007 at 03:09:06PM +0100, Pedro Alves wrote:
> 
> 
> Hello.
> 
> I've been using kvm for a while, and it's been working great so far. Today
> I got a kernel error pasted below.

Strangely I got the same problem one or two hours ago.

Here are some info about the host:
- Distribution: Debian
- Architecture: x86_64
- Kernel: 2.6.22-2
- CPU: Intel Core 2 Q6600
- KVM 48

The system is running 10 KVM guests and the operating systems are BSD, Linux, 
Hurd, GNU/kFreeBSD.

Only one of the two GNU/kFreeBSD amd64 guests crashed, the others are
still running fine. It was under heavy load (building a glibc).

And the dmesg log:


[ cut here ]
kernel BUG at /usr/local/src/kvm-48/kernel/mmu.c:307!
invalid opcode:  [1] SMP 
CPU 3 
Modules linked in: usb_storage kvm_intel kvm cpufreq_userspace nfs nfsd 
exportfs lockd nfs_acl sunrpc ppdev lp button ac battery xt_mark xt_MARK 
ipt_REDIRECT ipt_REJECT ipt_recent xt_state ipt_TOS xt_tcpudp ipt_LOG xt_limit 
iptable_mangle iptable_nat nf_conntrack_ipv4 iptable_filter ip_tables x_tables 
nf_nat_h323 nf_conntrack_h323 nf_nat_rtsp nf_conntrack_rtsp nf_nat_tftp 
nf_conntrack_tftp nf_nat_ftp nf_conntrack_ftp nf_nat_irc nf_nat 
nf_conntrack_irc nf_conntrack nfnetlink aoe sit tunnel4 wlan_wep bridge 
quota_v2 dm_snapshot dm_mirror dm_mod cpufreq_stats cpufreq_ondemand 
acpi_cpufreq freq_table tun loop it87 hwmon_vid i2c_isa coretemp 8021q ipv6 
snd_hda_intel ftdi_sio wlan_scan_ap snd_pcm snd_timer snd ath_rate_sample 
usbserial evdev intel_agp soundcore snd_page_alloc i2c_i801 ath_pci wlan usblp 
i2c_core ath_hal(P) parport_pc parport pcspkr ext3 jbd mbcache raid456 xor 
raid1 raid0 md_mod ide_generic ide_cd cdrom ata_generic sd_mod usbhid hid 
jmicron r8169 firewire_ohci fire
 wire_core crc_itu_t ahci generic ide_core e1000 ehci_hcd libata scsi_mod 
uhci_hcd thermal processor fan
Pid: 11409, comm: qemu-system-x86 Tainted: P   2.6.22-2-amd64 #1
RIP: 0010:[]  [] 
:kvm:mmu_memory_cache_alloc+0xd/0x29
RSP: 0018:8102206a39c8  EFLAGS: 00010246
RAX:  RBX: c20013238810 RCX: 0028
RDX: 810133d84088 RSI: 0028 RDI: 8101c5b04758
RBP: 8101c5b04440 R08:  R09: 0004
R10: 071c2067 R11: 885a137c R12: 8101009c6010
R13: 0002 R14: 8101c5b04440 R15: 8101009c6010
FS:  2b2e3cc37550() GS:810227b29b40() knlGS:
CS:  0010 DS: 002b ES: 002b CR0: 80050033
CR2: 005b19a4 CR3: 00014f225000 CR4: 26e0
Process qemu-system-x86 (pid: 11409, threadinfo 8102206a2000, task 
810226c370a0)
Stack:  71c2 8839a48c 00018c586047 00018c586000
 0045 8839ae92 0001 71c2
   071c2000 071c2000
Call Trace:
 [] :kvm:rmap_add+0x85/0xe7
 [] :kvm:paging64_set_pte_common+0x1c5/0x22e
 [] :kvm:paging64_set_pte+0x4a/0x4f
 [] :kvm:kvm_mmu_pte_write+0x2b8/0x328
 [] :kvm:emulator_write_emulated_onepage+0x6e/0xce
 [] :kvm:x86_emulate_insn+0x2ba1/0x4146
 [] :kvm:x86_decode_insn+0x78c/0xa25
 [] :kvm_intel:vmcs_readl+0x17/0x1c
 [] :kvm:emulate_instruction+0x152/0x290
 [] :kvm_intel:handle_exception+0x170/0x250
 [] :kvm:kvm_vcpu_ioctl+0x357/0xf57
 [] task_rq_lock+0x3d/0x6f
 [] __activate_task+0x26/0x38
 [] memcpy_toiovec+0x36/0x66
 [] skb_copy_datagram_iovec+0x49/0x1ed
 [] remove_wait_queue+0x12/0x45
 [] :tun:tun_chr_aio_read+0x2a8/0x2ba
 [] core_sys_select+0x234/0x265
 [] __dequeue_signal+0x19/0x15a
 [] dequeue_signal+0xa5/0x126
 [] getnstimeofday+0x32/0x8b
 [] do_ioctl+0x2b/0xb6
 [] vfs_ioctl+0x24d/0x266
 [] sys_ioctl+0x59/0x7c
 [] system_call+0x7e/0x83


Code: 0f 0b eb fe ff c8 89 07 48 98 48 8b 54 c7 08 31 c0 fc 48 89 
RIP  [] :kvm:mmu_memory_cache_alloc+0xd/0x29
 RSP 


-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

[Izik Eidus]

Carsten Otte wrote:
> Hollis Blanchard wrote:
>   
>> Izik's idea (as I understand it) is to have one ioctl registering all of
>> RAM, and then multiple "configure slot" ioctls that tell the kernel how
>> to divide that area into the guest physical address space. That seems
>> more awkward to me and I don't seem a benefit.
>> 
> I think we need to wait for Izik to explain more. In this 
> interpretation it really does'nt make sense for s390 as well. My 
> interpretation of Izik's idea was just like memory slots are today. 
> Avi clarified my misunderstanding of memory slots on x86.
>   
my idea was to let kvm register userspace memory that will hold the 
guest memory,
and then much like qemu do with its cpu_register_physical_memory 
function, run ioctls
that will tell the kernel how to map this memory,
what i wanted to achieved is making the memory allocation code shared, 
but still
let each arch to use any kind of "arch depended" mapping rules it want,
but after reading the last posts it seems like you can use the normal 
memslots, so it is kind of useless i guess and i will
give up the idea of writing patch to make this, unless you still have 
problem with the memslots?

thanks.

> so long,
> Carsten
>
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> ___
> kvm-devel mailing list
> kvm-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>   


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] Testing Results for TPR optimization tarball

[Haydn Solomon]

Were you able to do this with -smp 2 or more?

On 10/26/07, Anthony Liguori <[EMAIL PROTECTED]> wrote:
>
> With the patch to increase the minimum rmap cache, I've been able to
> successful install and boot with kvm-test:
>
> Windows XP Professional (i386)
> Windows Vista Enterprise Edition (i386)
> Fedora 8 test 3 (i386)
> openSUSE 10.3 (x86_64)
> RHEL5 Server (x86_64)
> SLES10 (x86_64)
> Ubuntu 6.06.1 server (i386)
> Ubuntu 7.04 desktop (x86_64)
> Ubuntu 7.10 desktop (i386)
>
> It's looking pretty good to me.
>
> Regards,
>
> Anthony Liguori
>
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> ___
> kvm-devel mailing list
> kvm-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] Testing Results for TPR optimization tarball

[Anthony Liguori]

Haydn Solomon wrote:
> Were you able to do this with -smp 2 or more?

I haven't tried doing smp testing yet.  But I can do that now.

Regards,

Anthony Liguori

> On 10/26/07, *Anthony Liguori* <[EMAIL PROTECTED] 
> > wrote:
>
> With the patch to increase the minimum rmap cache, I've been able to
> successful install and boot with kvm-test:
>
> Windows XP Professional (i386)
> Windows Vista Enterprise Edition (i386)
> Fedora 8 test 3 (i386)
> openSUSE 10.3 (x86_64)
> RHEL5 Server (x86_64)
> SLES10 (x86_64)
> Ubuntu 6.06.1 server (i386)
> Ubuntu 7.04 desktop (x86_64)
> Ubuntu 7.10 desktop (i386)
>
> It's looking pretty good to me.
>
> Regards,
>
> Anthony Liguori
>
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> ___
> kvm-devel mailing list
> kvm-devel@lists.sourceforge.net
> 
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>
>


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] Testing Results for TPR optimization tarball

[Anthony Liguori]

Haydn Solomon wrote:
> Were you able to do this with -smp 2 or more?

I get a BSOD with -smp 2.  But I haven't yet been able to confirm that 
this is a regression.

Since the TPR optimization makes the install go over 2x as fast, it's 
throwing off my automated tests.

Regards,

Anthony Liguori

> On 10/26/07, *Anthony Liguori* <[EMAIL PROTECTED] 
> > wrote:
>
> With the patch to increase the minimum rmap cache, I've been able to
> successful install and boot with kvm-test:
>
> Windows XP Professional (i386)
> Windows Vista Enterprise Edition (i386)
> Fedora 8 test 3 (i386)
> openSUSE 10.3 (x86_64)
> RHEL5 Server (x86_64)
> SLES10 (x86_64)
> Ubuntu 6.06.1 server (i386)
> Ubuntu 7.04 desktop (x86_64)
> Ubuntu 7.10 desktop (i386)
>
> It's looking pretty good to me.
>
> Regards,
>
> Anthony Liguori
>
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> ___
> kvm-devel mailing list
> kvm-devel@lists.sourceforge.net
> 
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>
>


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3

[Hollis Blanchard]

Acked-by: Hollis Blanchard <[EMAIL PROTECTED]>

On Fri, 2007-10-26 at 14:01 +0200, Carsten Otte wrote:
> This patch splits kvm_vm_ioctl into archtecture independent parts, and
> x86 specific parts which go to kvm_arch_vcpu_ioctl in x86.c. 
> The patch has been updated to current git, and it leaves out memory slot
> registration work which is currently subject to a detailed discussion.
> 
> Common ioctls for all architectures are:
> KVM_CREATE_VCPU, KVM_GET_DIRTY_LOG, KVM_SET_USER_MEMORY_REGION
> 
> KVM_SET_USER_MEMORY_REGION implementation is no longer moved to x86.c.
> It seems to me that more fine-grained refinement then just moving the
> code is required here.
> 
> x86 specific ioctls are:
> KVM_SET_MEMORY_REGION, 
> KVM_GET/SET_NR_MMU_PAGES, KVM_SET_MEMORY_ALIAS, KVM_CREATE_IRQCHIP,
> KVM_CREATE_IRQ_LINE, KVM_GET/SET_IRQCHIP
> KVM_SET_TSS_ADDR
> 
> KVM_SET_TSS_ADDR has been added to the list of x86 specifics, as Izik's
> commit states it is used for emulating real mode on intel.
> 
> 
>  kvm.h  |7 +
>  kvm_main.c |  255
> +---
>  x86.c  |  258
> +
>  3 files changed, 271 insertions(+), 249 deletions(-)
> Signed-off-by: Carsten Otte <[EMAIL PROTECTED]>
> ---
> diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
> index b08fc9e..438d4a9 100644
> --- a/drivers/kvm/kvm.h
> +++ b/drivers/kvm/kvm.h
> @@ -621,6 +621,13 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
>unsigned int ioctl, unsigned long arg);
>  void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu);
>  void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu);
> +int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
> +struct
> +kvm_userspace_memory_region *mem,
> +int user_alloc);
> +long kvm_arch_vm_ioctl(struct file *filp,
> +unsigned int ioctl, unsigned long arg);
> +void kvm_arch_destroy_vm(struct kvm *kvm);
> 
>  __init void kvm_arch_init(void);
> 
> diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
> index 9a3d663..7a85be9 100644
> --- a/drivers/kvm/kvm_main.c
> +++ b/drivers/kvm/kvm_main.c
> @@ -792,36 +792,16 @@ out:
>  }
>  EXPORT_SYMBOL_GPL(kvm_set_memory_region);
> 
> -static int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
> -   struct
> -   kvm_userspace_memory_region *mem,
> -   int user_alloc)
> +int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
> +struct
> +kvm_userspace_memory_region *mem,
> +int user_alloc)
>  {
>   if (mem->slot >= KVM_MEMORY_SLOTS)
>   return -EINVAL;
>   return kvm_set_memory_region(kvm, mem, user_alloc);
>  }
> 
> -static int kvm_vm_ioctl_set_nr_mmu_pages(struct kvm *kvm,
> -   u32 kvm_nr_mmu_pages)
> -{
> - if (kvm_nr_mmu_pages < KVM_MIN_ALLOC_MMU_PAGES)
> - return -EINVAL;
> -
> - mutex_lock(&kvm->lock);
> -
> - kvm_mmu_change_mmu_pages(kvm, kvm_nr_mmu_pages);
> - kvm->n_requested_mmu_pages = kvm_nr_mmu_pages;
> -
> - mutex_unlock(&kvm->lock);
> - return 0;
> -}
> -
> -static int kvm_vm_ioctl_get_nr_mmu_pages(struct kvm *kvm)
> -{
> - return kvm->n_alloc_mmu_pages;
> -}
> -
>  /*
>   * Get (and clear) the dirty memory log for a memory slot.
>   */
> @@ -867,111 +847,6 @@ out:
>   return r;
>  }
> 
> -/*
> - * Set a new alias region.  Aliases map a portion of physical memory into
> - * another portion.  This is useful for memory windows, for example the PC
> - * VGA region.
> - */
> -static int kvm_vm_ioctl_set_memory_alias(struct kvm *kvm,
> -  struct kvm_memory_alias *alias)
> -{
> - int r, n;
> - struct kvm_mem_alias *p;
> -
> - r = -EINVAL;
> - /* General sanity checks */
> - if (alias->memory_size & (PAGE_SIZE - 1))
> - goto out;
> - if (alias->guest_phys_addr & (PAGE_SIZE - 1))
> - goto out;
> - if (alias->slot >= KVM_ALIAS_SLOTS)
> - goto out;
> - if (alias->guest_phys_addr + alias->memory_size
> - < alias->guest_phys_addr)
> - goto out;
> - if (alias->target_phys_addr + alias->memory_size
> - < alias->target_phys_addr)
> - goto out;
> -
> - mutex_lock(&kvm->lock);
> -
> - p = &kvm->aliases[alias->slot];
> - p->base_gfn = alias->guest_phys_addr >> PAGE_SHIFT;
> - p->npages = alias->memory_size >> PAGE_SHIFT;
> - p->target_gfn = alias->target_phys_addr >> PAGE_SHIFT;
> -
> - for (n = KVM_ALIAS_SLOTS; n > 0; --n)
> - if (kvm->aliases[n - 1].npages)
> - break;
> - kvm->naliases = n;
> -
> - kvm_mmu_zap_all(kvm);
> -
> - mutex_

[kvm-devel] [PATCH] Move libkvm into its own directory. No functional changes

[Hollis Blanchard]

16 files changed, 62 insertions(+), 33 deletions(-)
Makefile   |   14 --
configure  |4 ++--
libkvm/Makefile|   37 +
libkvm/config-i386.mak |2 ++
libkvm/config-x86_64.mak   |2 ++
libkvm/libkvm.c|2 +-
qemu/Makefile.target   |2 +-
qemu/hw/vga.c  |2 +-
qemu/hw/vmport.c   |2 +-
qemu/qemu-kvm.c|2 +-
qemu/qemu-kvm.h|2 +-
user/Makefile  |   14 ++
user/config-i386.mak   |1 -
user/config-x86-common.mak |6 ++
user/config-x86_64.mak |1 -
user/main.c|2 +-


Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>

---
I've build-tested this pretty thoroughly on x86(32).

diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -5,16 +5,17 @@ DESTDIR=
 
 rpmrelease = devel
 
-.PHONY: kernel user qemu bios clean
+.PHONY: kernel user libkvm qemu bios clean
 
-all: $(if $(WANT_MODULE), kernel) user qemu
+all: $(if $(WANT_MODULE), kernel) user libkvm qemu
 
 kcmd = $(if $(WANT_MODULE),,@\#)
 
-qemu kernel user:
+qemu kernel user libkvm:
$(MAKE) -C $@
 
-qemu: user
+qemu: libkvm
+user: libkvm
 
 bios:
$(MAKE) -C $@
@@ -41,7 +42,7 @@ install-rpm:
 
 install:
$(kcmd)make -C kernel DESTDIR="$(DESTDIR)" install
-   make -C user DESTDIR="$(DESTDIR)" install
+   make -C libkvm DESTDIR="$(DESTDIR)" install
make -C qemu DESTDIR="$(DESTDIR)" install
 
 tmpspec = .tmp.kvm.spec
@@ -59,6 +60,7 @@ srpm:
sed 's/^Release:.*/Release: $(rpmrelease)/' kvm.spec > $(tmpspec)
tar czf SOURCES/kvm.tar.gz qemu
tar czf SOURCES/user.tar.gz user
+   tar czf SOURCES/libkvm.tar.gz libkvm
tar czf SOURCES/kernel.tar.gz kernel
tar czf SOURCES/scripts.tar.gz scripts
cp Makefile configure kvm_stat SOURCES
@@ -66,7 +68,7 @@ srpm:
$(RM) $(tmpspec)
 
 clean:
-   for i in $(if $(WANT_MODULE), kernel) user qemu; do \
+   for i in $(if $(WANT_MODULE), kernel) user libkvm qemu; do \
make -C $$i clean; \
done
rm -f config.mak user/config.mak
diff --git a/configure b/configure
--- a/configure
+++ b/configure
@@ -108,8 +108,8 @@ fi
 
 #configure qemu
 (cd qemu; ./configure --target-list=$target_exec \
---disable-kqemu --extra-cflags="-I $PWD/../user $qemu_cflags" \
---extra-ldflags="-L $PWD/../user $qemu_ldflags" \
+--disable-kqemu --extra-cflags="-I $PWD/../libkvm $qemu_cflags" \
+--extra-ldflags="-L $PWD/../libkvm $qemu_ldflags" \
 --enable-kvm --kernel-path="$libkvm_kerneldir" \
 ${enable_alsa:+"--enable-alsa"} \
 ${disable_vnc_tls:+"--disable-vnc-tls"} \
diff --git a/libkvm/Makefile b/libkvm/Makefile
new file mode 100644
--- /dev/null
+++ b/libkvm/Makefile
@@ -0,0 +1,37 @@
+include ../config.mak
+include config-$(ARCH).mak
+
+# cc-option
+# Usage: OP_CFLAGS+=$(call cc-option, -falign-functions=0, -malign-functions=0)
+cc-option = $(shell if $(CC) $(1) -S -o /dev/null -xc /dev/null \
+  > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi ;)
+
+CFLAGS += $(autodepend-flags) -g -fomit-frame-pointer -Wall
+CFLAGS += $(call cc-option, -fno-stack-protector, "")
+CFLAGS += $(call cc-option, -fno-stack-protector-all, "")
+CFLAGS += -I $(KERNELDIR)/include
+
+LDFLAGS += $(CFLAGS)
+
+CXXFLAGS = $(autodepend-flags)
+
+autodepend-flags = -MMD -MF $(dir $*).$(notdir $*).d
+
+
+all: libkvm.a
+
+libkvm.a: libkvm.o
+   $(AR) rcs $@ $^
+
+install:
+   install -D libkvm.h $(DESTDIR)/$(PREFIX)/include/libkvm.h
+   install -D $(KERNELDIR)/include/linux/kvm.h \
+   $(DESTDIR)/$(PREFIX)/include/linux/kvm.h
+   install -D $(KERNELDIR)/include/linux/kvm_para.h \
+   $(DESTDIR)/$(PREFIX)/include/linux/kvm_para.h
+   install -D libkvm.a $(DESTDIR)/$(PREFIX)/$(LIBDIR)/libkvm.a
+
+-include .*.d
+
+clean:
+   $(RM) *.o *.a .*.d
diff --git a/libkvm/config-i386.mak b/libkvm/config-i386.mak
new file mode 100644
--- /dev/null
+++ b/libkvm/config-i386.mak
@@ -0,0 +1,2 @@
+
+LIBDIR := /lib
diff --git a/libkvm/config-x86_64.mak b/libkvm/config-x86_64.mak
new file mode 100644
--- /dev/null
+++ b/libkvm/config-x86_64.mak
@@ -0,0 +1,2 @@
+
+LIBDIR := /lib64
diff --git a/user/kvm-abi-10.h b/libkvm/kvm-abi-10.h
rename from user/kvm-abi-10.h
rename to libkvm/kvm-abi-10.h
diff --git a/user/kvmctl.c b/libkvm/libkvm.c
rename from user/kvmctl.c
rename to libkvm/libkvm.c
--- a/libkvm/libkvm.c
+++ b/libkvm/libkvm.c
@@ -34,7 +34,7 @@
 #include 
 #include 
 #include 
-#include "kvmctl.h"
+#include "libkvm.h"
 #include "kvm-abi-10.h"
 
 static int kvm_abi = EXPECTED_KVM_API_VERSION;
diff --git a/user/kvmctl.h b/libkvm/libkvm.h
rename from user/kvmctl.h
rename to libkvm/libkvm.h
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
--- a/qemu/Makefile.target
+++ b/qemu/Makefile.target
@@ -419,7 +419,7 @@ ifdef CONFIG_KVM_KER

[kvm-devel] [PATCH] Move libkvm (v2)

[Hollis Blanchard]

17 files changed, 64 insertions(+), 35 deletions(-)
Makefile   |   14 --
configure  |4 ++--
libkvm/Makefile|   37 +
libkvm/config-i386.mak |2 ++
libkvm/config-x86_64.mak   |2 ++
libkvm/libkvm.c|2 +-
libkvm/libkvm.h|4 ++--
qemu/Makefile.target   |2 +-
qemu/hw/vga.c  |2 +-
qemu/hw/vmport.c   |2 +-
qemu/qemu-kvm.c|2 +-
qemu/qemu-kvm.h|2 +-
user/Makefile  |   14 ++
user/config-i386.mak   |1 -
user/config-x86-common.mak |6 ++
user/config-x86_64.mak |1 -
user/main.c|2 +-


Move libkvm into its own directory. No functional changes.

Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>

---
I've build-tested this pretty thoroughly on x86(32).

Changes from v1: update libkvm.h #include guard macro.

diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -5,16 +5,17 @@ DESTDIR=
 
 rpmrelease = devel
 
-.PHONY: kernel user qemu bios clean
+.PHONY: kernel user libkvm qemu bios clean
 
-all: $(if $(WANT_MODULE), kernel) user qemu
+all: $(if $(WANT_MODULE), kernel) user libkvm qemu
 
 kcmd = $(if $(WANT_MODULE),,@\#)
 
-qemu kernel user:
+qemu kernel user libkvm:
$(MAKE) -C $@
 
-qemu: user
+qemu: libkvm
+user: libkvm
 
 bios:
$(MAKE) -C $@
@@ -41,7 +42,7 @@ install-rpm:
 
 install:
$(kcmd)make -C kernel DESTDIR="$(DESTDIR)" install
-   make -C user DESTDIR="$(DESTDIR)" install
+   make -C libkvm DESTDIR="$(DESTDIR)" install
make -C qemu DESTDIR="$(DESTDIR)" install
 
 tmpspec = .tmp.kvm.spec
@@ -59,6 +60,7 @@ srpm:
sed 's/^Release:.*/Release: $(rpmrelease)/' kvm.spec > $(tmpspec)
tar czf SOURCES/kvm.tar.gz qemu
tar czf SOURCES/user.tar.gz user
+   tar czf SOURCES/libkvm.tar.gz libkvm
tar czf SOURCES/kernel.tar.gz kernel
tar czf SOURCES/scripts.tar.gz scripts
cp Makefile configure kvm_stat SOURCES
@@ -66,7 +68,7 @@ srpm:
$(RM) $(tmpspec)
 
 clean:
-   for i in $(if $(WANT_MODULE), kernel) user qemu; do \
+   for i in $(if $(WANT_MODULE), kernel) user libkvm qemu; do \
make -C $$i clean; \
done
rm -f config.mak user/config.mak
diff --git a/configure b/configure
--- a/configure
+++ b/configure
@@ -108,8 +108,8 @@ fi
 
 #configure qemu
 (cd qemu; ./configure --target-list=$target_exec \
---disable-kqemu --extra-cflags="-I $PWD/../user $qemu_cflags" \
---extra-ldflags="-L $PWD/../user $qemu_ldflags" \
+--disable-kqemu --extra-cflags="-I $PWD/../libkvm $qemu_cflags" \
+--extra-ldflags="-L $PWD/../libkvm $qemu_ldflags" \
 --enable-kvm --kernel-path="$libkvm_kerneldir" \
 ${enable_alsa:+"--enable-alsa"} \
 ${disable_vnc_tls:+"--disable-vnc-tls"} \
diff --git a/libkvm/Makefile b/libkvm/Makefile
new file mode 100644
--- /dev/null
+++ b/libkvm/Makefile
@@ -0,0 +1,37 @@
+include ../config.mak
+include config-$(ARCH).mak
+
+# cc-option
+# Usage: OP_CFLAGS+=$(call cc-option, -falign-functions=0, -malign-functions=0)
+cc-option = $(shell if $(CC) $(1) -S -o /dev/null -xc /dev/null \
+  > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi ;)
+
+CFLAGS += $(autodepend-flags) -g -fomit-frame-pointer -Wall
+CFLAGS += $(call cc-option, -fno-stack-protector, "")
+CFLAGS += $(call cc-option, -fno-stack-protector-all, "")
+CFLAGS += -I $(KERNELDIR)/include
+
+LDFLAGS += $(CFLAGS)
+
+CXXFLAGS = $(autodepend-flags)
+
+autodepend-flags = -MMD -MF $(dir $*).$(notdir $*).d
+
+
+all: libkvm.a
+
+libkvm.a: libkvm.o
+   $(AR) rcs $@ $^
+
+install:
+   install -D libkvm.h $(DESTDIR)/$(PREFIX)/include/libkvm.h
+   install -D $(KERNELDIR)/include/linux/kvm.h \
+   $(DESTDIR)/$(PREFIX)/include/linux/kvm.h
+   install -D $(KERNELDIR)/include/linux/kvm_para.h \
+   $(DESTDIR)/$(PREFIX)/include/linux/kvm_para.h
+   install -D libkvm.a $(DESTDIR)/$(PREFIX)/$(LIBDIR)/libkvm.a
+
+-include .*.d
+
+clean:
+   $(RM) *.o *.a .*.d
diff --git a/libkvm/config-i386.mak b/libkvm/config-i386.mak
new file mode 100644
--- /dev/null
+++ b/libkvm/config-i386.mak
@@ -0,0 +1,2 @@
+
+LIBDIR := /lib
diff --git a/libkvm/config-x86_64.mak b/libkvm/config-x86_64.mak
new file mode 100644
--- /dev/null
+++ b/libkvm/config-x86_64.mak
@@ -0,0 +1,2 @@
+
+LIBDIR := /lib64
diff --git a/user/kvm-abi-10.h b/libkvm/kvm-abi-10.h
rename from user/kvm-abi-10.h
rename to libkvm/kvm-abi-10.h
diff --git a/user/kvmctl.c b/libkvm/libkvm.c
rename from user/kvmctl.c
rename to libkvm/libkvm.c
--- a/libkvm/libkvm.c
+++ b/libkvm/libkvm.c
@@ -34,7 +34,7 @@
 #include 
 #include 
 #include 
-#include "kvmctl.h"
+#include "libkvm.h"
 #include "kvm-abi-10.h"
 
 static int kvm_abi = EXPECTED_KVM_API_VERSION;
diff --git a/user/kvmctl.h b/libkvm/libkvm.h
rename from user/kvmctl.h
rename to libkvm/libkv

Re: [kvm-devel] Testing Results for TPR optimization tarball

[Anthony Liguori]

Haydn Solomon wrote:
> Yeah.. I also got BSOD with windows xp sp2. I'll continue to run with 
> the tpr + rmap patch with one vcpu as that's running perfectly fine 
> for me. Thanks.

I don't think it's a regression.  With the latest git, I cannot install 
Windows XP with -smp 2.

Regards,

Anthony Liguori

> On 10/26/07, * Anthony Liguori* <[EMAIL PROTECTED] 
> > wrote:
>
> Haydn Solomon wrote:
> > Were you able to do this with -smp 2 or more?
>
> I get a BSOD with -smp 2.  But I haven't yet been able to confirm that
> this is a regression.
>
> Since the TPR optimization makes the install go over 2x as fast, it's
> throwing off my automated tests.
>
> Regards,
>
> Anthony Liguori
>
> > On 10/26/07, *Anthony Liguori* <[EMAIL PROTECTED]
> 
> > mailto:[EMAIL PROTECTED]>>>
> wrote:
> >
> > With the patch to increase the minimum rmap cache, I've been
> able to
> > successful install and boot with kvm-test:
> >
> > Windows XP Professional (i386)
> > Windows Vista Enterprise Edition (i386)
> > Fedora 8 test 3 (i386)
> > openSUSE 10.3 (x86_64)
> > RHEL5 Server (x86_64)
> > SLES10 (x86_64)
> > Ubuntu 6.06.1 server (i386)
> > Ubuntu 7.04 desktop (x86_64)
> > Ubuntu 7.10 desktop (i386)
> >
> > It's looking pretty good to me.
> >
> > Regards,
> >
> > Anthony Liguori
> >
> >
> -
>
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a
> > browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > ___
> > kvm-devel mailing list
> > kvm-devel@lists.sourceforge.net
> 
> >  >
> > https://lists.sourceforge.net/lists/listinfo/kvm-devel
> >
> >
>
>


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] Testing Results for TPR optimization tarball

[Haydn Solomon]

On 10/26/07, Anthony Liguori <[EMAIL PROTECTED]> wrote:
>
> Haydn Solomon wrote:
> > Yeah.. I also got BSOD with windows xp sp2. I'll continue to run with
> > the tpr + rmap patch with one vcpu as that's running perfectly fine
> > for me. Thanks.
>
> I don't think it's a regression.  With the latest git, I cannot install
> Windows XP with -smp 2.
>
> Regards,
>
> Anthony Liguori



Thanks. I'll hang tight till smp is sorted out. Its still so much better
even with one cpu

Regards

Haydn
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel