similar to: [patch] non-SMP build fix

Displaying 20 results from an estimated 7000 matches similar to: "[patch] non-SMP build fix"

2005 Oct 07
1
[patch] testing needed: "xenif" dom0_ops
This patch changes the dom0_ops structures as discussed in the thread "32/64-bit hypercall interface". Keir, I added a struct inside XENIF_PTR() to catch direct users in the general code; it was quite useful to have the compiler identify those spots. I have compiled x86_32 and run it with xm-test[1] under qemu. There are 63 passed tests, so that''s good. I still need to
2005 Mar 23
9
[patch] final header fixes
I think this is the last of the header fixes I''ve run across. Though it''s sometimes difficult to tell, I believe Xen/ia64 has asm/mm.h, flushtlb.h, page.h, and shadow.h. Please apply. Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com> -- Hollis Blanchard IBM Linux Technology Center
2006 Aug 07
0
[PATCH] [XEN] Remove redundant redeclaration of ''machine_restart''
# HG changeset patch # User Hollis Blanchard <hollisb@us.ibm.com> # Date 1154990956 18000 # Node ID 058f2e27476d686538de2671f57c1ded5c693b47 # Parent 4196687234c530a11d26a199f1479bc07e08248f [XEN] Remove redundant redeclaration of ''machine_restart''. Fixes compile warning with gcc 3.4.2. Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com> diff -r 4196687234c5 -r
2006 Mar 14
0
[patch] call out to arch code to deliver timer interrupts
Unlike x86 and apparently ia64, PowerPC delivers timer interrupts as a different exception than device interrupts. For PowerPC Xen, we emulate this exception rather than delivering timer events as virtual IRQs. This patch introduces no functional changes for x86 and ia64, but is a required change for xen/arch/ppc. Compile-tested on x86-32. Please apply. Signed-off-by: Hollis Blanchard
2006 Apr 17
1
[patch] calloc arguments
Hi, it looks like a few users of calloc had their arguments backwards. I checked the other users and they seem fine. Since one of those is in ioemu code, does that mean we (I?) will be submitting that bug to qemu upstream? -- Hollis Blanchard IBM Linux Technology Center Fix swapped calloc() arguments. Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com> diff -r c4eead8a925b
2006 Mar 30
3
[patch] bitops on irq_cpustat_t->__softirq_pending
As mentioned earlier, PowerPC''s atomic ops operate on longs, and we have made our *_bit() prototypes use long* (instead of void*) to warn us of problems at compile time. Here''s one caller that was flagged: test_and_set_bit(nr, &softirq_pending(cpu)) Accordingly, we need __softirq_pending to be long, not int. PowerPC is currently using a few files unmodified from the x86
2005 Mar 21
0
[patch] IO-APIC in drivers/pci/quirks.c
This patch moves the IO-APIC include inside #ifdef CONFIG_X86_IO_APIC , which is how Linux 2.6 has it. This is needed for architectures without asm/io_apic.h. I''ve verified that x86 still builds; please apply. Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com> -- Hollis Blanchard IBM Linux Technology Center
2008 Jun 19
0
[PATCH] ia64/xen: implement the arch specific part of xencomm.
On ia64/xen, pointer argument for the hypercall is passed by pseudo physical address (guest physical address.) So it is necessary to convert virtual address into pseudo physical address right before issuing hypercall. The frame work is called xencomm. This patch implements arch specific part. Signed-off-by: Alex Williamson <alex.williamson at hp.com> Signed-off-by: Isaku Yamahata
2008 Jun 19
0
[PATCH] ia64/xen: implement the arch specific part of xencomm.
On ia64/xen, pointer argument for the hypercall is passed by pseudo physical address (guest physical address.) So it is necessary to convert virtual address into pseudo physical address right before issuing hypercall. The frame work is called xencomm. This patch implements arch specific part. Signed-off-by: Alex Williamson <alex.williamson at hp.com> Signed-off-by: Isaku Yamahata
2006 Sep 20
15
[PATCH] [XEND] Remove hard tabs
# HG changeset patch # User Hollis Blanchard <hollisb@us.ibm.com> # Date 1158780052 18000 # Node ID f7d90f962967a5a94fce0c04f8fcac449f36344f # Parent 041be3f6b38e05f904d240630c18cadb1259317b [XEND] Remove hard tabs. Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com> diff -r 041be3f6b38e -r f7d90f962967 tools/python/xen/xend/XendDomainInfo.py ---
2006 Aug 30
3
arch-specific xc.c code?
Hi Ewan/Alistair, I have a patch that looks like this: diff -r a39ad4c78850 tools/libxc/xenctrl.h --- a/tools/libxc/xenctrl.h Wed Aug 30 13:51:12 2006 +0100 +++ b/tools/libxc/xenctrl.h Wed Aug 30 15:11:20 2006 -0500 @@ -416,6 +416,10 @@ int xc_domain_memory_populate_physmap(in unsigned int address_bits, xen_pfn_t
2006 Jun 09
2
evtchn_upcall_mask
This topic came up months ago (under the thread "make hypercall_preempt_check() a little more sensitive"), but since then, due to a misunderstanding, PPC has been running with a hack instead of a solution. So anyways, I''ve been digging into this again. PowerPC domains are allowed to write to the "interrupts enabled" bit (called External Exceptions, or EE) in the
2006 Aug 08
11
architecture-specific stuff in xend
Hi Ewan, I''m almost ready to integrate some PPC-specific stuff into xend, and I was wondering if you had a plan for how that should work. First example: the device tree data structure we talked about a few weeks ago. We will need to pass the config data to PPC code, probably in XendDomainInfo.initDomain(), and then pass the resulting data structure into libxc''s xc_linux_load()
2006 Jul 28
1
Re: [Xen-changelog] [xen-unstable] [IA64] Creates tools/libxc/ia64 directory.
On Fri, 2006-07-28 at 16:20 +0000, Xen patchbot-unstable wrote: > diff -r dc26ac2f7718 -r dab0a5650e6d tools/libxc/Makefile > --- a/tools/libxc/Makefile Mon Jul 10 14:14:11 2006 -0600 > +++ b/tools/libxc/Makefile Tue Jul 11 11:29:25 2006 -0600 > @@ -30,9 +30,11 @@ GUEST_SRCS-y += xc_load_bin.c > GUEST_SRCS-y += xc_load_bin.c > GUEST_SRCS-y += xc_load_elf.c >
2006 Apr 14
8
[rfc] [patch] 32/64-bit hypercall interface revisited
Last year we had a discussion[1] about how the hypercall ABI unfortunately contains fields that change width between 32- and 64-bit builds. This is a huge problem as we come up on the python management stack for ppc64, since the distributions ship 32-bit python. A 32-bit python/libxc cannot currently manage a 64-bit hypervisor. I had a patch but was unable to test it, and some other things were
2005 Aug 02
4
Re: [Xen-changelog] Fixes.
On Tuesday 02 August 2005 10:42, Xen patchbot -unstable wrote: > # HG changeset patch > # User smh22@firebug.cl.cam.ac.uk > # Node ID 59e76450e286240decceda23eca343ec4604124f > # Parent 48dea637aac96bcbabe788d036b52570520cc82e > Fixes. Sorry, but could we not make checkin comments like "Fixes."? It would just take a few more seconds to describe it in a complete
2005 May 11
1
RE: recent major -unstable changes cause ia64 build to bebroken
> Another new problem due to a common change... > > xen/include/xen/cpumask.h declares: > > extern cpumask_t cpu_online_map; > > However, with CONFIG_SMP off, xen/include/xen/smp.h defines > cpu_online_map to 1. It''s daft that we even have a CONFIG_SMP option in Xen. It spends most of its time broken because no-one using x86 builds it, and you won''t
2006 Aug 17
5
Re: [XenPPC] Xencomm for xen/ia64
(CCed to xen-devel for completeness. ;) On Wed, 2006-08-16 at 17:24 +0200, Tristan Gingold wrote: > I am porting xen-ppc''s xencomm to xen/ia64. > Currently on xen/ia64 copy_from/to_guest uses guest virtual address. This > works well as long as the virtual addresses are in the TLB. When not in TLB > (or vTLB) the hypercall can''t success without domain help. The
2006 Apr 19
0
RE: [patch] "frame number" size in hypercall ABI
Keir Fraser wrote: > On 19 Apr 2006, at 17:44, Hollis Blanchard wrote: > >> "xen_frameno_t" then? > > xen_pfn_t? Definitely won''t conflict with anyone, and I prefer ''pfn'' > to ''frameno'' as it''s more consistent with other names we have in the > interface. > >> Attached is the updated patch, with
2008 Mar 26
1
[kvm-ppc-devel] virtio network traffic issues
Hollis Blanchard wrote: > On Tue, 2008-03-25 at 14:45 +0100, Christian Ehrhardt wrote: >> => from one not yet defined point our guest seems to receive absolutely nothing >> => when the guest is hanging it sends nfs requests which are seen externally, but it does not seem to get the respones >> => the arp requests for the guest are repeated - maybe we can add some very