This patch adds paravirt-ops hooks in pv_mmu_ops for ptep_modify_prot_start and
ptep_modify_prot_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 +++
Hi all,
[ Change since last post: change name to ptep_modify_prot_, on the
grounds that it isn't really a general pte-modification interface. ]
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 has a pte update function which will update a pte while preserving
its accessed and dirty bits. This means that ptep_modify_prot_start() can be
implemented as a simple read of the pte value. The hardware may
update the pte in the meantime, but ptep_modify_prot_commit() updates it while
This patch adds an API for doing read-modify-write updates to a pte's
protection bits 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.
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
Avi Kivity wrote:
This all looks pretty good. How do you want this to get into the
kernel?
[ note: fixed up kvm list address: s/-owner// ]
Good question. The kvm patches have dependencies on not-yet merged
bits, so they have to go through the kvm queue. The first two can also
On Mon, 16 Jun 2008, Jeremy Fitzhardinge wrote:
ptep_modify_prot_start() returns the current pte value, and puts the
pte entry into a state where either the hardware will not update the
pte, or if it does, the updates will be preserved on commit.
ptep_modify_prot_commit() writes back
On Mon, 16 Jun 2008, Linus Torvalds wrote:
On Mon, 16 Jun 2008, Jeremy Fitzhardinge wrote:
ptep_modify_prot_start() returns the current pte value, and puts the
pte entry into a state where either the hardware will not update the
pte, or if it does, the updates will be preserved on
* Hugh Dickins [EMAIL PROTECTED] wrote:
On Mon, 16 Jun 2008, Linus Torvalds wrote:
On Mon, 16 Jun 2008, Jeremy Fitzhardinge wrote:
ptep_modify_prot_start() returns the current pte value, and puts the
pte entry into a state where either the hardware will not update the
pte, or
On Sun, Jun 15 2008, Jeremy Fitzhardinge wrote:
Jens Axboe wrote:
On Fri, Jun 13 2008, Jeremy Fitzhardinge wrote:
Randy Dunlap wrote:
next-20080613 on x86_32 has lots of xen build errors like this:
linux-next-20080613/arch/x86/xen/mmu.c: In function 'drop_mm_ref':
On Mon, Jun 16, 2008 at 02:41:41PM +1000, Rusty Russell wrote:
From: Mark McLoughlin [EMAIL PROTECTED]
hdr-csum_start is the offset from the start of the ethernet
header to the transport layer checksum field. skb-csum_start
is the offset from skb-head.
skb_partial_csum_set() assumes that
Jens Axboe wrote:
Thanks, I just folded it in with the existing patch to avoid breakage.
That one doesn't have an ack from you though, so if you have done a full
review of the x86 bits, I'd appreciate an ack on those from you :-)
I've been testing it without problems, at least under Xen.
On Tuesday 17 June 2008 05:38:45 Greg KH wrote:
On Mon, Jun 16, 2008 at 02:41:41PM +1000, Rusty Russell wrote:
From: Mark McLoughlin [EMAIL PROTECTED]
hdr-csum_start is the offset from the start of the ethernet
header to the transport layer checksum field. skb-csum_start
is the offset
13 matches
Mail list logo
