> This defines __smp_XXX barriers for ia64,
> for use by virtualization.
>
> smp_XXX barriers are removed as they are
> defined correctly by asm-generic/barriers.h
>
> This reduces the amount of arch-specific boiler-plate code.
Acked-by: Tony Luck
___
> On ia64 smp_rmb, smp_wmb, read_barrier_depends, smp_read_barrier_depends
> and smp_store_mb() match the asm-generic variants exactly. Drop the
> local definitions and pull in asm-generic/barrier.h instead.
>
> This is in preparation to refactoring this code area.
Acked-by: Tony Luck
__
> asm-generic/barrier.h defines a nop() macro.
> To be able to use this header on ia64, we shouldn't
> call local functions/variables nop().
>
> There's one instance where this breaks on ia64:
> rename the function to iosapic_nop to avoid the conflict.
Acked-by: Tony Luck
___
> > I assume that this patch will be pushed via the ia64 patch queue, no?
>
> I suppose that Tony would handle it. Tony?
Yes. I'll put that in.
Yamahata-san: Would you please send me a .config file that
I can check in as arch/ia64/configs/xen_defconfig so I can
add a xen build to my regular regr
> This patchset is ia64/xen domU patch take 12.
> Tony, please commit those patches.
Ok. Committed.
-Tony
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
+++ 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
I will trade out this patch for one that just makes
a copy of the x86 include file. This #include will
break
> This patch implements a checker to detect instructions which
> should be paravirtualized instead of direct writing raw instruction.
> This patch does rough check so that it doesn't fully cover all cases,
> but it can detects most cases of paravirtualization breakage of hand
> written assembly cod
>+ if (!time_after(delta_itm + new_itm, ia64_get_itc()))
>+ stolentick = ia64_get_itc() - new_itm;
>+
>+ do_div(stolentick, NS_PER_TICK);
>
>
> Which makes me assume that ia64_get_itc() is returning nanoseconds; does
> it do the adjustment from the itc's actual rate to nan
> So, my understanding from looking at your patch that the itc is somewhat
> like the x86 tsc, in that it's not (necessarily) synchronized between
> cpus. But unlike the tsc, the itc is always in nanoseconds, but you
> don't get information from Xen about the current physical cpu's offset
> from a
>> +#define is_kernel_addr(x) \
>> + ((PAGE_OFFSET <= (x) && \
>> + (x) < (PAGE_OFFSET + (1UL << IA64_MAX_PHYS_BITS))) || \
>> +(KERNEL_START <= (x) &&\
>> + (x) < KERN
> introduce CONFIG_PARAVIRT_GUEST, CONFIG_PARAVIRT for
> paravirtualized guest.
> introduce CONFING_XEN, CONFIG_IA64_XEN for xen.
s/CONFING_XEN/CONFIG_XEN/
Would it make sense to rename CONFIG_IA64_XEN to be
CONFIG_IA64_XEN_GUEST? The comments you add to
arch/ia64/Kconfig say that this is what i
> This patch includes ia64 counter part of
> 9e124fe16ff24746d6de5a2ad685266d7bce0e08 and
> 83abc70a4c6e306f4c1672e25884322f797e4fcb for xen early printk support.
These GIT commit ids do not exist in Linus' tree, so this
is not a good commit log message.
-Tony
> On ia64/xen, pointer arguments for hypercall is passed
> by pseudo physical address(guest physical address.)
> So such hypercalls needs address conversion functions.
> This patch implements concreate conversion functions for
s/concreate/concrete/
-Tony
___
> On ia64/xen, pointer argument for the hypercall is passed
> by pseudo physical address (guest phsysical address.)
s/phsysical/physical/
> So it is necessary to convert virtual address into pseudo physical
> address rigth before issuing hypercall. The frame work is called
s/rigth/right/
+#ifde
+/*
+ * Hypercalls without parameter.
+ */
+#define __HCALL0(name,hcall) \
+ GLOBAL_ENTRY(name); \
+ break hcall; \
Should Linux code be made aware of the "break" numbers that
are being used for hypercalls (so it doesn't try to re-use
them for
> Resolve it by increasing NET_SKB_NET from the default value 16 to 18.
Typo? You mean NET_SKB_PAD here?
But in include/linux/skbuff.h it says: "It must be a power of 2".
Explain why 18 is ok.
-Tony
___
Virtualization mailing list
Virtualization@list
03/27 was fine.
04/27 ... I've no idea what it is all for ... I expect I'll find out later
in the patch series :-)
One style quibble ... I don't see much of this elsewhere in the Linux code:
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * ind
Just started digging through these ... part 01/27 was fine. But here
are a couple of comments for part 02/27
+/*
+ * Copyright 1992, Linus Torvalds.
+ * Heavily modified to provide guaranteed strong synchronisation
+ * when communicating with Xen or other guest OSes running on other CPUs.
+ */
Pr
> Since the effort to reduce code size had already been made, so
> it is difficult to go further. By moving all of them, it would
> be consistent and we don't have to worry about code size anymore.
I've been caught by these a number of times while adding debug/monitor
hooks to ivt.S code. Moving
> Thank you for testing.
>
> What was the result?
No problems found.
> No patch has been committed to
> git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git#test
I had to spend time on a bugfix. The bugfix is posted
in my 'release' branch. The pv_ops series (including the
documentat
> Hi. This patchset implements ia64/pv_ops support which is the
> framework for virtualization support.
> Changes from take 5 are rebased to Linux 2.6.26-rc3,
> bug fix ivt.S paravirtualization and multi entry point support.
> I believe these patches can be applied to the linux ia64 repository.
Ok
I started looking at this patch set.
Parts 1-9 applied ok, but part10 (entry.S) failed to apply because of
recent changes to this file to fix the problems with warnings when
trying to get locks with interrupts blocked.
I thought this would be a good point to test the bisectability
of this patch s
> > Have you looked at Jens Axboe's patches to make all this stuff a lot
> > more arch-common?
>
> Nope, do you have a pointer?
Check your favourite archive for this Subject line:
Generic smp_call_function(), improvements, and smp_call_function_single()
-Tony
_
23 matches
Mail list logo
