Anthony Liguori wrote:
> The virtio config space is little endian. Make sure that in virtio-blk we
> store the values in little endian format.
>
Applied, thanks.
--
error compiling committee.c: too many arguments to function
-
Joerg Roedel wrote:
> The kvm_host.h file for x86 declares the functions kvm_set_cr[0348]. In the
> header file their second parameter is named cr0 in all cases. This patch
> renames the parameters so that they match the function name.
>
Applied, thanks.
--
error compiling committee.c: too ma
David Abrahams wrote:
> With the title combination, the guest takes nearly 100% of my real CPU
> time and still only sees one CPU. Is this a known problem, and does it
> have a known solution?
>
>
Can you send the output of 'kvm_stat -1'? Also, what does the guest
think it is doing (in task
On Tue, Apr 01, 2008 at 01:55:32PM -0700, Christoph Lameter wrote:
> +/* Perform a callback */
> +int __emm_notify(struct mm_struct *mm, enum emm_operation op,
> + unsigned long start, unsigned long end)
> +{
> + struct emm_notifier *e = rcu_dereference(mm)->emm_notifier;
> + in
Иностpанные pаботники-особенности тpудовых отношений и налогообложения.
Новшества в законодательстве
Семинаp пpойдёт 10 апpеля 2008, г. Москва
Пpогpамма:
1. Статус иностpанного гpажданина в pФ. pезиденты и неpезиденты. pегистpация по
месту жительства.
2. Участие иностpанцев в тpудовых отноше
Anthony Liguori wrote:
> What about switching the KVM MMU code to use hfn_t instead of struct
> page? The initial conversion is pretty straight forward as the places
> where you actually need a struct page you can always get it from
> pfn_to_page() (like in kvm_release_page_dirty).
>
> We can th
Anthony Liguori wrote:
>
> You could get away with supporting reserved RAM another way though.
> If we refactored the MMU to use hfn_t instead of struct page, you
> would then need a mechanism to mmap() reserved ram into userspace
> (similar to ioremap I guess). In fact, you may be able to jus
Changed to be a soft and clear saying. Thanks! :-)
Xiantao
Jes Sorensen wrote:
> Zhang, Xiantao wrote:
>>> From 5c70c038c57190144390ae9d30c3d06afba103d4 Mon Sep 17 00:00:00
>>> 2001
>> From: Xiantao Zhang <[EMAIL PROTECTED]>
>> Date: Tue, 1 Apr 2008 14:59:30 +0800
>> Subject: [PATCH] KVM:IA64 : A
Fixed. Thanks :)
Jes Sorensen wrote:
> Zhang, Xiantao wrote:
>>> From 0d698efed15759b49e78adcef085feda0a14a175 Mon Sep 17 00:00:00
>>> 2001
>> From: Xiantao Zhang <[EMAIL PROTECTED]>
>> Date: Tue, 1 Apr 2008 14:57:09 +0800
>> Subject: [PATCH] KVM:IA64: Add optimization for some virtulization
>> f
Hi,
I have been working on a port of bochs bios to gcc. This port is
nearly complete. The new code does not rely on bcc or dev86.
Instead, it uses standard gcc and gas. It should compile on any
recent Linux distribution.
I'm sending this email because I understand kvm has a copy of bochs
bios
Бухгалтepский учeт и налогообложeниe пpи осущeствлeнии капитальных вложeний и
жилищного стpоитeльства
Однoднeвный сeминаp / 7 апpeля 2008 г. / Мoсква
Пpoгpамма сeминаpа:
1. Понятиe инвeстиций в капитальныe вложeния.
Субъeкты капитальных вложeний. Инвeстоp, пользоватeль, заказчик, подpядчик.
On Tue, Apr 01, 2008 at 10:22:51PM +0300, Avi Kivity wrote:
> It's just something we discussed, not code.
Yes, the pfn_valid check should skip all refcounting for mmio regions
without a struct page. But gfn_to_page can't work without a struct
page, so some change will be needed there. With the res
Andrea Arcangeli wrote:
> On Tue, Apr 01, 2008 at 01:21:37PM -0500, Anthony Liguori wrote:
>
>> return a page, not a HPA. I haven't looked too deeply yet, but my
>> suspicion is that to properly support mapping in VM_IO pages will require
>> some general refactoring since we always assume tha
On Tue, Apr 01, 2008 at 01:21:37PM -0500, Anthony Liguori wrote:
> return a page, not a HPA. I haven't looked too deeply yet, but my
> suspicion is that to properly support mapping in VM_IO pages will require
> some general refactoring since we always assume that a struct page exists
> for any
On Tue, 2008-04-01 at 16:18 -0500, Hollis Blanchard wrote:
> The point is that a virtio device appears as a PCI device. Like all
> other PCI devices, it has config space. Unlike all other PCI devices,
> its config space is accessed with 1-byte reads.
Which is weirdo ... it you guys make it look l
On Tue, 2008-04-01 at 16:03 -0500, Anthony Liguori wrote:
> Benjamin Herrenschmidt wrote:
> > On Tue, 2008-04-01 at 12:09 -0500, Anthony Liguori wrote:
> >
> >
> >> It's the unfortunate side-effect of using PCI config space without
> >> passing it's semantics through to the virtio devices. Rig
> > Config space should be 8/16/32. Is that ever bridged to real PCI config
> > space anyway ? Or only virtio ? And it should be endian swapped at the
> > low level, either by your HV calls or by the low level kernel. Always.
> > That's how PCI config space is supposed to work.
> >
>
> I guess
Benjamin Herrenschmidt wrote:
> On Tue, 2008-04-01 at 12:09 -0500, Anthony Liguori wrote:
>
>
>> It's the unfortunate side-effect of using PCI config space without
>> passing it's semantics through to the virtio devices. Right now, you do
>> a config_get which is basically a memcpy. If we di
The conversion to a rwsem allows callbacks during rmap traversal
for files in a non atomic context. A rw style lock also allows concurrent
walking of the reverse map. This is fairly straightforward if one removes
pieces of the resched checking.
[Restarting unmapping is an issue to be discussed].
A simple test program (well actually a pair). They are fairly easy to use.
NOTE: the xpmem.h is copied from the kernel/drivers/misc/xp/xpmem.h
file.
Type make. Then from one session, type ./A1. Grab the first
line of output which should begin with ./A2 and paste the whole line
into a second se
We no longer abort unmapping in unmap vmas because we can reschedule while
unmapping since we are holding a semaphore. This would allow moving more
of the tlb flusing into unmap_vmas reducing code in various places.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
include/linux/mm.h |
[Note that I will be giving talks next week at the OpenFabrics Forum
and at the Linux Collab Summit in Austin on memory pinning etc. It would
be great if I could get some feedback on the approach then]
V1->V2:
- Additional optimizations in the VM
- Convert vm spinlocks to rw sems.
- Add XPMEM driv
Move the tlb flushing into free_pgtables. The conversion of the locks
taken for reverse map scanning would require taking sleeping locks
in free_pgtables(). Moving the tlb flushing into free_pgtables allows
sleeping in parts of free_pgtables().
This means that we do a tlb_finish_mmu() before freei
This patch adds a lock ordering rule to avoid a potential deadlock when
multiple mmap_sems need to be locked.
Signed-off-by: Dean Nelson <[EMAIL PROTECTED]>
---
mm/filemap.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-2.6/mm/filemap.c
===
This patch implements a simple callback for device drivers that establish
their own references to pages (KVM, GRU, XPmem, RDMA/Infiniband, DMA engines
etc). These references are unknown to the VM (therefore external).
With these callbacks it is possible for the device driver to release external
re
XPMEM would have used sys_madvise() except that madvise_dontneed()
returns an -EINVAL if VM_PFNMAP is set, which is always true for the pages
XPMEM imports from other partitions and is also true for uncached pages
allocated locally via the mspec allocator. XPMEM needs zap_page_range()
functionalit
Convert the anon_vma spinlock to a rw semaphore. This allows concurrent
traversal of reverse maps for try_to_unmap and page_mkclean. It also
allows the calling of sleeping functions from reverse map traversal.
An additional complication is that rcu is used in some context to guarantee
the presence
On Tue, 2008-04-01 at 12:09 -0500, Anthony Liguori wrote:
> It's the unfortunate side-effect of using PCI config space without
> passing it's semantics through to the virtio devices. Right now, you do
> a config_get which is basically a memcpy. If we didn't do accesses with
> ioread8(), you
Avi Kivity wrote:
> Ben-Ami Yassour1 wrote:
>
>>
>>
>
> Not enough. How do you know if this calling process has permissions to
> access that pci device (I retract my previous "pci passthrough is as
> rootish as you get" remark).
>
>
>> What do you think? Given that the shadow page
Ben-Ami Yassour1 wrote:
>>
>> Can you explain why you're not using the regular memory slot mechanism?
>> i.e. have userspace mmap(/dev/mem) and create a memslot containing that
>> at the appropriate guest physical address?
>>
>>
> Our initial approach was to mmap /sys/bus/pci/devices/.../resou
Avi Kivity <[EMAIL PROTECTED]> wrote on 01/04/2008 16:30:00:
> [EMAIL PROTECTED] wrote:
> > From: Ben-Ami Yassour <[EMAIL PROTECTED]>
> >
> > Enable a guest to access a device's memory mapped I/O regions directly.
> > Userspace sends the mmio regions that the guest can access. On the
first
> > p
Anthony Liguori wrote:
> I looked at Andrea's patches and I didn't see any special handling for
> non-RAM pages. Something Muli mentioned that kept them from doing
> /sys/devices/pci/.../region to begin with was the fact that IO pages do
> not have a struct page backing them so get_user_pages()
Andrea Arcangeli wrote:
> On Tue, Apr 01, 2008 at 10:20:49AM -0500, Anthony Liguori wrote:
>
>> Which is apparently entirely unnecessary as we already have
>> /sys/bus/pci/.../region. It's just a matter of checking if a vma is VM_IO
>> and then dealing with the subsequent reference counting i
Andrea Arcangeli wrote:
> On Tue, Apr 01, 2008 at 06:18:07PM +0100, Daniel P. Berrange wrote:
>
>> and very few application domains are allowed to access them. THe KVM/QEMU
>> policy will not allow this for example. Basically on the X server, HAL and
>> dmidecode have access in current policy. I
Avi Kivity wrote:
> Anthony Liguori wrote:
>> Avi Kivity wrote:
>>> [EMAIL PROTECTED] wrote:
>>>
From: Ben-Ami Yassour <[EMAIL PROTECTED]>
Enable a guest to access a device's memory mapped I/O regions
directly.
Userspace sends the mmio regions that the guest can access.
On Tue, Apr 01, 2008 at 08:10:31PM +0200, Andrea Arcangeli wrote:
> On Tue, Apr 01, 2008 at 06:18:07PM +0100, Daniel P. Berrange wrote:
> > and very few application domains are allowed to access them. THe KVM/QEMU
> > policy will not allow this for example. Basically on the X server, HAL and
> > dm
On Tue, Apr 01, 2008 at 10:20:49AM -0500, Anthony Liguori wrote:
> Which is apparently entirely unnecessary as we already have
> /sys/bus/pci/.../region. It's just a matter of checking if a vma is VM_IO
> and then dealing with the subsequent reference counting issues as Avi
> points out.
Do yo
On Tue, Apr 01, 2008 at 06:18:07PM +0100, Daniel P. Berrange wrote:
> and very few application domains are allowed to access them. THe KVM/QEMU
> policy will not allow this for example. Basically on the X server, HAL and
> dmidecode have access in current policy. It would be undesirable to have to
On Tue, Apr 01, 2008 at 08:03:14PM +0300, Avi Kivity wrote:
> Anthony Liguori wrote:
> > Avi Kivity wrote:
> >> [EMAIL PROTECTED] wrote:
> >>
> >>> From: Ben-Ami Yassour <[EMAIL PROTECTED]>
> >>>
> >>> Enable a guest to access a device's memory mapped I/O regions directly.
> >>> Userspace sends t
Jonathan Underwood wrote:
> Hi,
>
> I am trying to run Windows XP pro as a guest under kvm. The host
> system is Fedora 8. I have seen this behaviour with kvm-60 (as
> currently packaged for Fedora 8) and kvm-64 (using the rawhide
> package).
>
> Essentially, I install XP Pro successfuly. When I th
Hollis Blanchard wrote:
>
> Thanks Anthony, you've saved me a lot of debug time! Rusty, doing 64-bit
> PCI config space accesses with ioread8() definitely violates the
> principle of least surprises, and would have taken me a long time to
> track down. :(
>
It's the unfortunate side-effect of u
Hollis Blanchard wrote:
> On Tue, 2008-04-01 at 09:46 -0500, Anthony Liguori wrote:
>
> Thanks Anthony, you've saved me a lot of debug time! Rusty, doing 64-bit
> PCI config space accesses with ioread8() definitely violates the
> principle of least surprises, and would have taken me a long time
Anthony Liguori wrote:
>>
>> Regardless of whether we can use /dev/mem, I think we should
>> introduce a new char device anyway. We only need to mmap() MMIO
>> regions which are mapped by the PCI bus, presumably, the kernel
>> should know about these mappings. The driver should only allow
>>
Anthony Liguori wrote:
> Avi Kivity wrote:
>> [EMAIL PROTECTED] wrote:
>>
>>> From: Ben-Ami Yassour <[EMAIL PROTECTED]>
>>>
>>> Enable a guest to access a device's memory mapped I/O regions directly.
>>> Userspace sends the mmio regions that the guest can access. On the
>>> first
>>> page fault
On Tue, 2008-04-01 at 11:04 -0500, Anthony Liguori wrote:
> The virtio config space is little endian. Make sure that in virtio-blk we
> store the values in little endian format.
>
> Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
>
> diff --git a/qemu/hw/virtio-blk.c b/qemu/hw/virtio-blk.c
>
On 01.04.2008 Jonathan Underwood wrote:
Essentially, I install XP Pro successfuly. When I then try and run the
SP2 exe in order to update it to SP2, KVM always freezes at the point
where is says "Running post install processes).
Hi Jonathan,
the problem looks similar to the Win2003 Server
On Tue, 2008-04-01 at 09:46 -0500, Anthony Liguori wrote:
> Hollis Blanchard wrote:
> > On Tue, 2008-04-01 at 14:08 +0200, Christian Ehrhardt wrote:
> >> bash-3.00# cat /proc/partitions
> >> major minor #blocks name
> >> [...]
> >> 254 0 22517998136852480 vda <- ?broken?
> >>
The virtio config space is little endian. Make sure that in virtio-blk we
store the values in little endian format.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/hw/virtio-blk.c b/qemu/hw/virtio-blk.c
index 0f55d2a..492bd7f 100644
--- a/qemu/hw/virtio-blk.c
+++ b/qemu/hw/v
Jes Sorensen wrote:
> Jeremy Fitzhardinge wrote:
>
>> Jes Sorensen wrote:
>> This change has been on the x86 side for ages, and not even Ingo made a
>> peep about it ;)
>>
>
> Mmmm, last time I looked, x86 didn't scale to any interesting number
> of CPUs :-)
>
Well, I guess you need al
Your hot secret admirer
Just one look at you and all th girls will not be able to resist you.
http://www.deceiname.com/
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just ab
Next I'm going to test on 2.6.25-rc7-git5 with KVM-64.
Running on 2.6.25-rc7-git5 with KVM 64 for 48 hours now and no more hangs!
Note that the longest uptime of the Windows 2003 Std guest was around 20
hours before.
So it *seems* that 2.6.25 does indeed solve the problem, although a
couple m
Zhang, Xiantao wrote:
>>From 5c70c038c57190144390ae9d30c3d06afba103d4 Mon Sep 17 00:00:00 2001
> From: Xiantao Zhang <[EMAIL PROTECTED]>
> Date: Tue, 1 Apr 2008 14:59:30 +0800
> Subject: [PATCH] KVM:IA64 : Add kvm sal/pal virtulization support.
>
> Some sal/pal calls would be traped to kvm for vir
Anthony Liguori wrote:
> Avi Kivity wrote:
>> [EMAIL PROTECTED] wrote:
>>
>>> From: Ben-Ami Yassour <[EMAIL PROTECTED]>
>>>
>>> Enable a guest to access a device's memory mapped I/O regions directly.
>>> Userspace sends the mmio regions that the guest can access. On the
>>> first
>>> page fault
Zhang, Xiantao wrote:
>>From 0d698efed15759b49e78adcef085feda0a14a175 Mon Sep 17 00:00:00 2001
> From: Xiantao Zhang <[EMAIL PROTECTED]>
> Date: Tue, 1 Apr 2008 14:57:09 +0800
> Subject: [PATCH] KVM:IA64: Add optimization for some virtulization
> faults
>
> optvfault.S Add optimization for some pe
The kvm_host.h file for x86 declares the functions kvm_set_cr[0348]. In the
header file their second parameter is named cr0 in all cases. This patch
renames the parameters so that they match the function name.
Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>
---
include/asm-x86/kvm_host.h |6 +
Hi,
I am trying to run Windows XP pro as a guest under kvm. The host
system is Fedora 8. I have seen this behaviour with kvm-60 (as
currently packaged for Fedora 8) and kvm-64 (using the rawhide
package).
Essentially, I install XP Pro successfuly. When I then try and run the
SP2 exe in order to u
Avi Kivity wrote:
> [EMAIL PROTECTED] wrote:
>
>> From: Ben-Ami Yassour <[EMAIL PROTECTED]>
>>
>> Enable a guest to access a device's memory mapped I/O regions directly.
>> Userspace sends the mmio regions that the guest can access. On the first
>> page fault for an access to an mmio address the
[EMAIL PROTECTED] wrote:
> From: Ben-Ami Yassour <[EMAIL PROTECTED]>
>
> Enable a guest to access a device's memory mapped I/O regions directly.
> Userspace sends the mmio regions that the guest can access. On the first
> page fault for an access to an mmio address the host translates the gva to
>
On Tue, Apr 01 2008, Andrea Arcangeli wrote:
> Looking a bit closer into this regression the reason this can't be
> right is that dma_addr common default is BLK_BOUNCE_HIGH and most
> machines have less than 4G. So if you do:
>
> if (b_pfn <= (min_t(u64, 0x, BLK_BOUNCE_HIGH) >> PAGE_SH
From: Ben-Ami Yassour <[EMAIL PROTECTED]>
Enable a guest to access a device's memory mapped I/O regions directly.
When the guest changes the I/O memory mappings for a passthrough device,
send the updated mmio region to the kernel.
Signed-off-by: Ben-Ami Yassour <[EMAIL PROTECTED]>
Signed-off-by:
This patch for PCI passthrough devices enables a guest to access a device's
memory mapped I/O regions directly, without requiring the host to trap and
emulate every MMIO access. We save the list of MMIO regions of the guest's
devices and the corresponding host MMIO regions in the host kernel. When
Zhang, Xiantao wrote:
> Carsten Otte wrote:
>> Zhang, Xiantao wrote:
>>> Carsten Otte wrote:
Zhang, Xiantao wrote:
> Hi, Carsten
> Why do you think it is racy? In this function,
> target_vcpu->arch.launched should be set to 1 for the first run,
> and keep its value all th
From: Ben-Ami Yassour <[EMAIL PROTECTED]>
Enable a guest to access a device's memory mapped I/O regions directly.
Userspace sends the mmio regions that the guest can access. On the first
page fault for an access to an mmio address the host translates the gva to hpa,
and updates the sptes.
Signed-
Hi Andrea,
This patch works well on my machine. Thanks.
Best Regards,
Yang
Andrea Arcangeli ??:
> Looking a bit closer into this regression the reason this can't be
> right is that dma_addr common default is BLK_BOUNCE_HIGH and most
> machines have less than 4G. So if you do:
>
> if (b_pfn <
Zhang, Xiantao wrote:
> Hi, All
> According to the comments from V8, I refined the code, and worked out
> the new patchset. Please help to review. Thanks! :-)
> In this new version, most of typdefs are removed to comply with the
> requirement of coding style. Fixed the issues found by reviewers.
Carsten Otte wrote:
> Zhang, Xiantao wrote:
>> Carsten Otte wrote:
>>> Zhang, Xiantao wrote:
Hi, Carsten
Why do you think it is racy? In this function,
target_vcpu->arch.launched should be set to 1 for the first run,
and keep its value all the time. Except the first IPI t
Zhang, Xiantao wrote:
> Carsten Otte wrote:
>> Zhang, Xiantao wrote:
>>> Hi, Carsten
>>> Why do you think it is racy? In this function,
>>> target_vcpu->arch.launched should be set to 1 for the first run, and
>>> keep its value all the time. Except the first IPI to wake up the
>>> vcpu, all
>From b4d573038915205c7b85740bf80bd0e0c82a702a Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Tue, 1 Apr 2008 14:49:24 +0800
Subject: [PATCH] KVM:IA64 : VMM module interfaces.
vmm.c adds the interfaces with kvm/module, and initialize global data
area.
Signed-off-by: Xiantao
For considering Jes's performance concern, I kept the old
smp_call_function, and add smp_call_function_mask separately.
Xiantao
>From fe3c5deac39033fb7651ecce5df3d1dce7dd66f7 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Tue, 1 Apr 2008 14:38:21 +0800
Subject: [PATCH] IA
>From 6fcd534964e91d409ee4dba39c393dc7cf019b97 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Tue, 1 Apr 2008 14:53:32 +0800
Subject: [PATCH] KVM:IA64 : Add mmio decoder for kvm/ia64.
mmio.c includes mmio decoder, and related mmio logics..
Signed-off-by: Anthony Xu <[EMAIL
>From 5c70c038c57190144390ae9d30c3d06afba103d4 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Tue, 1 Apr 2008 14:59:30 +0800
Subject: [PATCH] KVM:IA64 : Add kvm sal/pal virtulization support.
Some sal/pal calls would be traped to kvm for virtulization
from guest firmware.
S
>From 2d624a8e44bb284224820cd61fe2f0975c029fda Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Tue, 1 Apr 2008 14:50:59 +0800
Subject: [PATCH] KVM:IA64 : Add TLB virtulization support.
vtlb.c includes tlb/VHPT virtulization.
Signed-off-by: Anthony Xu <[EMAIL PROTECTED]>
Sign
>From 365a0bb8b49354f9111b5745edb21b5e153784d9 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Tue, 1 Apr 2008 15:08:29 +0800
Subject: [PATCH] KVM: IA64: A Guide about how to create kvm guests on
ia64
Guide for creating virtual machine on kvm/ia64.
Signed-off-by: Xiantao Zha
>From fe8c760aad0b51bad533c608d23ba460f0c46446 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Fri, 28 Mar 2008 14:58:47 +0800
Subject: [PATCH] KVM:IA64 Enable kvm build for ia64
Update the related Makefile and Kconfig for kvm build
Signed-off-by: Xiantao Zhang <[EMAIL PROTE
Looking a bit closer into this regression the reason this can't be
right is that dma_addr common default is BLK_BOUNCE_HIGH and most
machines have less than 4G. So if you do:
if (b_pfn <= (min_t(u64, 0x, BLK_BOUNCE_HIGH) >> PAGE_SHIFT))
dma = 1
that will translate to:
if
>From 759f98f6cb61f5f6064180562656ef052f38490c Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Tue, 1 Apr 2008 14:45:06 +0800
Subject: [PATCH] KVM: IA64: Add header files for kvm/ia64.
Three header files are added:
asm-ia64/kvm.h
asm-ia64/kvm_host.h
asm-ia64/kvm_para.h
Signe
>From 0d698efed15759b49e78adcef085feda0a14a175 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Tue, 1 Apr 2008 14:57:09 +0800
Subject: [PATCH] KVM:IA64: Add optimization for some virtulization
faults
optvfault.S Add optimization for some performance-critical
virtualization f
>From 10d254b2fdb93a366a2f3f29e17f6c1dfbb6e0a6 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Tue, 1 Apr 2008 14:57:53 +0800
Subject: [PATCH] KVM:IA64 : Generate offset values for assembly code
use.
asm-offsets.c will generate offset values used for assembly code
for some f
>From 7f1714377e6d5812b4557bb3ccd8268b57865952 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Tue, 1 Apr 2008 14:42:00 +0800
Subject: [PATCH] KVM: IA64 : Prepare some structure definitions and
routines for kvm use.
Register structures are defined per SDM.
Add three small ro
Hi, All
According to the comments from V8, I refined the code, and worked out
the new patchset. Please help to review. Thanks! :-)
In this new version, most of typdefs are removed to comply with the
requirement of coding style. Fixed the issues found by reviewers. Thanks
for your effort!
The whol
>From b0c5c7fc45bbe0f56efba28e814ccb67b8c8 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Tue, 1 Apr 2008 14:34:50 +0800
Subject: [PATCH] IA64: Add API for allocating Dynamic TR resource.
Dynamic TR resource should be managed in the uniform way.
Add two interfaces for k
倡议书.doc
Description: Binary data
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http
Carsten Otte wrote:
> Zhang, Xiantao wrote:
>> Hi, Carsten
>> Why do you think it is racy? In this function,
>> target_vcpu->arch.launched should be set to 1 for the first run, and
>> keep its value all the time. Except the first IPI to wake up the
>> vcpu, all IPIs received by target vcpu s
Jes Sorensen wrote:
> Zhang, Xiantao wrote:
>>> From 6b731c15afa8cec84f16408c421c286f1dd1b7d3 Mon Sep 17 00:00:00
>>> 2001
>> From: Xiantao Zhang <[EMAIL PROTECTED]>
>> Date: Wed, 12 Mar 2008 13:45:40 +0800
>> Subject: [PATCH] KVM:IA64 : Add TLB virtulization support.
>>
>> vtlb.c includes tlb/VH
Zhang, Xiantao wrote:
>>From 6b731c15afa8cec84f16408c421c286f1dd1b7d3 Mon Sep 17 00:00:00 2001
> From: Xiantao Zhang <[EMAIL PROTECTED]>
> Date: Wed, 12 Mar 2008 13:45:40 +0800
> Subject: [PATCH] KVM:IA64 : Add TLB virtulization support.
>
> vtlb.c includes tlb/VHPT virtulization.
> Signed-off-by:
Jeremy Fitzhardinge wrote:
> Jes Sorensen wrote:
> This change has been on the x86 side for ages, and not even Ingo made a
> peep about it ;)
Mmmm, last time I looked, x86 didn't scale to any interesting number
of CPUs :-)
>> Why not keep smp_call_function() the way it was before, rather than
>>
Zhang, Xiantao wrote:
> Hi, Carsten
> Why do you think it is racy? In this function,
> target_vcpu->arch.launched should be set to 1 for the first run, and
> keep its value all the time. Except the first IPI to wake up the vcpu,
> all IPIs received by target vcpu should go into "else" condi
Zhang, Xiantao wrote:
> Carsten Otte wrote:
>> Zhang, Xiantao wrote:
>>> +/* mca_insert_tr
>>> + *
>>> + * Switch rid when TR reload and needed!
>>> + * iord: 1: itr, 2: itr;
>>> + *
>>> +*/
>>> +static void mca_insert_tr(u64 iord)
>>> +{
>>> +
>>> + int i;
>>> + u64 old_rr;
>>> + struct i
88 matches
Mail list logo