On 08/30/2010 07:43 AM, Arnd Bergmann wrote:
Hi Hank,
I wanted to follow up on the block device driver discussion we had at
LinuxCon, based on some other input I got.
What most people recommended was to make both the hv scsi and the
hv ata code scsi device drivers, *not* make them
On 08/30/2010 10:31 AM, Hank Janssen wrote:
For a more general question, When/if we make it out of staging, where should
these drivers live?
drivers/hyper-v or drivers/scsi and drivers/ide.
Is there a standard that is being followed?
If they're not actually scsi/ide subsystem
On 07/14/2010 10:54 AM, David Miller wrote:
And doing what you're doing is foolish on so many levels. One more
duplication of code, one more place for unnecessary bugs to live, one
more place that might need optimizations and thus require duplication
of even more work people have done over
On 04/07/2010 11:20 AM, Ky Srinivasan wrote:
Jeremy, thank you for your comments. I am attaching the next version of this
patch that addresses the comments I have gotten thus far.
It looks like you overlooked a couple of comments.
+}
+
+static struct clocksource hyperv_cs = {
+
On 04/05/2010 01:30 PM, Ky Srinivasan wrote:
+static cycle_t read_hv_clock(struct clocksource *arg)
+{
+ cycle_t current_tick;
+ /*
+ * Read the partition counter to get the current tick count. This count
+ * is set to 0 when the partition is created and is incremented in
On 03/03/2010 08:42 AM, Hank Janssen wrote:
There is a pretty good chance that ring buffer on Hyper-V will change to
support
additional functionality. I did further investigations to check on other
virtualization technologies. And this same things seems to be true for XEN,
they also
On 02/10/2010 10:13 AM, Jan Engelhardt wrote:
As I was compile-testing 2.6.33-rc with gcc-3.3,
binutils-2.19.51-10.26.4.x86_64, I observed a failure when
CONFIG_PARAVIRT is turned on:
Yeah, there's a gcc bug of some kind there, and its very hard to see how
to work around it. When we
On 11/18/09 08:13, Alexander Graf wrote:
Currently when using paravirt ops it's an all-or-nothing option. We can either
use pv-ops for CPU, MMU, timing, etc. or not at all.
Now there are some use cases where we don't need the full feature set, but
only
a small chunk of it. KVM is a pretty
On 11/18/09 20:56, Alexander Graf wrote:
Currently we use pv-ops to tell linux not to do anything on io_delay.
While the basic idea is good IMHO, I don't see why we would need pv-ops
for that. The io delay function already has a switch that can do nothing
if you're so inclined.
So here's a
On 11/20/09 07:58, Alexander Graf wrote:
Am 19.11.2009 um 23:55 schrieb Jeremy Fitzhardinge jer...@goop.org:
On 11/18/09 20:56, Alexander Graf wrote:
Currently we use pv-ops to tell linux not to do anything on io_delay.
While the basic idea is good IMHO, I don't see why we would need pv-ops
On 11/20/09 09:59, Alexander Graf wrote:
On 20.11.2009, at 02:54, Jeremy Fitzhardinge wrote:
On 11/20/09 07:58, Alexander Graf wrote:
Am 19.11.2009 um 23:55 schrieb Jeremy Fitzhardinge jer...@goop.org:
On 11/18/09 20:56, Alexander Graf wrote:
Currently we use pv-ops to tell linux
On 10/13/09 07:35, James Bottomley wrote:
Yep, below is a patch with the rename, the driver is now called
vmw_pvscsi. Do let me know if you have any other comments. Thanks.
I'm still curious to know what the 'p' in the name stands for. Surely
this is a fully virtual driver, not a
On 10/02/09 12:06, Shirley Ma wrote:
On Fri, 2009-10-02 at 11:30 -0700, Jeremy Fitzhardinge wrote:
I'm assuming from the lists you've posted to that this is under KVM?
What disk drivers are you using (virtio or emulated)?
Can you get a full stack backtrace of kjournald?
Yes, it's
On 09/22/09 01:09, Ingo Molnar wrote:
kvm will be removing the pvmmu support soon; and Xen is talking about
running paravirtualized guests in a vmx/svm container where they don't
need most of the hooks.
We have no plans to drop support for non-vmx/svm capable processors,
let alone
On 09/22/09 00:22, Rusty Russell wrote:
When they're all gone, even I don't think lguest is sufficient excuse
to keep CONFIG_PARAVIRT. Oh well. But that will probably be a while.
/Solidarność/!
J
___
Virtualization mailing list
On 09/22/09 11:02, Ingo Molnar wrote:
obviously they are workload dependent - that's why numbers were posted
in this thread with various workloads. Do you concur with those
conclusions that they are generally a speedup over paravirt? If not,
which are the workloads where paravirt offers
On 09/22/09 12:30, Alok Kataria wrote:
We can certainly look at removing some paravirt-hooks which are only
used by VMI. Not sure if there are any but will take a look when we
actually remove VMI.
There are a couple:
* pte_update_defer
* alloc_pmd_clone
lguest appears to still
On 09/21/09 00:22, Rusty Russell wrote:
If we're building a pte, we can use simple assigment; only use set_pte
etc. when we're actually going to use that destination as a PTE. I
don't know that we'll ever run under Xen, but it's neater.
I've always thought it would be a Neat Thing To Try.
On 09/20/09 02:00, Avi Kivity wrote:
On 09/20/2009 10:52 AM, Arjan van de Ven wrote:
On Sun, 20 Sep 2009 09:42:47 +0200
Ingo Molnarmi...@elte.hu wrote:
If we were able to rip out all (or most) of paravirt from arch/x86 it
would be tempting for other technical reasons - but the patch
On 09/19/09 15:44, Greg KH wrote:
That sounds good to me, how intrusive are the patches to do this? Is it
going to be tricky to get everything merged properly in -tip for it?
They should be very local - just a matter of removing a couple of files
and dropping some config options.
J
On 09/09/09 16:34, Anthony Liguori wrote:
We haven't even been successful in getting the Xen folks to present
their work on lkml before shipping it to their users. Why would we
expect more from VMware if we're willing to merge the Xen stuff?
The Xen code may be out of tree, but it has
On 08/25/09 03:01, Jaswinder Singh Rajput wrote:
mk_pirq_info(), gsi_from_irq() and vector_from_irq() are static functions
and no one is calling them.
This fixed following compilation warnings :
drivers/xen/events.c:134: warning: ‘mk_pirq_info’ defined but not used
On 08/25/09 14:00, Jiri Slaby wrote:
To avoid a wrong compiler warning, use unitialized_var(cx) in
xen_init_cpuid_mask.
cx needn't be initialized for cpuid when ax is 1.
Signed-off-by: Jiri Slaby jirisl...@gmail.com
Cc: Jeremy Fitzhardinge jer...@xensource.com
Cc: Chris Wright chr...@sous
On 08/04/09 10:33, Peter Zijlstra wrote:
On Tue, 2009-08-04 at 19:29 +0200, Martin Schwidefsky wrote:
So its going to split user time into user and guest. Does that really
make sense? For the host kernel it really is just another user process,
no?
The code (at least in parts) is
Matias Zabaljauregui wrote:
Jeremy, I fixed the code following your comments (hope you still
remember).
I'd like to ask you again about this one:
/* Found in switcher.S */
extern unsigned long default_idt_entries[];
diff --git a/arch/x86/include/asm/lguest_hcall.h
Roel Kluin wrote:
Do not go beyond ARRAY_SIZE of info-shadow
Signed-off-by: Roel Kluin roel.kl...@gmail.com
Acked-by: Jeremy Fitzhardinge jeremy.fitzhardi...@citrix.com
Jens, can you put this into a next-merge-window branch?
Thanks,
J
---
diff --git a/drivers/block/xen-blkfront.c b
Roel Kluin wrote:
To avoid direct access to the driver_data pointer in struct device, the
functions dev_get_drvdata() and dev_set_drvdata() should be used.
Are these the same as the ones Greg KH posted last week?
J
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
diff --git
M A Young wrote:
On Tue, 5 May 2009, Randy Dunlap wrote:
From: Randy Dunlap randy.dun...@oracle.com
When a driver kconfig symbol =m and it selects another symbol,
that other symbol will also be =m (unless something else
causes it to be =y), so when XEN_BLKDEV_FRONTEND=m and/or
Chris Wright wrote:
* Greg KH (g...@kroah.com) wrote:
Thanks, will add it. Any objections for this to go through my
driver-core tree to Linus for 2.6.31?
None from me.
Fine by me.
Acked-by: Jeremy Fitzhardinge jeremy.fitzhardi...@citrix.com
J
Matias Zabaljauregui wrote:
Hi,
For some days I have been looking for the bug that causes an easily
reproducible oops in the guest
when I apply my PAE support _draft_ patch (appended at the end of this mail)
to lguest.
Good, lguest has needed PAE support for a while. Do you
Martin Schwidefsky wrote:
This is the basic idea of guest page hinting. Let the host memory
manager make it decision based on the data it has. That includes page
age determined with a global LRU list, page age determined with a
per-guest LRU list, i/o rates of the guests, all kind of policy
Martin Schwidefsky wrote:
I still think this needs much more justification.
Ok, I can understand that. We probably need a KVM based version to show
that benefits exist on non-s390 hardware as well.
BTW, there was a presentation at the most recent Xen summit which makes
use of CMM
Rik van Riel wrote:
Page hinting has a complex, but well understood, mechanism
and simple policy.
For the guest perhaps, and yes, it does push the problem out to the
host. But that doesn't make solving a performance problem any easier if
you end up in a mess.
Ballooning has a simpler
Rik van Riel wrote:
Jeremy Fitzhardinge wrote:
The more complex host policy decisions of how to balance overall
memory use system-wide are much in the same for both mechanisms.
Not at all. Page hinting is just an optimization to host swapping, where
IO can be avoided on many of the pages
Rik van Riel wrote:
I guess we could try to figure out a simple and robust policy
for ballooning. If we can come up with a policy which nobody
can shoot holes in by just discussing it, it may be worth
implementing and benchmarking.
Maybe something based on the host passing memory pressure
Dave Hansen wrote:
It also occurs to me that the hypervisor could be doing a lot of this
internally. This whole scheme is about telling the hypervisor about
pages that we (the kernel) know we can regenerate. The hypervisor
should know a lot of that information, too. We ask it to populate a
Rik van Riel wrote:
Jeremy Fitzhardinge wrote:
That said, people have been looking at tracking block IO to work out
when it might be useful to try and share pages between guests under Xen.
Tracking block IO seems like a bass-ackwards way to figure
out what the contents of a memory page
Rik van Riel wrote:
Jeremy Fitzhardinge wrote:
Rik van Riel wrote:
Jeremy Fitzhardinge wrote:
That said, people have been looking at tracking block IO to work
out when it might be useful to try and share pages between guests
under Xen.
Tracking block IO seems like a bass-ackwards way
Rusty Russell wrote:
You can't just do this in tlb flush?
I don't think so. The problem is that lguest tracks 4 toplevels, using random
replacement. This cache is indexed by cr3 value.
Lguest assumes it's told about all pte removals or changes, but simple
additions get faulted in.
Rusty Russell wrote:
Impact: potential bugfix
In theory, the kernel could reuse the same page as pgdir for a new process
while the hypervisor keeps it cached. This would have undesirable results.
You can't just do this in tlb flush?
J
Signed-off-by: Rusty Russell
Jiri Kosina wrote:
Noone seems to have picked this so far, so I have applied it to trivial
tree. Thanks,
I've got it queued up, but I'm sure we'll be able to resolve any
conflicts if it goes via both paths...
J
___
Virtualization mailing list
Alok Kataria wrote:
Hi,
I am not sure, but I think this may be a process accounting bug.
If interrupts are disabled for a considerable amount of time ( say
multiple ticks), the process accounting code will still account a single
tick for such cases, on the next interrupt tick.
Shouldn't we
Alok Kataria wrote:
I don't know if their are instances when interrupts are actually
disabled for such a long time in the kernel , but I don't see a reason
why this might not be happening currently, i.e. do we have a way to
detect such cases.
I noticed this problem ( with process accounting)
Hannes Eder wrote:
Fix this sparse warnings:
arch/x86/xen/smp.c:316:52: warning: Using plain integer as NULL pointer
arch/x86/xen/smp.c:421:60: warning: Using plain integer as NULL pointer
Signed-off-by: Hannes Eder han...@hanneseder.net
Acked-by: Jeremy Fitzhardinge jeremy.fitzhardi
Rose, Gregory V wrote:
-Original Message-
From: Jesse Barnes [mailto:jbar...@virtuousgeek.org]
On Wednesday, December 17, 2008 8:44 am Rose, Gregory V wrote:
As noted in the attached email to the netdev list, we (e1000_devel) will
support the API.
Do you think you'll
Anthony Liguori wrote:
David Miller wrote:
From: Gleb Natapov g...@redhat.com
Date: Sun, 14 Dec 2008 13:50:55 +0200
It is undesirable to use TCP/IP for this purpose since network
connectivity may not exist between host and guest and if it exists the
traffic can be not routable
Anthony Liguori wrote:
Jeremy Fitzhardinge wrote:
Each of these sockets are going to be connected to a backend (to
implement guest=copy/paste for instance). We want to implement
those backends in userspace and preferably in QEMU.
Using some raw protocol over ethernet means you don't
Anthony Liguori wrote:
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
That seems unnecessarily complex.
Well, the simplest thing is to let the host TCP stack do TCP. Could
you go into more detail about why you'd want to avoid that?
The KVM model is that a guest is a process. Any
Luck, Tony wrote:
+++ b/arch/ia64/include/asm/pvclock-abi.h
@@ -0,0 +1,5 @@
+/*
+ * use same structure to x86's
+ * Hopefully asm-x86/pvclock-abi.h would be moved to somewhere more generic.
+ */
+#include asm-x86/pvclock-abi.h
I will trade out this patch for one that just makes
a copy
H. Peter Anvin wrote:
And you're absolutely right that the guest may end up picking and
choosing different parts of the interfaces. That's how it is supposed
to work.
No, that would be a horrible, horrible mistake. There's no sane way to
implement that; it would mean that the hypervisor
H. Peter Anvin wrote:
Jeremy Fitzhardinge wrote:
The big difference here is that you could create a VM at runtime (by
combining the existing interfaces) that did not exist before (or was
not tested before). For example, a hypervisor could show hyper-v,
osx-v (if any), linux-v, etc
Alok Kataria wrote:
Hi,
Please find below the proposal for the generic use of cpuid space
allotted for hypervisors. Apart from this cpuid space another thing
worth noting would be that, Intel AMD reserve the MSRs from 0x4000
- 0x40FF for software use. Though the proposal doesn't
H. Peter Anvin wrote:
Jeremy Fitzhardinge wrote:
No, we're not getting anywhere. This is an outright broken idea.
The space is too small to be able to chop up in this way, and the
number of vendors too large to be able to do it without having a
central oversight.
I suspect we can get
H. Peter Anvin wrote:
With a sufficiently large block, we could use fixed points, e.g. by
having each vendor create interfaces in the 0x40XX range, where
is the PCI ID they use for PCI devices.
Sure, you could do that, but you'd still want to have a signature in
0x4000 to
H. Peter Anvin wrote:
What you'd want, at least, is a standard CPUID identification and
range leaf at the top. 256 leaves is a *lot*, though; I'm not saying
one couldn't run out, but it'd be hard. Keep in mind that for large
objects there are counting CPUID levels, as much as I personally
Anthony Liguori wrote:
Mmm, cpuid bikeshedding :-)
My shade of blue is better.
The space 0x4000-0x40ff is reserved for hypervisor usage.
This region is divided into 16 16-leaf blocks. Each block has the
structure:
0x40x0:
eax: max used leaf within the leaf block (max
Alok Kataria wrote:
1. Kernel complexity : Just thinking about the complexity that this will
put in the kernel to handle these multiple ABI signatures and scanning
all of these leaf block's is difficult to digest.
The scanning for the signatures is trivial; it's not a significant
amount
Rusty Russell wrote:
This is the last use of (the deprecated) stop_machine_run in the tree.
OK, thanks.
Signed-off-by: Rusty Russell [EMAIL PROTECTED]
Acked-by: Jeremy Fitzhardinge [EMAIL PROTECTED]
diff -r 332ec042cb4d drivers/xen/manage.c
--- a/drivers/xen/manage.cWed Aug 13
Alexey Eremenko wrote:
Jeremy: Mr. Grant speaking about the future where Linux (2.6.28?)
mainline kernel will support Xen Dom0, not kernel 2.6.27, which only
improves Xen DomU.
And I agree with Grant, that if Linux mainline will have Dom0
included, that may cause problems for all kinds of
Grant McWilliams wrote:
I wasn't really trying to run VBox in the dom0. I'd been running the
Xen kernel so long that I'd forgotten which
kernel I was on. Like I said when you start VMware the guest OS just
doesn't run which gives you a second
to ponder why. VBox uses VT/SVM if you check a box
Nick Piggin wrote:
A good start would be to register a shrinker (look at dcache or inode
cache for examples). Start off by allocating pages, and slow down or
stop or even release some of the pages back as you start getting feedback
back through your shrinker callback.
Not perfect, but it
Peter Zijlstra wrote:
Have a peek at this:
http://people.redhat.com/~riel/riel-OLS2006.pdf
The refault patches have been posted several times, but nobody really
tried to use them for your problem.
Yep, Rik pointed the paper and patches out to me. Seems like an
interesting approach
Huang Weiyi wrote:
Removed duplicated include file linux/highmem.h in
drivers/xen/balloon.c.
Signed-off-by: Huang Weiyi [EMAIL PROTECTED]
Acked-by: Jeremy Fitzhardinge [EMAIL PROTECTED]
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index d4427cb..afdeac5 100644
I'm thinking about ways to improve the Xen balloon driver. This is the
driver which allows the guest domain to expand or contract by either
asking for more memory from the hypervisor, or giving unneeded memory
back. From the kernel's perspective, it simply looks like a driver
which allocates
Isaku Yamahata wrote:
On Thu, Jul 17, 2008 at 07:21:37AM -0700, Jeremy Fitzhardinge wrote:
Isaku Yamahata wrote:
I had explained about that.
I had considered that option. However my conclusion is not share
he implementation because xen/ia64 timer interrupt isn't
paravirtualized
Hidetoshi Seto wrote:
+#ifdef CONFIG_STOP_MACHINE
+extern unsigned long stopmachine_timeout;
+#endif
No externs in C files. Put it in an appropriate header.
I'll do a proper review soon.
J
___
Virtualization mailing list
Hidetoshi Seto wrote:
sysctl.c already has many externs... but I can fix at least
the above.
Yeah, but it's an ugly pattern we'd rather not encourage.
I'll do a proper review soon.
Is it better to postpone v4 until your comment comes?
No.
J
Akio Takebe wrote:
+enum ipi_vector {
+XEN_RESCHEDULE_VECTOR,
+XEN_IPI_VECTOR,
+XEN_CMCP_VECTOR,
+XEN_CPEP_VECTOR,
+
+XEN_NR_IPIS,
+};
+
Don't need empty line.
It's preferred style. XEN_NR_IPIS is the end sentinel, and nothing
should be added after it.
Isaku Yamahata wrote:
implement xen pv_time_ops to account steal time.
I think you could just share arch/x86/xen/time.c, couldn't you? I'd be
happy to accept a patch to move all the shareable bits into
drivers/xen/time.c.
J
Cc: Jeremy Fitzhardinge [EMAIL PROTECTED]
Signed-off
Isaku Yamahata wrote:
Create include/asm-ia64/pvclock-abi.h to compile which includes
include/asm-x86/pvclock-abi.h because ia64/xen uses same structure.
Hopefully include/asm-x86/pvclock-abi.h would be moved to somewhere
more generic.
Could you fix the patch title spelling (necessary,
Rusty Russell wrote:
On Monday 14 July 2008 21:51:25 Christian Borntraeger wrote:
Am Montag, 14. Juli 2008 schrieb Hidetoshi Seto:
+ /* Wait all others come to life */
+ while (cpus_weight(prepared_cpus) != num_online_cpus() - 1) {
+ if (time_is_before_jiffies(limit))
Johannes Weiner wrote:
+static DEFINE_PER_CPU(int, lock_kicker_irq) = -1;
+static DEFINE_PER_CPU(struct xen_spinlock *, lock_spinners);
The plural is a bit misleading, as this is a single pointer per CPU.
Yeah. And it's wrong because it's specifically *not* spinning, but
blocking.
Switch to using the lock-byte spinlock implementation, to avoid the
worst of the performance hit from ticket locks.
Signed-off-by: Jeremy Fitzhardinge [EMAIL PROTECTED]
Cc: Thomas Friebel [EMAIL PROTECTED]
---
arch/x86/xen/smp.c |1 +
1 file changed, 1 insertion
At the most recent Xen Summit, Thomas Friebel presented a paper
(Preventing Guests from Spinning Around,
http://xen.org/files/xensummitboston08/LHP.pdf) investigating the
interactions between spinlocks and virtual machines. Specifically, he
looked at what happens when a lock-holding VCPU gets
Guests from
Spinning Around for pointing out this problem.
Signed-off-by: Jeremy Fitzhardinge [EMAIL PROTECTED]
Cc: Nick Piggin [EMAIL PROTECTED]
Cc: Thomas Friebel [EMAIL PROTECTED]
---
arch/x86/kernel/paravirt.c | 10 ++
include/asm-x86/paravirt.h | 37
-by: Jeremy Fitzhardinge [EMAIL PROTECTED]
Cc: Thomas Friebel [EMAIL PROTECTED]
---
arch/x86/xen/smp.c | 172 +-
drivers/xen/events.c | 27 ++
include/asm-x86/xen/events.h |1
include/xen/events.h |7 +
4 files changed, 206
paravirt_use_bytelocks() very early, before
any spinlocks have been taken.
Signed-off-by: Jeremy Fitzhardinge [EMAIL PROTECTED]
Cc: Nick Piggin [EMAIL PROTECTED]
Cc: Thomas Friebel [EMAIL PROTECTED]
---
arch/x86/kernel/paravirt.c |9 ++
include/asm-x86/paravirt.h |2 +
include/asm-x86
Rusty Russell wrote:
On Tuesday 08 July 2008 05:07:49 Jeremy Fitzhardinge wrote:
At the most recent Xen Summit, Thomas Friebel presented a paper
(Preventing Guests from Spinning Around,
http://xen.org/files/xensummitboston08/LHP.pdf) investigating the
interactions between spinlocks
Nick Piggin wrote:
What's lguest's solution?
Uniprocessor only.
J
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
Christopher S. Aker wrote:
Xen: 3.2.1-rc5 64bit
Dom0: 2.6.18.8 (at cs 524) 32-pae
DomU: 2.6.26-rc8 32-pae
[EMAIL PROTECTED]:~# xm create -f /linodes/xencaker/xen.conf -c
Using config file /linodes/xencaker/xen.conf.
Started domain xencaker
Is this consistent or sporadic? Does it depend on
Christopher S. Aker wrote:
Jeremy Fitzhardinge wrote:
Is this consistent or sporadic?
Consistently fails to boot, across a few test boxes, slightly
different Xen versions -- all around Xen 3.2.1, same config.
Does it depend on how much guest memory you give it?
No. Tried with 128, 360
Christopher S. Aker wrote:
Jeremy Fitzhardinge wrote:
Were there any other errors/warnings printed here?
Nope. Just some whitespace.
Are you sure? Could you send a full xm dmesg log output? The crash
is from a BUG() caused by a failing hypercall. Since you have
compiled Xen
Christopher S. Aker wrote:
Jeremy Fitzhardinge wrote:
Although, looking at it again, I did miss this line:
(XEN) mm.c:645:d341 Non-privileged (341) attempt to map I/O space
000d2e50
Good, that's what I was hoping to see. (Well, actually not that
*particular* message, which
Isaku Yamahata wrote:
clean up of xencomm.c. is_phys_contiguous() is arch dependent
function that depends on how virtual memory are laid out.
So split out the function into arch specific code.
I suppose. But given that ia64 is the only user of xencomm, I'm not too
concerned about it.
Isaku Yamahata wrote:
don't include asm/pvclock-abi.h directly, but asm/xen/pvclock-abi.h
At this moment linux ia64 won't accept asm/pvclock-abi.h because
there's no user of it.
Huh? Is this a ia64 maintainer policy? Aren't you about to start using it?
Instead make it include
is on top of the kvm git tree. The first two patches should
have no kvm dependencies and should apply to linus tree just fine.
Jeremy, can you ack the Xen bits for 2.6.26?
Hadn't I already?
Acked-by: Jeremy Fitzhardinge [EMAIL PROTECTED]
J
Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
* Linus Torvalds [EMAIL PROTECTED] wrote:
On Thu, 19 Jun 2008, Ingo Molnar wrote:
Below is the commit, it needed a small amount of massaging to apply the
void * - unsigned long * change in the x86/bitops topic.
Ingo Molnar wrote:
* Linus Torvalds [EMAIL PROTECTED] wrote:
On Fri, 20 Jun 2008, Jeremy Fitzhardinge wrote:
Blows up on gcc version 3.4.4 20050314 (prerelease) (Debian 3.4.3-13):
Yeah, I was a bit worried about that. Gcc sometimes does insane
things.
We literally just
Linus Torvalds wrote:
On Fri, 20 Jun 2008, Ingo Molnar wrote:
okay - Jeremy, could you try the fix below? (or tip/master, i just
pushed this out)
Actually, don't try that one.
It needs to be a _byte_ registers, so ir was wrong. You need iq.
Doesn't work, unfortunately:
Benjamin Herrenschmidt wrote:
Which architecture are you interested in? If it isn't x86, you can
probably get anything past Linus ;)
I'll do some measurements to see what effect the batchable
ptep_set_wrprotect() has on native. If it's significant, I'll propose
making it conditional on
Benjamin Herrenschmidt wrote:
On Mon, 2008-06-16 at 04:30 -0700, Jeremy Fitzhardinge wrote:
The only current user of this interface is mprotect
Do you plan to use it with fork ultimately ?
Good point, I'd overlooked that. I guess that means using it in
ptep_set_wrprotect
Jeremy Fitzhardinge wrote:
Benjamin Herrenschmidt wrote:
On Mon, 2008-06-16 at 04:30 -0700, Jeremy Fitzhardinge wrote:
The only current user of this interface is mprotect
Do you plan to use it with fork ultimately ?
Good point, I'd overlooked that. I
Linus Torvalds wrote:
On Wed, 18 Jun 2008, Jeremy Fitzhardinge wrote:
Along the lines of:
Hell no. There's a reason we have a special set_wrprotect() thing. We can
do it more efficiently on native hardware by just clearing the bit
atomically. No need to do the cmpxchg games
Benjamin Herrenschmidt wrote:
On Wed, 2008-06-18 at 17:24 -0700, Linus Torvalds wrote:
On Wed, 18 Jun 2008, Jeremy Fitzhardinge wrote:
Along the lines of:
Hell no. There's a reason we have a special set_wrprotect() thing. We can
do it more efficiently on native hardware
Randy Dunlap wrote:
linux-next-20080618/drivers/xen/manage.c: In function 'xen_suspend':
linux-next-20080618/drivers/xen/manage.c:66: error: too few arguments to
function 'device_power_up'
linux-next-20080618/drivers/xen/manage.c: In function 'do_suspend':
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
multicall batching to get them all into the hypervisor.
The net effect of this is that each mprotect pte update turns from two
expensive trap-and-emulate faults into they hypervisor into a single
hypercall whose cost is amortized in a batched multicall.
Signed-off-by: Jeremy Fitzhardinge [EMAIL
ptep_get_and_clear()
fetch the pte and zero the entry, preventing any hardware updates.
_commit() simply writes the new pte value back knowing that the
hardware has not updated the pte in the meantime.
The only current user of this interface is mprotect
Signed-off-by: Jeremy Fitzhardinge [EMAIL PROTECTED
manages to batch updates to
pgd/pmds as well.
Signed-off-by: Jeremy Fitzhardinge [EMAIL PROTECTED]
---
arch/x86/xen/mmu.c| 55 -
arch/x86/xen/multicalls.c | 40 +++-
arch/x86/xen/multicalls.h | 12 +
3 files
101 - 200 of 605 matches
Mail list logo
