Re: [PATCH] virtio_ring: Fix the stale index in available ring

On Tue, Mar 26, 2024 at 03:49:02AM -0400, Michael S. Tsirkin wrote: > On Mon, Mar 25, 2024 at 05:34:29PM +1000, Gavin Shan wrote: > > > > On 3/20/24 17:14, Michael S. Tsirkin wrote: > > > On Wed, Mar 20, 2024 at 03:24:16PM +1000, Gavin Shan wrote: > > > > On 3/20/24 10:49, Michael S. Tsirkin

Re: [PATCH] virtio_ring: Fix the stale index in available ring

On Wed, Mar 20, 2024 at 03:24:16PM +1000, Gavin Shan wrote: > > Before this patch was posted, I had debugging code to record last 16 > transactions > to the available and used queue from guest and host side. It did reveal the > wrong > head was fetched from the available queue. > > [

Re: [Xen-devel] [PATCH 7/9] x86: skip check for spurious faults for non-present faults

H. Peter Anvin wrote: On 04/15/2014 07:15 AM, David Vrabel wrote: If a fault on a kernel address is due to a non-present page, then it cannot be the result of stale TLB entry from a protection change (RO to RW or NX to X). Thus the pagetable walk in spurious_fault() can be skipped. Erk...

Re: [Xen-devel] [PATCH 7/9] x86: skip check for spurious faults for non-present faults

H. Peter Anvin wrote: On 04/15/2014 07:15 AM, David Vrabel wrote: If a fault on a kernel address is due to a non-present page, then it cannot be the result of stale TLB entry from a protection change (RO to RW or NX to X). Thus the pagetable walk in spurious_fault() can be skipped. Erk...

Re: [PATCH XEN] xen: event channel arrays are xen_ulong_t and not unsigned long

On 21/02/2013 17:16, "Ian Campbell" wrote: > On Tue, 2013-02-19 at 14:49 +, Ian Campbell wrote: >> On ARM we want these to be the same size on 32- and 64-bit. >> >> This is an ABI change on ARM. X86 does not change. >> >> Signed-off-by: Ian Campbell >> Cc: Jan Beulich >> Cc: Keir

Re: [PATCH XEN] xen: event channel arrays are xen_ulong_t and not unsigned long

On 21/02/2013 17:16, Ian Campbell ian.campb...@citrix.com wrote: On Tue, 2013-02-19 at 14:49 +, Ian Campbell wrote: On ARM we want these to be the same size on 32- and 64-bit. This is an ABI change on ARM. X86 does not change. Signed-off-by: Ian Campbell ian.campb...@citrix.com Cc:

Re: [Xen-devel] incorrect layout of globals from head_64.S during kexec boot

On 15/07/2012 17:06, "Olaf Hering" wrote: > On Tue, Jul 10, Keir Fraser wrote: > >> Best thing to do, is possible, is map the shared-info page in the >> xen-platform pci device's BAR memory range. Then it will not conflict with >> any RAM. > >

Re: [Xen-devel] incorrect layout of globals from head_64.S during kexec boot

On 15/07/2012 17:06, Olaf Hering o...@aepfle.de wrote: On Tue, Jul 10, Keir Fraser wrote: Best thing to do, is possible, is map the shared-info page in the xen-platform pci device's BAR memory range. Then it will not conflict with any RAM. This patch does that. I did a kexec boot

Re: [Xen-devel] incorrect layout of globals from head_64.S during kexec boot

On 13/07/2012 21:20, "Olaf Hering" wrote: > On Tue, Jul 10, Keir Fraser wrote: > >> On 10/07/2012 19:09, "Olaf Hering" wrote: >>> I'm not sure, most likely the gfn will just disappear from the guest, >>> like a ballooned page disappears. Acces

Re: [Xen-devel] incorrect layout of globals from head_64.S during kexec boot

On 13/07/2012 21:20, Olaf Hering o...@aepfle.de wrote: On Tue, Jul 10, Keir Fraser wrote: On 10/07/2012 19:09, Olaf Hering o...@aepfle.de wrote: I'm not sure, most likely the gfn will just disappear from the guest, like a ballooned page disappears. Accessing it will likely cause a crash

Re: [Xen-devel] incorrect layout of globals from head_64.S during kexec boot

On 10/07/2012 19:09, "Olaf Hering" wrote: >>> Are there more shared areas or is it just the shared info page? >>> And I am kind of worried that moving it to the .data section won't be completly safe - as the decompressor might blow away that part too. >>> >>> The decompressor may

Re: [Xen-devel] incorrect layout of globals from head_64.S during kexec boot

On 10/07/2012 19:09, Olaf Hering o...@aepfle.de wrote: Are there more shared areas or is it just the shared info page? And I am kind of worried that moving it to the .data section won't be completly safe - as the decompressor might blow away that part too. The decompressor may just clear

Re: [PATCH 11 of 11] x86: defer cr3 reload when doing pud_clear()

On 25/1/08 22:54, "Jeremy Fitzhardinge" <[EMAIL PROTECTED]> wrote: > The only possibly relevant comment I can find in vol3a is: > > Older IA-32 processors that implement the PAE mechanism use uncached > accesses when loading page-directory-pointer table entries. This > behavior is >

Re: [PATCH UPDATE] x86: ignore spurious faults

On 25/1/08 10:19, "Andi Kleen" <[EMAIL PROTECTED]> wrote: >> Whether this a problem in light of Xen spurious faults depends on whether >> NMI handlers touch dynamically-allocated data. > > How do you define dynamically-allocated data? Anything that could have been a read-only pte or ldt page in

Re: [PATCH UPDATE] x86: ignore spurious faults

On 25/1/08 09:11, "Andi Kleen" <[EMAIL PROTECTED]> wrote: >>> Actually, another thought: permitting (and handling) spurious faults for >>> kernel mappings conflicts with NMI handling, i.e. great care would be >>> needed to ensure the NMI path cannot touch any such mapping. So >>> even the present

Re: [PATCH UPDATE] x86: ignore spurious faults

On 25/1/08 00:26, "Jeremy Fitzhardinge" <[EMAIL PROTECTED]> wrote: >> I (obviously) don't know exactly how the TLB works in x86, but I >> thought that on a miss, the CPU walks the pagetables first before >> faulting? Maybe that's not the case if there is an RO entry >> actually in the TLB? >>

Re: [PATCH UPDATE] x86: ignore spurious faults

On 25/1/08 00:26, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: I (obviously) don't know exactly how the TLB works in x86, but I thought that on a miss, the CPU walks the pagetables first before faulting? Maybe that's not the case if there is an RO entry actually in the TLB? My

Re: [PATCH UPDATE] x86: ignore spurious faults

On 25/1/08 09:11, Andi Kleen [EMAIL PROTECTED] wrote: Actually, another thought: permitting (and handling) spurious faults for kernel mappings conflicts with NMI handling, i.e. great care would be needed to ensure the NMI path cannot touch any such mapping. So even the present Xen/Linux Dom0

Re: [PATCH 11 of 11] x86: defer cr3 reload when doing pud_clear()

On 25/1/08 22:54, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: The only possibly relevant comment I can find in vol3a is: Older IA-32 processors that implement the PAE mechanism use uncached accesses when loading page-directory-pointer table entries. This behavior is model

Re: [PATCH UPDATE] x86: ignore spurious faults

On 25/1/08 10:19, Andi Kleen [EMAIL PROTECTED] wrote: Whether this a problem in light of Xen spurious faults depends on whether NMI handlers touch dynamically-allocated data. How do you define dynamically-allocated data? Anything that could have been a read-only pte or ldt page in a

Re: [PATCH 3/16] read/write_crX, clts and wbinvd for 64-bit paravirt

On 1/11/07 15:30, "Jeremy Fitzhardinge" <[EMAIL PROTECTED]> wrote: > Glauber de Oliveira Costa wrote: >> I in fact have seen bugs with mixed reads and writes to the same cr, >> (cr4), but adding the volatile >> flag to the read function seemed to fix it. > > Well, volatile will make a read be

Re: [PATCH 3/16] read/write_crX, clts and wbinvd for 64-bit paravirt

On 1/11/07 15:30, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: Glauber de Oliveira Costa wrote: I in fact have seen bugs with mixed reads and writes to the same cr, (cr4), but adding the volatile flag to the read function seemed to fix it. Well, volatile will make a read be repeated rather

Re: race with page_referenced_one->ptep_test_and_clear_young and pagetable setup/pulldown

On 5/10/07 16:33, "Hugh Dickins" <[EMAIL PROTECTED]> wrote: > If a 2.6.23 fix is needed, I suggest simply excluding split ptlocks > in the Xen case, as shown by the mm/Kconfig - line in Jan's patch. I didn't think that nobbling config options for particular pv_ops implementations was acceptable?

Re: race with page_referenced_one->ptep_test_and_clear_young and pagetable setup/pulldown

On 5/10/07 10:05, "Jeremy Fitzhardinge" <[EMAIL PROTECTED]> wrote: > Andi says: >> Do I misread that patch or does it really walk the complete address >> space and try to take all possible locks? Isn't that very slow? >> > > That's pretty much what it has to do. Pinning/unpinning walks the

Re: race with page_referenced_one-ptep_test_and_clear_young and pagetable setup/pulldown

On 5/10/07 10:05, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: Andi says: Do I misread that patch or does it really walk the complete address space and try to take all possible locks? Isn't that very slow? That's pretty much what it has to do. Pinning/unpinning walks the whole

Re: race with page_referenced_one-ptep_test_and_clear_young and pagetable setup/pulldown

On 5/10/07 16:33, Hugh Dickins [EMAIL PROTECTED] wrote: If a 2.6.23 fix is needed, I suggest simply excluding split ptlocks in the Xen case, as shown by the mm/Kconfig - line in Jan's patch. I didn't think that nobbling config options for particular pv_ops implementations was acceptable? I'm

[PATCH] Fix swiotlb_sync_single_range()

. This patch fixes the issue by initialising all mapped slabs in io_tlb_orig_addr[]. It also correctly adjusts the buffer pointer in sync_single() to handle the case that the given dma_addr is not aligned on a slab boundary. Signed-off-by: Keir Fraser <[EMAIL PROTECTED]> (Please Cc me

[PATCH] Fix swiotlb_sync_single_range()

. This patch fixes the issue by initialising all mapped slabs in io_tlb_orig_addr[]. It also correctly adjusts the buffer pointer in sync_single() to handle the case that the given dma_addr is not aligned on a slab boundary. Signed-off-by: Keir Fraser [EMAIL PROTECTED] (Please Cc me in any response

Re: [Xen-devel] [patch 14/33] xen: xen time implementation

On 6/6/07 13:46, "Jan Beulich" <[EMAIL PROTECTED]> wrote: >> On the other hand some timing issues on throttling are probably >> the smallest of the users' problems when it really happens. > > Not if this results in your box hanging - I think throttling is exactly > intended > to keep the box

Re: [Xen-devel] [patch 14/33] xen: xen time implementation

On 6/6/07 12:00, "Jan Beulich" <[EMAIL PROTECTED]> wrote: >> If the error across CPUS is +/- just a few microseconds at worst then having >> the clocksource clamp to no less than the last timestamp returned seems a >> reasonable fix. Time won't 'stop' for longer than the cross-CPU error, and

Re: [Xen-devel] [patch 14/33] xen: xen time implementation

On 6/6/07 10:30, "Jan Beulich" <[EMAIL PROTECTED]> wrote: >> If you have an ACPI PM timer in your system (and if you have SMM then your >> system is almost certainly modern enough to have one) then surely the >> problem is fixed for all practical purposes? The problem was overflow of a >>

Re: [Xen-devel] [patch 14/33] xen: xen time implementation

On 6/6/07 09:39, "Jan Beulich" <[EMAIL PROTECTED]> wrote: > The issue is > that on that system, transition into ACPI mode takes over 600ms (SMM > execution, and hence no interrupts delivered during that time), and with > Xen using the PIT (PM timer support was added by Keir as a result of this, >

Re: [Xen-devel] [patch 14/33] xen: xen time implementation

On 6/6/07 09:39, Jan Beulich [EMAIL PROTECTED] wrote: The issue is that on that system, transition into ACPI mode takes over 600ms (SMM execution, and hence no interrupts delivered during that time), and with Xen using the PIT (PM timer support was added by Keir as a result of this, but that

Re: [Xen-devel] [patch 14/33] xen: xen time implementation

On 6/6/07 10:30, Jan Beulich [EMAIL PROTECTED] wrote: If you have an ACPI PM timer in your system (and if you have SMM then your system is almost certainly modern enough to have one) then surely the problem is fixed for all practical purposes? The problem was overflow of a fixed-width

Re: [Xen-devel] [patch 14/33] xen: xen time implementation

On 6/6/07 12:00, Jan Beulich [EMAIL PROTECTED] wrote: If the error across CPUS is +/- just a few microseconds at worst then having the clocksource clamp to no less than the last timestamp returned seems a reasonable fix. Time won't 'stop' for longer than the cross-CPU error, and that

Re: [Xen-devel] [patch 14/33] xen: xen time implementation

On 6/6/07 13:46, Jan Beulich [EMAIL PROTECTED] wrote: On the other hand some timing issues on throttling are probably the smallest of the users' problems when it really happens. Not if this results in your box hanging - I think throttling is exactly intended to keep the box alive as

Re: netfront for review

On 3/5/07 15:27, "Jeremy Fitzhardinge" <[EMAIL PROTECTED]> wrote: >> The function has an effect in page flipping mode only. It walks the >> whole list of rx skbufs (id is the loop variable ...), checks whenever >> they are handed out to the frontend driver to fill in packet data and >> not

Re: netfront for review

On 3/5/07 15:27, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: The function has an effect in page flipping mode only. It walks the whole list of rx skbufs (id is the loop variable ...), checks whenever they are handed out to the frontend driver to fill in packet data and not returned yet,

Re: [PATCH 06/25] xen: Core Xen implementation

On 27/4/07 08:08, "Jeremy Fitzhardinge" <[EMAIL PROTECTED]> wrote: >> Don't you need a rmb() here then? The CPU could speculate reads >> (more occurrences) >> > > Is rmb() sufficient? It will stop a speculative read on the pending > flag, but will it make sure the write has happened by then?

Re: [PATCH 06/25] xen: Core Xen implementation

On 27/4/07 08:08, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: Don't you need a rmb() here then? The CPU could speculate reads (more occurrences) Is rmb() sufficient? It will stop a speculative read on the pending flag, but will it make sure the write has happened by then? Ie, is it a

Re: [PATCH 0/4] i386 - pte update optimizations

On 13/4/07 13:27, "Andi Kleen" <[EMAIL PROTECTED]> wrote: >> LOCKed instruction suck really badly on the netburst microarchitecture (like >> factor of 10x, or not far off). I think it's probably because of their side >> effect of serialising memory accesses, causing horrible pipeline stalls. > >

Re: [PATCH 0/4] i386 - pte update optimizations

On 13/4/07 03:24, "Zachary Amsden" <[EMAIL PROTECTED]> wrote: >> You do know that P6 and higher don't do locked bus references as long >> as the value is in the cache, right? > > Yes. Even then, last time I clocked instructions, xchg was still slower > than read / write, although I could be

Re: [PATCH 0/4] i386 - pte update optimizations

On 13/4/07 03:24, Zachary Amsden [EMAIL PROTECTED] wrote: You do know that P6 and higher don't do locked bus references as long as the value is in the cache, right? Yes. Even then, last time I clocked instructions, xchg was still slower than read / write, although I could be

Re: [PATCH 0/4] i386 - pte update optimizations

On 13/4/07 13:27, Andi Kleen [EMAIL PROTECTED] wrote: LOCKed instruction suck really badly on the netburst microarchitecture (like factor of 10x, or not far off). I think it's probably because of their side effect of serialising memory accesses, causing horrible pipeline stalls.

Re: [Xen-devel] Re: [patch 21/26] Xen-paravirt_ops: Use the hvc console infrastructure for Xen console

On 16/3/07 11:41, "Andrew Morton" <[EMAIL PROTECTED]> wrote: >> It's needed for writing data /after/ reading the consumer index that shows >> you have space to write. Looking through xenbus_comms.c I think all the >> barriers are correct except there is a spurious extra mb() in xb_read(), >>

Re: [Xen-devel] Re: [patch 21/26] Xen-paravirt_ops: Use the hvc console infrastructure for Xen console

On 16/3/07 09:58, "Ingo Molnar" <[EMAIL PROTECTED]> wrote: >> These mb()'s are pretty standard for lock-free producer/consumer >> rings. Write descriptor /then/ write the updated producer. Read the >> producer /then/ read any descriptors revealed by this new producer >> value. > > then use

Re: [Xen-devel] Re: [patch 21/26] Xen-paravirt_ops: Use the hvc console infrastructure for Xen console

On 16/3/07 09:58, Ingo Molnar [EMAIL PROTECTED] wrote: These mb()'s are pretty standard for lock-free producer/consumer rings. Write descriptor /then/ write the updated producer. Read the producer /then/ read any descriptors revealed by this new producer value. then use rmb()/wmb(). Rarely

Re: [Xen-devel] Re: [patch 21/26] Xen-paravirt_ops: Use the hvc console infrastructure for Xen console

On 16/3/07 11:41, Andrew Morton [EMAIL PROTECTED] wrote: It's needed for writing data /after/ reading the consumer index that shows you have space to write. Looking through xenbus_comms.c I think all the barriers are correct except there is a spurious extra mb() in xb_read(), where there is a

Re: + stupid-hack-to-make-mainline-build.patch added to -mm tree

On 8/3/07 08:01, "Ingo Molnar" <[EMAIL PROTECTED]> wrote: > you are obsessed with avoiding a hypercall, but why? Granted it's slow > especially on things like SVN/VMX, but it's not fundamentally slow. We > definitely do not want to design our whole APIs and abstractions around > the temporary

Re: + stupid-hack-to-make-mainline-build.patch added to -mm tree

On 8/3/07 08:01, Ingo Molnar [EMAIL PROTECTED] wrote: you are obsessed with avoiding a hypercall, but why? Granted it's slow especially on things like SVN/VMX, but it's not fundamentally slow. We definitely do not want to design our whole APIs and abstractions around the temporary notion that

Re: [RFC] Arp announce (for Xen)

On 2/3/07 01:30, "Stephen Hemminger" <[EMAIL PROTECTED]> wrote: > What about implementing the unused arp_announce flag on the inetdevice? > Something like the following. Totally untested... > > Looks like it either was there (and got removed) or was planned but > never implemented. This would

Re: [RFC] Arp announce (for Xen)

On 2/3/07 01:30, Stephen Hemminger [EMAIL PROTECTED] wrote: What about implementing the unused arp_announce flag on the inetdevice? Something like the following. Totally untested... Looks like it either was there (and got removed) or was planned but never implemented. This would be

Re: [patch 17/24] Xen-paravirt_ops: avoid having a bad selector in %gs during context switch

On 21/2/07 22:10, "Andi Kleen" <[EMAIL PROTECTED]> wrote: >> /* >> + * Temporary hack: zero gs now that we've saved it so that Xen >> + * doesn't try to reload the old value after changing the GDT >> + * during the context switch. This can go away once Xen has >> + * been taught to only

Re: [patch 17/24] Xen-paravirt_ops: avoid having a bad selector in %gs during context switch

On 21/2/07 22:10, Andi Kleen [EMAIL PROTECTED] wrote: /* + * Temporary hack: zero gs now that we've saved it so that Xen + * doesn't try to reload the old value after changing the GDT + * during the context switch. This can go away once Xen has + * been taught to only reload %gs when it

Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas

On 16/2/07 19:26, "Jeremy Fitzhardinge" <[EMAIL PROTECTED]> wrote: > Keir Fraser wrote: >> Hmmm... Actually looks like a bunch of architectures do lazy sync of the >> vmalloc area, although neither ia64 nor powerpc does so. However, all >> current users

Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas

On 16/2/07 19:06, "Keir Fraser" <[EMAIL PROTECTED]> wrote: >> I had moved it to mm/vmalloc.c in response to previous review comments >> (namely, its not Xen specific, so it shouldn't live in the Xen part of >> the tree). > > Then the call will have to

Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas

On 16/2/07 17:27, "Jeremy Fitzhardinge" <[EMAIL PROTECTED]> wrote: > In fact that file is only built for i386 and x86_64, so there really is no >> problem with using vmalloc_sync_all() directly and without ifdef. >> > > I had moved it to mm/vmalloc.c in response to previous review comments >

Re: [Xen-devel] Re: [patch 14/21] Xen-paravirt: Add XEN config options and disableunsupported config options.

On 16/2/07 17:46, "Jeremy Fitzhardinge" <[EMAIL PROTECTED]> wrote: > Keir Fraser wrote: >> This initial patchset does not include save/restore support anyway, so in >> fact it would be consistent to have CONFIG_PREEMPT configurable. I'm sure >> that we are go

Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas

On 16/2/07 17:10, "Keir Fraser" <[EMAIL PROTECTED]> wrote: > On 16/2/07 16:46, "Jeremy Fitzhardinge" <[EMAIL PROTECTED]> wrote: > >> Yes, that would work. Unfortunately that's i386 arch-specific, whereas >> the rest of this code is generic. I

Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas

On 16/2/07 16:46, "Jeremy Fitzhardinge" <[EMAIL PROTECTED]> wrote: > Yes, that would work. Unfortunately that's i386 arch-specific, whereas > the rest of this code is generic. I guess I could just move it all to > arch/i386/mm. This whole thing isn't an issue on ia64 (they no-op

Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas

On 16/2/07 09:18, "Andi Kleen" <[EMAIL PROTECTED]> wrote: >> It's for populating the pagetable in a vmalloc area. There's magic in > > If the lazy setup doesn't work for you you can always call vmalloc_sync() > early. vmalloc_sync_all()? That's a great idea. We can put that in

Re: [patch 14/21] Xen-paravirt: Add XEN config options and disableunsupported config options.

On 16/2/07 10:54, "Andrew Morton" <[EMAIL PROTECTED]> wrote: > OK, you're screwed. I agree that the process freezer is the way out of that > one. > > Ingo said that he's clocked the freezer at a few milliseconds. But if it's > any higher than that it'll need to get sped up once we convert cpu

Re: [patch 14/21] Xen-paravirt: Add XEN config options and disable unsupported config options.

On 16/2/07 08:37, "Dan Hecht" <[EMAIL PROTECTED]> wrote: > Hmm? I thought the periodic timer and one-shot timer both generate the > same VIRQ. So, how can you mask one without masking the other? > > The tickless idle works since the block hypercall disables the periodic > timer. But for

Re: [patch 14/21] Xen-paravirt: Add XEN config options and disableunsupported config options.

On 16/2/07 10:09, "Andrew Morton" <[EMAIL PROTECTED]> wrote: > Are the places where the domU code references machine addresses splattered > all over the code? If not, they can just be wrapped with > preempt_disable/preempt_enable? The main places where machine addresses are 'visible' are any

Re: [Xen-devel] Re: [patch 14/21] Xen-paravirt: Add XEN config options and disable unsupported config options.

On 16/2/07 10:19, "Zachary Amsden" <[EMAIL PROTECTED]> wrote: > Doesn't stop_machine_run already take care of getting you out of all > kernel threads? So you can only be sleeping, not preempted, in which > case, this might not be an issue? It ensures that no (non-stopmachine) threads are

Re: [patch 14/21] Xen-paravirt: Add XEN config options and disable unsupported config options.

On 16/2/07 07:25, "Jeremy Fitzhardinge" <[EMAIL PROTECTED]> wrote: >> Oh, so that's why it doesn't break when CONFIG_PREEMPT=y. In which case >> that preempt_disable() I spotted is wrong-and-unneeded. >> >> Why doesn't Xen work with preemption?? > > I've forgotten the details. Ian? Keir?

Re: [patch 14/21] Xen-paravirt: Add XEN config options and disable unsupported config options.

On 16/2/07 07:25, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: Oh, so that's why it doesn't break when CONFIG_PREEMPT=y. In which case that preempt_disable() I spotted is wrong-and-unneeded. Why doesn't Xen work with preemption?? I've forgotten the details. Ian? Keir? Steven? Maybe

Re: [Xen-devel] Re: [patch 14/21] Xen-paravirt: Add XEN config options and disable unsupported config options.

On 16/2/07 10:19, Zachary Amsden [EMAIL PROTECTED] wrote: Doesn't stop_machine_run already take care of getting you out of all kernel threads? So you can only be sleeping, not preempted, in which case, this might not be an issue? It ensures that no (non-stopmachine) threads are running on

Re: [patch 14/21] Xen-paravirt: Add XEN config options and disableunsupported config options.

On 16/2/07 10:09, Andrew Morton [EMAIL PROTECTED] wrote: Are the places where the domU code references machine addresses splattered all over the code? If not, they can just be wrapped with preempt_disable/preempt_enable? The main places where machine addresses are 'visible' are any code that

Re: [patch 14/21] Xen-paravirt: Add XEN config options and disable unsupported config options.

On 16/2/07 08:37, Dan Hecht [EMAIL PROTECTED] wrote: Hmm? I thought the periodic timer and one-shot timer both generate the same VIRQ. So, how can you mask one without masking the other? The tickless idle works since the block hypercall disables the periodic timer. But for dynticks (aka

Re: [patch 14/21] Xen-paravirt: Add XEN config options and disableunsupported config options.

On 16/2/07 10:54, Andrew Morton [EMAIL PROTECTED] wrote: OK, you're screwed. I agree that the process freezer is the way out of that one. Ingo said that he's clocked the freezer at a few milliseconds. But if it's any higher than that it'll need to get sped up once we convert cpu hotplug

Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas

On 16/2/07 09:18, Andi Kleen [EMAIL PROTECTED] wrote: It's for populating the pagetable in a vmalloc area. There's magic in If the lazy setup doesn't work for you you can always call vmalloc_sync() early. vmalloc_sync_all()? That's a great idea. We can put that in alloc_vm_area() and

Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas

On 16/2/07 16:46, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: Yes, that would work. Unfortunately that's i386 arch-specific, whereas the rest of this code is generic. I guess I could just move it all to arch/i386/mm. This whole thing isn't an issue on ia64 (they no-op lock_vm_area) and

Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas

On 16/2/07 17:10, Keir Fraser [EMAIL PROTECTED] wrote: On 16/2/07 16:46, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: Yes, that would work. Unfortunately that's i386 arch-specific, whereas the rest of this code is generic. I guess I could just move it all to arch/i386/mm. This whole

Re: [Xen-devel] Re: [patch 14/21] Xen-paravirt: Add XEN config options and disableunsupported config options.

On 16/2/07 17:46, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: Keir Fraser wrote: This initial patchset does not include save/restore support anyway, so in fact it would be consistent to have CONFIG_PREEMPT configurable. I'm sure that we are going to have some nasty bugs to fix up as a result

Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas

On 16/2/07 17:27, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: In fact that file is only built for i386 and x86_64, so there really is no problem with using vmalloc_sync_all() directly and without ifdef. I had moved it to mm/vmalloc.c in response to previous review comments (namely,

Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas

On 16/2/07 19:06, Keir Fraser [EMAIL PROTECTED] wrote: I had moved it to mm/vmalloc.c in response to previous review comments (namely, its not Xen specific, so it shouldn't live in the Xen part of the tree). Then the call will have to be CONFIG_X86. I hadn't realised powerpc were also

Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas

On 16/2/07 19:26, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: Keir Fraser wrote: Hmmm... Actually looks like a bunch of architectures do lazy sync of the vmalloc area, although neither ia64 nor powerpc does so. However, all current users of the alloc_vm_area() function would be okay since

Re: [patch 20/20] XEN-paravirt: Add Xen virtual block device driver.

On 14/1/07 11:05 am, "Jan Engelhardt" <[EMAIL PROTECTED]> wrote: >> The block device frontend driver allows the kernel to access block >> devices exported exported by a virtual machine containing a physical >> block device driver. > > Is this significantly different from ubd/hostfs that it

Re: [patch 20/20] XEN-paravirt: Add Xen virtual block device driver.

On 14/1/07 11:05 am, Jan Engelhardt [EMAIL PROTECTED] wrote: The block device frontend driver allows the kernel to access block devices exported exported by a virtual machine containing a physical block device driver. Is this significantly different from ubd/hostfs that it actually warrants

Re: [Xen-devel] Lots of "swapper: page allocation failure" and other memory related messages - 2.6.16-xen0

On 8/12/06 12:36, "Jesper Juhl" <[EMAIL PROTECTED]> wrote: > (please keep me on Cc when replying) > > I have a server running Xen that regularly spews the following. > The box seems to survive fine regardless - just thought I'd let everyone know. Harmless and not entirely unexpected. I'll

Re: [Xen-devel] Lots of swapper: page allocation failure and other memory related messages - 2.6.16-xen0

On 8/12/06 12:36, Jesper Juhl [EMAIL PROTECTED] wrote: (please keep me on Cc when replying) I have a server running Xen that regularly spews the following. The box seems to survive fine regardless - just thought I'd let everyone know. Harmless and not entirely unexpected. I'll add

Incorrect comment in leave_mm()?

Hi, I have a question regarding the per-cpu tlbstate logic that is used to lazily switch to the swapper_pgdir when running a process with no mm_struct of its own. There is a comment in arch/i386/kernel/smp.c:leave_mm() that states 'We need to reload %cr3 since the page tables may be going away

Incorrect comment in leave_mm()?

Hi, I have a question regarding the per-cpu tlbstate logic that is used to lazily switch to the swapper_pgdir when running a process with no mm_struct of its own. There is a comment in arch/i386/kernel/smp.c:leave_mm() that states 'We need to reload %cr3 since the page tables may be going away

[PATCH] AGP fix for Xen VMM

that use the GART driver. Signed-off-by: Keir Fraser <[EMAIL PROTECTED]> --- linux-2.6-old/drivers/char/agp/agp.h2005-03-16 10:30:25 +00:00 +++ linux-2.6-new/drivers/char/agp/agp.h2005-03-21 13:24:24 +00:00 @@ -278,6 +278,8 @@ #define AGP_GENERIC_SIZES_ENTRIES 11 extern

Suspected bug in floppy.c

I think I may have uncovered a bug in the floppy driver while getting it to work on Xen. The problem is that vfree() may get called in softirq context, via the following backtrace: vfree fd_dma_mem_free floppy_release_irq_and_dma set_dor motor_off_callback On native i386, this would

Suspected bug in floppy.c

I think I may have uncovered a bug in the floppy driver while getting it to work on Xen. The problem is that vfree() may get called in softirq context, via the following backtrace: vfree fd_dma_mem_free floppy_release_irq_and_dma set_dor motor_off_callback On native i386, this would

[PATCH] AGP fix for Xen VMM

that use the GART driver. Signed-off-by: Keir Fraser [EMAIL PROTECTED] --- linux-2.6-old/drivers/char/agp/agp.h2005-03-16 10:30:25 +00:00 +++ linux-2.6-new/drivers/char/agp/agp.h2005-03-21 13:24:24 +00:00 @@ -278,6 +278,8 @@ #define AGP_GENERIC_SIZES_ENTRIES 11 extern struct

Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

On 19 Mar 2005, at 10:56, Christian Limpach wrote: For this specific case there may be another resolution but could you please, please look at marking the missing pages PG_reserved and not hacking phys_to_virt. At this point anything short of explicitly introducing an intermediate step say

Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

On 19 Mar 2005, at 10:56, Christian Limpach wrote: For this specific case there may be another resolution but could you please, please look at marking the missing pages PG_reserved and not hacking phys_to_virt. At this point anything short of explicitly introducing an intermediate step say

Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

On 18 Mar 2005, at 00:16, Paul Mackerras wrote: That sounds like a good way to make AGP accesses slower. :) Seriously, given that AGP is a technology that is being superseded by PCI Express, I think it's reasonable to look at the range of current implementations to see what we have to cope with.

Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

On 18 Mar 2005, at 00:16, Paul Mackerras wrote: That sounds like a good way to make AGP accesses slower. :) Seriously, given that AGP is a technology that is being superseded by PCI Express, I think it's reasonable to look at the range of current implementations to see what we have to cope with.

Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

> > So: I would very much like you to take the patches I made to generic.c > > that replace __get_free_pages() calls with dma_alloc_coherent(). For > > This is also wrong - the base address of the GATT is a physical > address not a bus address. This change will break agpgart on ppc64 > systems

Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

On 16 Mar 2005, at 22:06, Jesse Barnes wrote: The distinction is that physical addresses are what are used to access physical memory, whereas bus addresses are what appears on some external bus (usually PCI). The GATT sits between an external (AGP) bus and memory, so while the GATT is indexed

Re: [PATCH] Xen/i386 cleanups - io_remap_pfn_range

On 17 Mar 2005, at 04:41, Randy.Dunlap wrote: Our io_remap_pfn_range() patches don't contain many collisions. My first patch [adding io_remap_pfn_range() to all arches] does go a little further than yours in that regard. Also, I was

Re: [PATCH] Xen/i386 cleanups - io_remap_pfn_range

On 17 Mar 2005, at 04:41, Randy.Dunlap wrote: Our io_remap_pfn_range() patches don't contain many collisions. My first patch [adding io_remap_pfn_range() to all arches] http://marc.theaimsgroup.com/?l=linux-mmm=111049473410099w=2 does go a little further than yours in that regard. Also, I was

Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

On 16 Mar 2005, at 22:06, Jesse Barnes wrote: The distinction is that physical addresses are what are used to access physical memory, whereas bus addresses are what appears on some external bus (usually PCI). The GATT sits between an external (AGP) bus and memory, so while the GATT is indexed

Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

So: I would very much like you to take the patches I made to generic.c that replace __get_free_pages() calls with dma_alloc_coherent(). For This is also wrong - the base address of the GATT is a physical address not a bus address. This change will break agpgart on ppc64 systems and I

Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

On 16 Mar 2005, at 19:06, Christoph Hellwig wrote: The AGP driver is only configurable for ppc32, alpha, x86, x86_64 and ia64, all of which have virt_to_bus. and ppc64 now, which doesn't. Sounds like the new DMA-mapping interface is the way to go then. -- Keir - To unsubscribe from this list:

Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

On 16 Mar 2005, at 18:42, Jesse Barnes wrote: The AGP driver is only configurable for ppc32, alpha, x86, x86_64 and ia64, all of which have virt_to_bus. Yeah, but that doesn't mean it makes sense on all those platforms. The biggest problem with virt_to_bus (well, depending on who you talk to) is

  1   2   >