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 (Xen.org

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 just

Re: Address translation

re that the above would work, and I think/hope it is the most elegant way to share memory between kernel and a process. Thanks in advance for any info! -- Keir Fraser PS. Please cc me directly ([EMAIL PROTECTED]) with any replies. - To unsubscribe from this list: send the line "unsubscri

Re: [patch] enabling APIC and NMI watchdog on UP systems

0 That is, all the LINT[0:1] pins on all processors are configured into NMI mode. That given, I don't see how external interrupts work (although obviously they must do :-) I'm really curious as to how this magic works... -- Keir Fraser - To unsubscribe from this list: send the line "

Re: [patch] enabling APIC and NMI watchdog on UP systems

> what is wrong with clearing the first performance counter before using it? > The NMI oopser is completely nonintrusive. > > so on UP systems you'll have to choose between the NMI oopser and other > uses of the first counter. You can save/restore the contents of the first > counter if you want t

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 wh

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: [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 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 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

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

dma_alloc_coherent rather than get_free_pages. Again, not a distinction that matters for i386, but very important for Xen and possibly for other architectures too. Signed-off-by: Keir Fraser <[EMAIL PROTECTED]> --- linux-2.6-old/drivers/char/agp/ali-agp.c2005-03-16 10:30:25 +00:00 +++ linux-2

[PATCH] Xen/i386 cleanups - io_remap_pfn_range

at boot time and to pass this to io_remap_pfn_range. Signed-off-by: Keir Fraser <[EMAIL PROTECTED]> --- linux-2.6-old/drivers/char/agp/frontend.c 2005-03-16 10:30:25 +00:00 +++ linux-2.6-new/drivers/char/agp/frontend.c 2005-03-16 10:34:58 +00:00 @@ -628,7 +628,7 @@ DBG(&

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

> On Wed, Mar 16, 2005 at 11:48:29AM +0000, Keir Fraser wrote: > > This patch cleans up AGP driver treatment of bus/device memory. Every > > use of virt_to_phys/phys_to_virt should properly be converting between > > virtual and bus addresses: this distinction reall

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

On 16 Mar 2005, at 18:10, Christoph Hellwig wrote: On Wed, Mar 16, 2005 at 10:01:07AM -0500, Rik van Riel wrote: In the case of AGP, the AGPGART effectively _is_ the IOMMU. Calculating the addresses right for programming the AGPGART is probably worth fixing. Well, it's a half-assed one. And some

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

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: send

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 u

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 usin

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 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. S

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 virt_to_

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 normal

[PATCH] AGP fix for Xen VMM

g architectures 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

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 f

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 rep

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 actual

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 reloa

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? Ste

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

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 cod

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 dyntic

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 h

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(

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

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 generi

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 a

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 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 hav

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

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

[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

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 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-wi

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 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 a

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 misr

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 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()/

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

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: [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 b

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 noti

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 ret

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. > > [ 11.78574

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 wrote

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.

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. > > T

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... thi