On Fri, 2008-05-23 at 21:32 +0100, Jeremy Fitzhardinge wrote:
> Zachary Amsden wrote:
> > I'm a bit skeptical you can get such a semantic to work without a very
> > heavyweight method in the hypervisor. How do you guarantee no other CPU
> > is fizzling the A/D bits in the page table (it can be do
Linus Torvalds wrote:
> On Fri, 23 May 2008, Jeremy Fitzhardinge wrote:
>
>> This series adds the pte_rmw_start() and pte_rmw_commit() operations,
>> which change this sequence to:
>>
>> ptent = pte_rmw_start(mm, addr, pte);
>> ptent = pte_modify(ptent, newprot);
>> /* ... */
>>
Zachary Amsden wrote:
> I'm a bit skeptical you can get such a semantic to work without a very
> heavyweight method in the hypervisor. How do you guarantee no other CPU
> is fizzling the A/D bits in the page table (it can be done by hardware
> with direct page tables), unless you use some kind of
On Fri, 23 May 2008, Jeremy Fitzhardinge wrote:
>
> This series adds the pte_rmw_start() and pte_rmw_commit() operations,
> which change this sequence to:
>
> ptent = pte_rmw_start(mm, addr, pte);
> ptent = pte_modify(ptent, newprot);
> /* ... */
> pte_rmw_commit(mm, add
On Fri, 2008-05-23 at 15:20 +0100, Jeremy Fitzhardinge wrote:
> Hi all,
>
> This little series adds a new transaction-like abstraction for doing
> RMW updates to a pte, hooks it into paravirt_ops, and then makes use
> of it in Xen.
>
> The basic problem is that mprotect is very slow under Xen (u
This patch adds paravirt-ops hooks in pv_mmu_ops for pte_rmw_start and
pte_rmw_commit. This allows the hypervisor-specific backends to
implement these in some more efficient way.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/x86/kernel/paravirt.c |3 +++
arch/x86/xen/enligh
This patch adds an API for doing read-modify-write updates to a pte
which may race against hardware updates to the pte. After reading the
pte, the hardware may asynchonously set the accessed or dirty bits on
a pte, which would be lost when writing back the modified pte value.
The existing techniq
Hi all,
This little series adds a new transaction-like abstraction for doing
RMW updates to a pte, hooks it into paravirt_ops, and then makes use
of it in Xen.
The basic problem is that mprotect is very slow under Xen (up to 50x
slower than native), primarily because of the
ptent = ptep_
Some Xen hypercalls accept an array of operations to work on. In
general this is because its more efficient for the hypercall to the
work all at once rather than as separate hypercalls (even batched as a
multicall).
This patch adds a mechanism (xen_mc_extend_args()) to allocate more
argument spac
Xen has a pte update function which will update a pte while preserving
its accessed and dirty bits. This means that pte_rmw_start() can be
implemented as a simple read of the pte value. The hardware may
update the pte in the meantime, but pte_rmw_commit() updates it while
preserving any changes t
Add pte_flags() to extract the flags from a pte. This is a special
case of pte_val() which is only guaranteed to return the pte's flags
correctly; the page number may be corrupted or missing.
The intent is to allow paravirt implementations to return pte flags
without having to do any translation
Hi,
Just a quick question: What is the status of the two projects in
$subject? Havn't heared anything for a while for both ...
cheers,
Gerd
--
http://kraxel.fedorapeople.org/xenner/
___
Virtualization mailing list
Virtualization@lists.linux-foun
12 matches
Mail list logo
