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
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) investi
t.
To use this, you must call 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 ++
incl
paths will only be entered 2% of the time.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Thomas Friebel <[EMAIL PROTECTED]>
---
arch/x86/xen/smp.c | 172 +-
drivers/xen/events.c | 27 ++
include/asm-x86/x
n Summit talk "Preventing 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 |
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 in
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,
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 asm/xen/p
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.
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, t
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 B
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
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 d
inor tweaks after super-fast review by Jeremy.
>>
>> The queue 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
Jeremy Fitzhardinge wrote:
> 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)
>>>
>>>
>> Act
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, unfo
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
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 i
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 cond
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':
> linux-next-20080618/drivers/xen
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_wrprotec
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
> at
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 u
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.
ut problems, at least under Xen.
Acked-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
J
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
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 ++
uses 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 &l
ng generic 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 Fitzhardin
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.
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
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_re
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':
> linux-next-20080613/arch/x86/xen/mmu.c:759: error: implicit declaration of
> function 'xen_smp_call_function_mask'
> make[2]: *** [arch/x86
Nick Piggin wrote:
> On Tuesday 10 June 2008 17:57, Jeremy Fitzhardinge wrote:
>
>> Nick Piggin wrote:
>>
>>> On Tuesday 10 June 2008 17:35, Isaku Yamahata wrote:
>>>
>>>> This patch is ported one from 534:77db69c38249 of linux-2.6.1
Nick Piggin wrote:
> On Tuesday 10 June 2008 17:35, Isaku Yamahata wrote:
>
>> This patch is ported one from 534:77db69c38249 of linux-2.6.18-xen.hg.
>> Use wmb instead of rmb to enforce ordering between
>> evtchn_upcall_pending and evtchn_pending_sel stores
>> in xen_evtchn_do_upcall().
>>
Gerd Hoffmann wrote:
> paravirt clock source patches, next round.
>
> There is now a pvclock-abi.h file with the structs and some longish
> comments in it and everybody is switched over to use the stuff in
> there.
This all looks pretty good. How do you want this to get into the kernel?
J
__
Gerd Hoffmann wrote:
> This patch updates the xen guest to use the pvclock structs
> and helper functions.
>
> Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
> ---
> arch/x86/xen/Kconfig|1 +
> arch/x86/xen/time.c | 130
> ---
> inclu
Gerd Hoffmann wrote:
> +/*
> + * These structs MUST NOT be changed.
> + * They are the ABI between hypervisor and guest OS.
> + * Both Xen and KVM are using this.
> + *
> + * pvclock_vcpu_time_info holds the system time and the tsc timestamp
> + * of the last update. So the guest can use the tsc de
Rusty Russell wrote:
> On Monday 02 June 2008 23:02:34 Jeremy Fitzhardinge wrote:
>
>> Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
>> ---
>> include/asm-generic/pgtable.h | 14 +-
>> 1 file c
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/asm-generic/pgtable.h | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
===
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-g
Ingo Molnar wrote:
> * Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>
>
>> +/* Get the current pte state, but zero it out to make it
>> + non-present, preventing the hardware from asynchronously
>> + updating it. */
>>
>
> ple
Ingo Molnar wrote:
> * Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>
>
>> +#define __HAVE_ARCH_PTEP_MODIFY_PROT_TRANSACTION
>>
>
> please turn this into CONFIG_ARCH_HAS_PTEP_MODIFY_PROT_TRANSACTION
> instead.
The __HAVE_ARCH_ form is consistent wi
Zachary Amsden wrote:
> We don't fault. We write directly to the primary page tables, and clear
> the pte just like native. We just issue all mprotect updates in the
> queue, and flush the queue when leaving lazy mmu mode. You can't wait
> for the TLB flush, you must flush the updates before rel
ng generic 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 Fitzhardin
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
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.
uses 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 &l
I've added a Xen/paravirt_ops page to the Xen wiki. This is intended to
let people know the current status, give them a guide on how to use the
Xen support in current Linux kernels, and (ideally) start contributing
to its ongoing development, with testing, debugging and patches.
http://wiki.xe
Randy Dunlap wrote:
> linux-next-20080528/drivers/xen/manage.c: In function 'xen_suspend':
> linux-next-20080528/drivers/xen/manage.c:43: error: implicit declaration of
> function 'device_power_down'
> linux-next-20080528/drivers/xen/manage.c:65: error: implicit declaration of
> function 'device_
Linus Torvalds wrote:
> On Fri, 23 May 2008, Jeremy Fitzhardinge wrote:
>
>> Well, you could use it to update the page and protection bits while
>> preserving
>> the AD bits, but I don't think that's very useful.
>>
>
> It's not that it&
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);
>>
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
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/x
, preventing any hardware updates.
pte_rmw_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]>
---
include/asm-generic/pgtable.h
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_
batch updates to pgd/pmds as well.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/x86/xen/mmu.c| 56 -
arch/x86/xen/multicalls.c | 40 +++-
arch/x86/xen/multicalls.h | 12 +
3 files c
ing 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 PROTECTED]&g
ation of the page number (most notably,
Xen).
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/x86/kernel/paravirt.c |1 +
arch/x86/xen/enlighten.c |1 +
drivers/lguest/lg.h|1 -
include/asm-x86/page.h |1 +
include/asm-x86/paravi
Gerd Hoffmann wrote:
> Jeremy Fitzhardinge wrote:
>
>
>>> +static unsigned pvclock_get_time_values(struct pvclock_shadow_time *dst,
>>> +struct kvm_vcpu_time_info *src)
>>>
>>>
>> I think the kvm_* types should be
Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
>
Looks basically OK, but some comments.
> ---
> arch/x86/Kconfig |4 +
> arch/x86/kernel/Makefile |1 +
> arch/x86/kernel/pvclock.c | 148
> +
> include/asm
Markus Armbruster wrote:
> This is an update to the Linux part of the Xen PVFB. Linux Xen PVFB
> is a pair of Xen para-virtual frontend device drivers:
> drivers/video/xen-fbfront.c provides a framebuffer, and
> drivers/input/xen-kbdfront provides keyboard and mouse. Their
> backends run in dom0
Rusty Russell wrote:
> Unfortunately not. Hardware randomness devices export /dev/hwrng, and it's
> up
> to userspace to feed that into /dev/random (or not). That's usually done by
> rngd, which at least on my system, assumes 1 bit of entropy per bit of data
> from /dev/hwrng by default.
>
>
Rusty Russell wrote:
> On Saturday 17 May 2008 17:47:01 Jeremy Fitzhardinge wrote:
>
>> But the host->guest protocol should include the number of bits estimated
>> entropy along with the bits themselves.
>>
>
> If we go down that path, we have to c
Isaku Yamahata wrote:
> Yes, I also really want such a tool and I've thought of it.
> I want to prevent people from accidently breaking paravirtualization
> and only a way to do so would be by enforcing.
> I think it can be easily achived by CPP macro trick.
> At worst a simple .s (or .o) parser.
>
Rusty Russell wrote:
> On Saturday 17 May 2008 14:50:31 H. Peter Anvin wrote:
>
>> Rusty Russell wrote:
>>
>>> On Friday 16 May 2008 20:49:41 Johannes Berg wrote:
>>>
> +
> +/* Our random number generator device reads from /dev/urandom into the
> Guest's + * input buffers
Jeff Garzik wrote:
> Has anyone yet written a "hw" RNG module for virt, that reads the host's
> random number pool?
>
> All this talk[1] about IRQF_SAMPLE_RANDOM in network drivers reminds me
> that virt guest instances should be grabbing random numbers from the
> host, especially if the host ha
Christian Borntraeger wrote:
> I really like 64 guest cpus as a good testcase for all kind of things.
>
Sure, I do the same kind of thing.
>> I think x86 (at least) is now using ticket locks, which is fair. Which
>> kernel are you seeing this problem on?
>>
>
> Sorry, forgot to mention
Christian Borntraeger wrote:
> On kvm I have seen some rare hangs in stop_machine when I used more guest
> cpus than hosts cpus. e.g. 32 guest cpus on 1 host cpu triggered the
> hang quite often. I could also reproduce the problem on a 4 way z/VM host
> with
> a 64 way guest.
>
I think that's
Isaku Yamahata wrote:
> Hi Jeremy.
> Here are the 3 patches for ia64/xen support.
> The first one is just to move manage.c under drivers/xen.
> This is trivial.
>
> The second and third ones are for compilation fix on ia64.
> You may want to postpone those 2 patches to make your merge task
> easy a
Isaku Yamahata wrote:
> move arch/x86/xen/manage.c under drivers/xen/to share codes
> with x86 and ia64.
> ia64/xen also uses manage.c
>
Hm, I've got patches to add suspend/resume to manage.c. I guess they're
going to be at least partially arch-specific. Well, no problem to split
those out.
Rusty Russell wrote:
> +asmlinkage long sys_vringfd(void __user *addr,
> + unsigned num_descs,
> + u16 __user *last_used)
> +{
> + int fd, err;
> + struct file *filp;
> + struct vring_info *vr;
> +
> + /* Must be a power of two, and re
Isaku Yamahata wrote:
> define sync bitops which is necessary for ia64/xen.
>
> Signed-off-by: Isaku Yamahata <[EMAIL PROTECTED]>
> ---
> include/asm-ia64/sync_bitops.h | 59
>
> 1 files changed, 59 insertions(+), 0 deletions(-)
> create mode 100644 inc
Markus Armbruster wrote:
> This turns out to a thornier problem than one might think.
>
> Consoles tty, hvc and ttyS register in this order.
>
> Unless the kernel command line dictates otherwise, the first one to
> register becomes the preferred console (the one behind /dev/console).
> This is tty.
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
&
Jes Sorensen wrote:
> I'm a little wary of the performance impact of this change. Doing a
> cpumask compare on all smp_call_function calls seems a little expensive.
> Maybe it's just noise in the big picture compared to the actual cost of
> the IPIs, but I thought I'd bring it up.
>
> Keep in mind
Isaku Yamahata wrote:
> On Fri, Mar 28, 2008 at 01:09:48PM -0700, Jeremy Fitzhardinge wrote:
>
>> Isaku Yamahata wrote:
>>
>>> On xen/ia64 and xen/powerpc hypercall arguments are passed by pseudo
>>> physical address (guest physical address) so tha
Markus Armbruster wrote:
> This makes the Xen console just work. Before, you had to ask for it
> on the kernel command line with console=hvc0
>
I see that this has been causing issues when people expect the pvfb
driver to be the console. Should we make it a config option, which
depends on !
Isaku Yamahata wrote:
> The definitions in include/asm/xen/page.h are arch specific.
> ia64/xen wants to define its own version. So move them to arch specific
> directory and keep include/xen/page.h in order not to break compilation.
>
> Signed-off-by: Isaku Yamahata <[EMAIL PROTECTED]>
> ---
> in
Isaku Yamahata wrote:
> +/* macro to avoid header inclusion dependncy hell */
> +#define xen_irqs_disabled(regs) (!((regs)->flags & X86_EFLAGS_IF))
>
This seems pretty generic. Is there no suitable existing function?
Could irqs_disabled_flags() be pressed into service? I guess it depen
Isaku Yamahata wrote:
> Don't use alloc_vm_area()/free_vm_area() directly, instead define
> xen_alloc_vm_area()/xen_free_vm_area() and use them.
>
> alloc_vm_area()/free_vm_area() are used to allocate/free area which
> are for grant table mapping. Xen/x86 grant table is based on virtual
> address s
Isaku Yamahata wrote:
> Define resend_irq_on_evtchn() which ia64/xen uses.
> Although it isn't used by current x86/xen code, it's arch generic
> so that put it into common code.
> make ipi_to_irq[] visible removing static because
> ia64/xen needs to access the variable from ia64 specific code
>
Isaku Yamahata wrote:
> On xen/ia64 and xen/powerpc hypercall arguments are passed by pseudo
> physical address (guest physical address) so that it's necessary to
> convert from virtual address into pseudo physical address. The frame
> work is called xencomm.
> Import arch generic part of xencomm.
l:
> - *
> - * 1. Inter-domain notifications. This includes all the virtual
> - *device events, since they're driven by front-ends in another
> domain
> - *(typically dom0).
> - * 2. VIRQs, typically used for timers. These are per-cpu events.
> - * 3. IPIs.
Carsten Otte wrote:
> +struct mm_struct *dup_mm(struct task_struct *tsk);
>
No prototypes in .c files. Put this in an appropriate header.
J
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.
Dong, Eddie wrote:
> Current xen kernel codes are in arch/x86/xen, but xen dynamic
> irqchip (events.c) are common for other architectures such as IA64. We
> are in progress with enabling pv_ops for IA64 now and want to reuse same
> code, do we need to move the code to some place common? sugg
xming wrote:
> On Feb 7, 2008 5:09 AM, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>
>> xming wrote:
>>
>>> But I do have one problem after I upgraded to xen 3.2, the 2.6.23.x domU do
>>> not boot any more and 2.6.24 does boot but will ha
Christopher S. Aker wrote:
> Jeremy Fitzhardinge wrote:
>> Are you running an SMP or UP domain? I found I could get hangs very
>> easily with UP (but I need confirm it isn't a result of some other
>> very experimental patches).
>
> The hang occurs with both SM
Zachary Amsden wrote:
> It needn't be that hard on s390, I believe you don't need to worry about
> PTEs becoming asynchronous when stealing a page, since if I understand
> the hypervisor architecture, there is a per-page mapping level
> available, allowing you to generate discard faults on access.
Zachary Amsden wrote:
> On Thu, 2008-03-13 at 18:55 +, Hugh Dickins wrote:
>
>> On Thu, 13 Mar 2008, Jeremy Fitzhardinge wrote:
>>
>>> My other concern is just correctness over time on the Linux side. We
>>> already
>>> have enough
Hugh Dickins wrote:
> On Wed, 12 Mar 2008, Martin Schwidefsky wrote:
>
>> Greetings,
>> I've dedusted the guest page hinting patches and ported them to todays
>> upstream git tree. There is one reject if applied to 2.6.24-rc5-mm1 but
>> that is easy to fix. The code stills works as expected on m
Martin Schwidefsky wrote:
> Vz is the page discarded state. The difference to Uz is slim, both
> states will cause a program check on access. Vz generates a discard
> fault, Uz generates an addressing exception which is nice for debugging.
>
How do you handle these different cases in Linux? Do
Jeremy Fitzhardinge wrote:
Martin Schwidefsky wrote:
Vz->Vr cannot happen. This would be a bug in the host.
Does that mean that Vz is effectively identical to Uz?
Hm, on further thought:
If guests writes to Vz pages are disallowed, then the only way out of Vz
is if the guest sets
Martin Schwidefsky wrote:
> Vz->Vr cannot happen. This would be a bug in the host.
>
Does that mean that Vz is effectively identical to Uz?
J
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation
Anthony Liguori wrote:
>> Vp should never happen, since you'd never preserve a V page. And
>> surely it would be Pr -> Sr, since the hypervisor wouldn't push the
>> page to backing store when you change the client state.
>>
>
> You're right, I meant Vp/Pp but they are invalid states. I thi
Anthony Liguori wrote:
Jeremy Fitzhardinge wrote:
With stable_if_clean you are refering to stable_if_present?
No. I misunderstood and thought that stable_if_present sets the Px
state. I'd overlooked the writable flag on page_set_volatile().
If yes the
answer is that
Martin Schwidefsky wrote:
On Wed, 2008-03-12 at 09:44 -0700, Jeremy Fitzhardinge wrote:
Martin Schwidefsky wrote:
That is the first block of state transitions: {Ur,Sr,Vr,Pr}
You can go from any of the four states to any of the remaining three.
You only mention page_set_
Martin Schwidefsky wrote:
That is the first block of state transitions: {Ur,Sr,Vr,Pr}
You can go from any of the four states to any of the remaining three.
You only mention page_set_{unused,stable,volatile}. Is
page_set_stable_if_present() the fourth. And shouldn't that be
"stable_if_cle
Martin Schwidefsky wrote:
The state transitions (a diagram would be nicer but that is too hard
to do in ascii art...):
{Ur,Sr,Vr,Pr}: a resident page will change its block usage state if the
guest requests it with page_set_{unused,stable,volatile}.
{Uz,Sz,Vz}: a logically zero page will chan
Ravikiran G Thirumalai wrote:
> Would anyone have objection to have PARAVIRT depend on PCI, since the
> vsmp paravirt bits depend on PCI cfg space to determine if the system is
> vsmp? If not, this patch would suffice.
>
NAK. Xen doesn't depend on PCI at all. Why not make VSMP depend on
P
Randy Dunlap wrote:
Added Cc:
> On Tue, 11 Mar 2008 01:14:34 -0700 Andrew Morton wrote:
>
>
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc5/2.6.25-rc5-mm1/
>>
>
> randconfig (x86_64) with
> PCI=n
> PARAVIRT=y
> VSMP=n
>
> ends with
>
> arch/x86/kernel/built-in.
Christopher S. Aker wrote:
> Jeremy Fitzhardinge wrote:
>> I've been running this all night without seeing any problem. I'm
>> using current x86.git#testing with a few local patches, but nothing
>> especially relevent-looking.
>
> Meh .. what backend ar
201 - 300 of 973 matches
Mail list logo
