[XenPPC] Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue
Updated cset numbers now that all the ia64 patches are merged into
mainline...
On Mon, 2007-09-10 at 13:18 -0600, Alex Williamson wrote:
> http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?rev/6644d8486266
> ia64/15762:6644d8486266 - cleanup NVRAM failure case
Now
http://xenbits.xensource.com/staging/xen-unstable.hg?rev/6644d8486266
15850:6644d8486266
> http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?rev/f88eea67a469
> *ia64/15764:f88eea67a469 - move NVRAM from /usr to /var
Now
http://xenbits.xensource.com/staging/xen-unstable.hg?rev/f88eea67a469
15852:f88eea67a469 (but you'll still need to use the modified version
attached previously)
Thanks,
Alex
--
Alex Williamson HP Open Source & Linux Org.
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue
On Mon, 2007-09-10 at 09:56 +0100, Keir Fraser wrote:
> Hi,
>
> A provisional patchqueue for Xen 3.1.1 is available at
> http://xenbits.xensource.com/xen-3.1-testing.pq.hg. This pq partners with
> http://xenbits.xensource.com/xen-3.1-testing.hg.
>
> Please kick this pq around and check whether the patches you want to see in
> 3.1.1 are included.
Hi Keir,
Here's a proposed list of patches for ia64:
Must have fixes:
http://xenbits.xensource.com/xen-unstable.hg?rev/51f5bea7b0d8
15348:51f5bea7b0d8 - adds free_irq(), necessary for build
http://xenbits.xensource.com/xen-unstable.hg?rev/b46c2ff6dfb0
15331:b46c2ff6dfb0 - fixes boot on NUMA systems
http://xenbits.xensource.com/xen-unstable.hg?rev/f536eb8576ee
15579:f536eb8576ee - fix VTI domain shutdown
http://xenbits.xensource.com/xen-unstable.hg?rev/d4f59e652078
15096:d4f59e652078 - fix pcifront with CONFIG_NUMA
http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/1483ef74511b
linux/56:1483ef74511b - update for acm interface changes
http://lists.xensource.com/archives/html/xen-ia64-devel/2006-11/msg00358.html
ia64-sal-get-state-info - Avoid GFP_KERNEL allocation from interrupt
context. This was only recently fixed in upstream and is dependent on
other patches. This is the simple fix proposed on the mailing list.
Patch attached.
These are all related to working out bugs and save location for NVRAM
support (must have):
http://xenbits.xensource.com/xen-unstable.hg?rev/71377eab1874
15349:71377eab1874 - white space cleanup - necessary for subsequent
patches
http://xenbits.xensource.com/xen-unstable.hg?rev/634b7f7f8584
*15265:634b7f7f8584 - allow domu nvram saving to fail gracefully
http://xenbits.xensource.com/xen-unstable.hg?rev/1623f5f5094f
15364:1623f5f5094f - don't save NVRAM on PV guests
http://xenbits.xensource.com/xen-unstable.hg?rev/33cc64dcaead
15365:33cc64dcaead - create NVRAM save directory
http://xenbits.xensource.com/xen-unstable.hg?rev/fd0103b55504
15366:fd0103b55504 - error checking for creat NVRAM save directory
http://xenbits.xensource.com/xen-unstable.hg?rev/38d061886873
1:38d061886873 - avoid saving garbage to NVRAM on config error
http://xenbits.xensource.com/xen-unstable.hg?rev/2a5b463f2e8d
15557:2a5b463f2e8d - fix NVRAM save on reboot
http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?rev/6644d8486266
ia64/15762:6644d8486266 - cleanup NVRAM failure case
http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?rev/f88eea67a469
*ia64/15764:f88eea67a469 - move NVRAM from /usr to /var
These add the PCI Controller backend (high want - driver domains on some
systems won't work without this):
http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/93a955c2bebb
linux/46:93a955c2bebb - introduces controller backend
http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/a62cfa35d3b5
*linux/55:a62cfa35d3b5 - add hypercall to register i/o spaces
http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/452c5d4a5537
*linux/61:452c5d4a5537 - enable controller as default PCI backend
http://xenbits.xensource.com/xen-unstable.hg?rev/601509daabfc
*15353:601509daabfc - xen side support for multiple i/o spaces
Patches with an asterisk above require some modification to apply (white
space/file location/invalid chunks). I've attached the modified
versions below. Also note that 15265 is intentionally applied after
15349 above. There's some screwiness around a merge for these and it
was easier to modify the white space in the smaller one and apply it
later.
Other ia64'ers, please speak up if there's something else missing.
Thanks,
Alex
--
Alex Williamson HP Open Source & Linux Org.
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1181644323 -3600
# Node ID 634b7f7f8584f478c9e45a98998c7e7c1b8e3b3d
# Parent e1c54c14220a4d4ab38d8a3d409ab678275a5426
[IA64] When a domU is destroyed, it will fall into NVRAM saving
path. But if there is no NVRAM file for the domU, the save operation
would fail. Then domU blocked by Xend's exception. This patch fixs
that issue.
Signed-off-by: Zhang Xin <[EMAIL PROTECTED]>
diff -r e1c54c14220a -r 634b7f7f8584 tools/libxc/ia64/xc_ia64_hvm_build.c
--- a/tools/libxc/ia64/xc_ia64_hvm_build.c Tue Jun 12 11:29:27 2007 +0100
+++ b/tools/libxc/ia64/xc_ia64_hvm_build.c Tue Jun 12 11:32:03 2007 +0100
@@ -712,11 +712,15 @@ int xc_ia64_save_to_nvram(int xc_handle,
xc_get_hvm_param(xc_handle, dom, HVM_PARAM_NVRAM_FD, &nvram_fd);
if ( !IS_VALID_NVRAM_FD(nvram_fd) )
-{
PERROR("Nvram not be initialized. Nvram save fail!\n");
-return -1;
-}
-return copy_from_GFW_to_nvram(xc_handle, dom, (int)nvram_fd);
+else
+copy_from_GFW_to_nvram(xc_handle, dom, (int)nvram_fd);
+
+// although save to nvram maybe fail, we don't return any error number
+// to Xend. This is quite logical because damage of NVRAM on native would
+
[XenPPC] Re: [Xen-devel] [PATCH 0/4] xencomm take 2: preparation for consolidation and various fixes
On Mon, 2007-08-13 at 10:10 +0100, Keir Fraser wrote: > I'll apply these if Alex and Hollis will ack them. They look OK to me. Acked-by: Alex Williamson <[EMAIL PROTECTED]> > On 13/8/07 04:59, "Isaku Yamahata" <[EMAIL PROTECTED]> wrote: > > > > > This updated patch series is for xencomm consolidation and various fixes > > based on Hollis's comment. > > > > Changes from take 1: > > xen side varisous fixes and preparation for consolidation > > - sorted out the maddr and vaddr issue > > - returning an error with warning message instead of panicing domain. > > linux side various fixes and preparation for consolidation > > - update gcc work around. > > It is a generic issue, not ia64 specific. > > 3/4 and 4/4 patch is same. > > > > > > [PATCH 1/4] xencomm take 2: xen side varisous fixes and preparation for > > consolidation > > [PATCH 2/4] xencomm take 2: linux side various fixes and preparation for > > consolidation > > [PATCH 3/4] xencomm take 2: linux side introduce struct xencomm_handle * > > [PATCH 4/4] xencomm take 2: linux side remove xencomm page size limit > > > > Thanks, > > > > ___ > > Xen-devel mailing list > > [EMAIL PROTECTED] > > http://lists.xensource.com/xen-devel > > > ___ > Xen-devel mailing list > [EMAIL PROTECTED] > http://lists.xensource.com/xen-devel > -- Alex Williamson HP Open Source & Linux Org. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-ia64-devel] [PATCH 2/2] remove xencomm page size limit(linux side)
Hi Isaku,
The 32bit restriction on this one is unfortunate, especially if we
want to also apply this to the common xencomm code. IIRC, ppc supports
32bit guests. Maybe we need to keep a page allocation interface for
32bit and a smaller granularity allocation for 64bit? I think a ~100GB
limit would be more than acceptable for a 32bit guest. Thanks,
Alex
On Tue, 2007-07-31 at 15:12 +0900, Isaku Yamahata wrote:
> # HG changeset patch
> # User [EMAIL PROTECTED]
> # Date 1185763112 -32400
> # Node ID 9536c4366949dcd4a163d2129e18e319bf6d1ac2
> # Parent b0bf9ba32bfe341af07da97d57572659c920fd30
> remove xencomm page size limit.
> Currently xencomm has page size limit so that a domain with many memory
> (e.g. 100GB~) can't be created.
>
> Now that xencomm of xen side accepts struct xencomm_desc whose address array
> crosses page boundary. Thus it isn't necessary to allocate single page
> not to cross page boundary. We can allocate exact sized memory.
> Note that struct xencomm_desc can't cross page boundary.
> For that sake, this implementation depends on the slab allocator
> implementation and sizeof(struct xencomm_desc) = 8 = sizeof (void*).
> This is true on ia64, but may not be true on 32bit environment.
> PATCHNAME: remove_xencomm_page_size_limit
>
> Signed-off-by: Isaku Yamahata <[EMAIL PROTECTED]>
>
> diff -r b0bf9ba32bfe -r 9536c4366949 arch/ia64/xen/xencomm.c
> --- a/arch/ia64/xen/xencomm.c Fri Jul 27 08:15:50 2007 -0600
> +++ b/arch/ia64/xen/xencomm.c Mon Jul 30 11:38:32 2007 +0900
> @@ -158,16 +158,25 @@ xencomm_init_desc(struct xencomm_desc *d
> }
>
> static struct xencomm_desc *
> -xencomm_alloc(gfp_t gfp_mask)
> -{
> - struct xencomm_desc *desc;
> -
> - desc = (struct xencomm_desc *)__get_free_page(gfp_mask);
> +xencomm_alloc(gfp_t gfp_mask, void *buffer, unsigned long bytes)
> +{
> + struct xencomm_desc *desc;
> + unsigned long buffer_ulong = (unsigned long)buffer;
> + unsigned long start = buffer_ulong & PAGE_MASK;
> + unsigned long end = (buffer_ulong + bytes) | ~PAGE_MASK;
> + unsigned long nr_addrs = (end - start + 1) >> PAGE_SHIFT;
> + unsigned long size = sizeof(*desc) +
> + sizeof(desc->address[0]) * nr_addrs;
> +
> + /*
> + * NOTE: kmalloc returns at least 64bit aligned value so that
> + * struct xencomm_desc doesn't cross page boundary.
> + */
> + BUILD_BUG_ON(sizeof(*desc) > sizeof(void*));
> + desc = kmalloc(size, gfp_mask);
> if (desc == NULL)
> panic("%s: page allocation failed\n", __func__);
> -
> - desc->nr_addrs = (PAGE_SIZE - sizeof(struct xencomm_desc)) /
> - sizeof(*desc->address);
> + desc->nr_addrs = nr_addrs;
>
> return desc;
> }
> @@ -176,7 +185,7 @@ xencomm_free(struct xencomm_handle *desc
> xencomm_free(struct xencomm_handle *desc)
> {
> if (desc)
> - free_page((unsigned long)__va(desc));
> + kfree(__va(desc));
> }
>
> int
> @@ -195,7 +204,7 @@ xencomm_create(void *buffer, unsigned lo
> return 0;
> }
>
> - desc = xencomm_alloc(gfp_mask);
> + desc = xencomm_alloc(gfp_mask, buffer, bytes);
> if (!desc) {
> printk("%s failure\n", "xencomm_alloc");
> return -ENOMEM;
>
>
> ___
> Xen-ia64-devel mailing list
> [EMAIL PROTECTED]
> http://lists.xensource.com/xen-ia64-devel
--
Alex Williamson HP Open Source & Linux Org.
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-ia64-devel] [PATCH 1/2] remove xencomm page size limit(xen side)
int from_pos = 0;
> unsigned int to_pos = 0;
> unsigned int i = 0;
>
> if (xencomm_debug)
> printk ("xencomm_copy_to_guest: to=%lx+%u n=%u\n",
> -(unsigned long)to, skip, n);
> +to_ulong, skip, n);
>
> if (XENCOMM_IS_INLINE(to)) {
> unsigned long dest_paddr = XENCOMM_INLINE_ADDR(to);
> @@ -263,8 +291,11 @@ xencomm_copy_to_guest(
> return 0;
> }
>
> +/* check if struct desc doesn't cross page boundry */
> +if (xencomm_desc_cross_page_boundary(to_ulong))
> +return -EINVAL;
> /* first we need to access the descriptor */
> -desc_addr = xencomm_paddr_to_maddr((unsigned long)to);
> +desc_addr = xencomm_paddr_to_maddr(to_ulong);
> if (desc_addr == 0)
> return -EFAULT;
>
> @@ -273,18 +304,26 @@ xencomm_copy_to_guest(
> printk("%s error: %p magic was 0x%x\n", __func__, desc, desc->magic);
> return -EFAULT;
> }
> +desc_paddr = (struct xencomm_desc*)to;
> +address = &desc->address[i];
>
> /* iterate through the descriptor, copying up to a page at a time */
> while ((from_pos < n) && (i < desc->nr_addrs)) {
> -unsigned long dest_paddr = desc->address[i];
> +unsigned long dest_paddr;
> unsigned int pgoffset;
> unsigned int chunksz;
> unsigned int chunk_skip;
>
> -if (dest_paddr == XENCOMM_INVALID) {
> -i++;
> -continue;
> -}
> +/* When crossing page boundary, machine address must be calculated.
> */
> +if (((unsigned long)address & ~PAGE_MASK) == 0) {
> +address = (unsigned long*)xencomm_paddr_to_maddr(
> +(unsigned long)&desc_paddr->address[i]);
> +if (address == NULL)
> +return -EFAULT;
> +}
> +dest_paddr = *address;
> +if (dest_paddr == XENCOMM_INVALID)
> +goto skip_to_next;
>
> pgoffset = dest_paddr % PAGE_SIZE;
> chunksz = PAGE_SIZE - pgoffset;
> @@ -308,7 +347,9 @@ xencomm_copy_to_guest(
> to_pos += bytes;
> }
>
> +skip_to_next:
> i++;
> +address++;
> }
> return n - from_pos;
> }
> @@ -320,15 +361,21 @@ xencomm_add_offset(
> void *handle,
> unsigned int bytes)
> {
> +unsigned long handle_ulong = (unsigned long)handle;
> struct xencomm_desc *desc;
> unsigned long desc_addr;
> +struct xencomm_desc *desc_paddr;
> +unsigned long *address;
> int i = 0;
>
> if (XENCOMM_IS_INLINE(handle))
> return (void *)((unsigned long)handle + bytes);
>
> +/* check if struct desc doesn't cross page boundry */
> +if (xencomm_desc_cross_page_boundary(handle_ulong))
> +return NULL;
> /* first we need to access the descriptor */
> -desc_addr = xencomm_paddr_to_maddr((unsigned long)handle);
> +desc_addr = xencomm_paddr_to_maddr(handle_ulong);
> if (desc_addr == 0)
> return NULL;
>
> @@ -337,18 +384,26 @@ xencomm_add_offset(
> printk("%s error: %p magic was 0x%x\n", __func__, desc, desc->magic);
> return NULL;
> }
> +desc_paddr = (struct xencomm_desc*)handle;
> +address = &desc->address[i];
>
> /* iterate through the descriptor incrementing addresses */
> while ((bytes > 0) && (i < desc->nr_addrs)) {
> -unsigned long dest_paddr = desc->address[i];
> +unsigned long dest_paddr;
> unsigned int pgoffset;
> unsigned int chunksz;
> unsigned int chunk_skip;
>
> -if (dest_paddr == XENCOMM_INVALID) {
> -i++;
> -continue;
> -}
> +/* When crossing page boundary, machine address must be calculated.
> */
> +if (((unsigned long)address & ~PAGE_MASK) == 0) {
> +address = (unsigned long*)xencomm_paddr_to_maddr(
> +(unsigned long)&desc_paddr->address[i]);
> +if (address == NULL)
> +return NULL;
> +}
> +dest_paddr = *address;
> +if (dest_paddr == XENCOMM_INVALID)
> +goto skip_to_next;
>
> pgoffset = dest_paddr % PAGE_SIZE;
> chunksz = PAGE_SIZE - pgoffset;
> @@ -356,13 +411,15 @@ xencomm_add_offset(
> chunk_skip = min(chunksz, bytes);
> if (chunk_skip == chunksz) {
> /* exhausted this page */
> -desc->address[i] = XENCOMM_INVALID;
> +*address = XENCOMM_INVALID;
> } else {
> -desc->address[i] += chunk_skip;
> +*address += chunk_skip;
> }
> bytes -= chunk_skip;
> -
> - i++;
> +
> +skip_to_next:
> +i++;
> +address++;
> }
> return handle;
> }
>
>
> ___
> Xen-ia64-devel mailing list
> [EMAIL PROTECTED]
> http://lists.xensource.com/xen-ia64-devel
--
Alex Williamson HP Open Source & Linux Org.
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] new repo layout?
On Mon, 2007-06-04 at 22:38 +0100, Ian Campbell wrote: > On Mon, 2007-06-04 at 14:15 -0500, Hollis Blanchard wrote: > > > This way we'll end up with common names like: > > > > > > /xen-unstable.hg > > > /linux-2.6.18-xen.hg > > > /staging/xen-unstable.hg > > > /staging/linux-2.6.18-xen.hg > > > /ext/ia64/xen-unstable.hg > > > /ext/ia64/linux-2.6.18-xen.hg > > > > > > Sound good? Thanks, > > > > Sounds good to me. > > I'll look into making these changes tomorrow, with symlinks so the old > names remain valid hopefully. > > (I presume you need someone at XenSource to do the moves for you?) Yes. Thanks, Alex -- Alex Williamson HP Open Source & Linux Org. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] new repo layout?
On Mon, 2007-06-04 at 12:46 -0500, Hollis Blanchard wrote: > On Mon, 2007-06-04 at 11:25 -0600, Alex Williamson wrote: > > > > > Another option would be to move the ia64 and ppc trees into separate > > > subdirectories of /ext/. I'm open to other alternatives. > > > >So far, this sounds like the best option. This way it would work > > just like the staging tree builds and would hopefully be less likely > > to get broken. We might also gain some flexibility in being able to > > create new repos in the subdirectory. Thanks, > > If you're suggesting moving all PPC repositories, including the Linux > tree, into http://xenbits.xensource.com/ext/powerpc/ , then that's fine > with me. Yep, I think this is the way to go. So we'll have: http://xenbits.xensource.com/ext/powerpc/ http://xenbits.xensource.com/ext/ia64/ Each will have a linux-2.6.18-xen.hg repo in it that will be maintained by the arch maintainers and used for pulls into upstream. The default arch Xen branch needs to be moved into the directory as well. I also think it might be good to standardize on names. I'd like the xen-ia64-unstable.hg repo to be renamed to xen-unstable.hg. This way we'll end up with common names like: /xen-unstable.hg /linux-2.6.18-xen.hg /staging/xen-unstable.hg /staging/linux-2.6.18-xen.hg /ext/ia64/xen-unstable.hg /ext/ia64/linux-2.6.18-xen.hg Sound good? Thanks, Alex -- Alex Williamson HP Open Source & Linux Org. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: Exporting native protocol ABI from domain builder
Hi Ian, On Tue, 2007-05-15 at 18:26 +0100, Ian Campbell wrote: > Hi guys, > > I'm not entirely sure this makes any sense for you since I don't think > either of you have 32on64 PV support but nevertheless here are the ia64 > and powerpc patches that go with xen-unstable.hg 15074:5c7a1e3abd54 Correct, ia64 doesn't support any 32bit guests and I haven't heard of anyone thinking of changing that. > I'm especially unsure about the value for xen-3.0-ia64be, does the > driver do the byte swapping itself or is a new protocol string required? Good question, IIRC I/O is kind of up in the air for big-endian guests right now. Dietmar did some patches but got resistance from upstream. So for now, not introducing a BE protocol ABI is probably correct. Dietmar, do you agree? > In the absence of any mixed mode support on your platforms it's harmless > to not apply but if you think it makes sense please go ahead. It looks reasonable to me and does give us a little flexibility should we decide to differentiate based on endian-ness at some point in the future. Thanks for thinking of us! Alex -- Alex Williamson HP Open Source & Linux Org. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] Re: [Xen-changelog] [xen-unstable] [HVM] save restore: new hyper-call
On Fri, 2007-01-19 at 11:50 -0600, Hollis Blanchard wrote:
> This patch breaks PowerPC, which does not supply arch_(get|
> set)hvm_ctxt(). In fact, I don't see where IA64 supplies these either.
We don't. This definitely breaks ia64 as well. Thanks,
Alex
--
Alex Williamson HP Open Source & Linux Org.
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] Re: [Xen-changelog] [xen-unstable] [IA64] fix xencomm_handle_is_null().
On Thu, 2006-11-16 at 09:55 -0600, Hollis Blanchard wrote:
>
> I think I'm missing something. Why did IA64 fork xencomm?
>
> I distinctly remember having conversations about sharing the code, which
> is obviously the right thing to do.
Because Tristan believed the resulting amount of shared code would
actually be very small (1 file) and we wanted to get his work into the
tree before he left Bull. We can still work to share as much as
possible even with the code split. Thanks,
Alex
--
Alex Williamson HP Open Source & Linux Org.
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] [PATCH] non-x86 build fix for libfsimage
IA64 & PPC aren't making use of this right now, but it's silly to have
the build fail for some trivial x86 specific assembly. I snagged the
appropriate bitops for ia64 and ppc (untested) and tossed in an
unoptimized option as well in case we want to make use of it. Thanks,
Alex
Signed-off-by: Alex Williamson <[EMAIL PROTECTED]>
---
diff -r b9fa39557370 tools/libfsimage/ext2fs/fsys_ext2fs.c
--- a/tools/libfsimage/ext2fs/fsys_ext2fs.c Fri Nov 10 08:58:47 2006 -0700
+++ b/tools/libfsimage/ext2fs/fsys_ext2fs.c Fri Nov 10 10:23:57 2006 -0700
@@ -232,6 +232,7 @@ struct ext2_dir_entry
#define S_ISREG(m) (((m) & S_IFMT) == S_IFREG)
#define S_ISDIR(m) (((m) & S_IFMT) == S_IFDIR)
+#if defined(__i386__) || defined(__x86_64__)
/* include/asm-i386/bitops.h */
/*
* ffz = Find First Zero in word. Undefined if no zero exists,
@@ -250,6 +251,66 @@ ffz (unsigned long word)
: "r" (~word));
return word;
}
+
+#elif defined(__ia64__)
+
+typedef unsigned long __u64;
+
+#if __GNUC__ >= 4 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 4)
+# define ia64_popcnt(x) __builtin_popcountl(x)
+#else
+# define ia64_popcnt(x) \
+ ({\
+__u64 ia64_intri_res; \
+asm ("popcnt %0=%1" : "=r" (ia64_intri_res) : "r" (x)); \
+ia64_intri_res; \
+ })
+#endif
+
+static __inline__ unsigned long
+ffz (unsigned long word)
+{
+ unsigned long result;
+
+ result = ia64_popcnt(word & (~word - 1));
+ return result;
+}
+
+#elif defined(__powerpc__)
+
+static __inline__ int
+__ilog2(unsigned long x)
+{
+ int lz;
+
+ asm (PPC_CNTLZL "%0,%1" : "=r" (lz) : "r" (x));
+ return BITS_PER_LONG - 1 - lz;
+}
+
+static __inline__ unsigned long
+ffz (unsigned long word)
+{
+ if ((word = ~word) == 0)
+return BITS_PER_LONG;
+ return __ilog2(word & -word);
+}
+
+#else /* Unoptimized */
+
+static __inline__ unsigned long
+ffz (unsigned long word)
+{
+ unsigned long result;
+
+ result = 0;
+ while(word & 1)
+{
+ result++;
+ word >>= 1;
+}
+ return result;
+}
+#endif
/* check filesystem types and read superblock into memory buffer */
int
diff -r b9fa39557370 tools/libfsimage/reiserfs/fsys_reiserfs.c
--- a/tools/libfsimage/reiserfs/fsys_reiserfs.c Fri Nov 10 08:58:47 2006 -0700
+++ b/tools/libfsimage/reiserfs/fsys_reiserfs.c Fri Nov 10 10:23:57 2006 -0700
@@ -363,6 +363,8 @@ struct fsys_reiser_info
#define JOURNAL_START((__u32 *) (INFO + 1))
#define JOURNAL_END ((__u32 *) (FSYS_BUF + FSYS_BUFLEN))
+#if defined(__i386__) || defined(__x86_64__)
+
#ifdef __amd64
#define BSF "bsfq"
#else
@@ -376,6 +378,61 @@ grub_log2 (unsigned long word)
: "r" (word));
return word;
}
+
+#elif defined(__ia64__)
+
+#if __GNUC__ >= 4 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 4)
+# define ia64_popcnt(x) __builtin_popcountl(x)
+#else
+# define ia64_popcnt(x) \
+ ({\
+__u64 ia64_intri_res; \
+asm ("popcnt %0=%1" : "=r" (ia64_intri_res) : "r" (x)); \
+ia64_intri_res; \
+ })
+#endif
+
+static __inline__ unsigned long
+grub_log2 (unsigned long word)
+{
+ unsigned long result;
+
+ result = ia64_popcnt((word - 1) & ~word);
+ return result;
+}
+
+#elif defined(__powerpc__)
+
+static __inline__ int
+__ilog2(unsigned long x)
+{
+ int lz;
+
+ asm (PPC_CNTLZL "%0,%1" : "=r" (lz) : "r" (x));
+ return BITS_PER_LONG - 1 - lz;
+}
+
+static __inline__ unsigned long
+grub_log2 (unsigned long word)
+{
+ return __ilog2(word & -word);
+}
+
+#else /* Unoptimized */
+
+static __inline__ unsigned long
+grub_log2 (unsigned long word)
+{
+ unsigned long result = 0;
+
+ while (!(word & 1UL))
+{
+ result++;
+ word >>= 1;
+}
+ return result;
+}
+#endif
#define log2 grub_log2
static __inline__ int
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [Xen-devel] Re: [XenPPC] [PATCH] [POWERPC] fix vga.c compilation
On Wed, 2006-08-16 at 15:24 +0100, Keir Fraser wrote:
> Actually I'm not sure this is particularly necessary for headless x86
> either. I could move the test to the end of setup_vga(), and only probe
> 0xb8000?
Hi Keir,
Yeah, I think something like the below change to your previous patch
would be fine. Thanks!
Alex
Signed-off-by: Alex Williamson <[EMAIL PROTECTED]>
---
diff -r aa9ed07f34a5 xen/drivers/video/vga.c
--- a/xen/drivers/video/vga.c Wed Aug 16 08:38:18 2006 -0600
+++ b/xen/drivers/video/vga.c Wed Aug 16 08:46:30 2006 -0600
@@ -321,45 +321,6 @@ static int detect_video(void *video_base
return video_found;
}
-static int detect_vga(void)
-{
-int detected;
-void *p;
-
-if ( memory_is_conventional_ram(0xA) )
-return 0;
-
-/*
- * Look at a number of well-known locations. Even if video is not at
- * 0xB8000 right now, it will appear there when we set up text mode 3.
- *
- * We assume if there is any sign of a video adaptor then it is at least
- * VGA-compatible (surely noone runs CGA, EGA, these days?).
- *
- * These checks are basically to detect headless server boxes.
- */
-
-p = ioremap(0xA, 0x1000);
-detected = detect_video(p);
-iounmap(p);
-if ( detected )
-return 1;
-
-p = ioremap(0xB, 0x1000);
-detected = detect_video(p);
-iounmap(p);
-if ( detected )
-return 1;
-
-p = ioremap(0xB8000, 0x1000);
-detected = detect_video(p);
-iounmap(p);
-if ( detected )
-return 1;
-
-return 0;
-}
-
/* This is actually code from vgaHWRestore in an old version of XFree86 :-) */
void *setup_vga(void)
{
@@ -378,9 +339,10 @@ void *setup_vga(void)
0x3b, 0x3c, 0x3d, 0x3e, 0x3f, 0x0c, 0x00, 0x0f, 0x08, 0x00
};
-int i, j;
-
-if ( !detect_vga() )
+int i, j, detected;
+void *p;
+
+if ( memory_is_conventional_ram(0xA) )
{
printk("No VGA adaptor detected!\n");
return NULL;
@@ -407,6 +369,12 @@ void *setup_vga(void)
inb(VGA_IS1_RC);
outb(0x20, VGA_ATT_IW);
+
+p = ioremap(0xB8000, 0x1000);
+detected = detect_video(p);
+iounmap(p);
+if ( !detected )
+return NULL;
return ioremap(0xB8000, 0x8000);
}
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [Xen-devel] Re: [XenPPC] [PATCH] [POWERPC] fix vga.c compilation
On Wed, 2006-08-16 at 11:49 +0100, Keir Fraser wrote: > Here you go. Arch/powerpc/vga.c isn't great but I assume it's > temporary > until vga support is fixed properly. > > If you think it looks okay I'll apply it. Also Sign-off or Ack if you > like. Hi Keir, In general this looks a lot better, but I think ia64 is still going to have trouble with the chunk below. It seems that a VGA card operating in a standard text mode doesn't necessarily respond to all of these addresses. On some ia64 platforms that causes a hard fail response (the bus goes fatal and a reboot follows). On my system, the 0xB8000 test looks like it will probably work, but we never get there because either the 0xA or the 0xB test will cause the hardfail. Do we need to poke the card through I/O port space to get it into the right mode before probing it in MMIO space? I don't know enough about the VGA programming model to be able to do that. The card works once we start talking to it correctly, but this probe is a little too brute force. Thanks, Alex > + > +p = ioremap(0xA, 0x1000); > +detected = detect_video(p); > +iounmap(p); > +if ( detected ) > +return 1; > + > +p = ioremap(0xB, 0x1000); > +detected = detect_video(p); > +iounmap(p); > +if ( detected ) > +return 1; > + > +p = ioremap(0xB8000, 0x1000); > +detected = detect_video(p); > +iounmap(p); > +if ( detected ) > +return 1; > + -- Alex Williamson HP Open Source & Linux Org. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] [PATCH] [POWERPC] fix vga.c compilation
On Tue, 2006-08-15 at 18:08 -0500, Hollis Blanchard wrote:
> # HG changeset patch
> # User Hollis Blanchard <[EMAIL PROTECTED]>
> # Date 1155683306 18000
> # Node ID 2250d38aed3854c626bdc642a91884754f9d12d8
> # Parent 6dcd85ea232e0de5445f325abd0829a0ed6d56a1
> [POWERPC] fix vga.c compilation
> - replace vga_readb/writeb with plain readb/writeb
> - add per-arch vga.c and vga.h
> - make detect_video() a per-arch function
> - stop doing void* arithmetic
> - remove i386 ifdef
Thanks Hollis. Keir, here's a patch that applies on top of the one
from Hollis that fixes up ia64 support for VGA console. Included is a
bug fix in the font setup that accessed the legacy VGA MMIO range as
cacheable memory. Thanks,
Alex
Signed-off-by: Alex Williamson <[EMAIL PROTECTED]>
---
diff -r b7cf184c3008 xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.cTue Aug 15 17:20:11 2006 -0600
+++ b/xen/arch/ia64/xen/domain.cTue Aug 15 17:57:48 2006 -0600
@@ -864,6 +864,7 @@ int construct_dom0(struct domain *d,
{
int i, rc;
start_info_t *si;
+ dom0_vga_console_info_t *ci;
struct vcpu *v = d->vcpu[0];
unsigned long max_pages;
@@ -1000,6 +1001,9 @@ int construct_dom0(struct domain *d,
//if ( initrd_len != 0 )
//memcpy((void *)vinitrd_start, initrd_start, initrd_len);
+ BUILD_BUG_ON(sizeof(start_info_t) + sizeof(dom0_vga_console_info_t) +
+sizeof(struct ia64_boot_param) > PAGE_SIZE);
+
/* Set up start info area. */
d->shared_info->arch.start_info_pfn = pstart_info >> PAGE_SHIFT;
start_info_page = assign_new_domain_page(d, pstart_info);
@@ -1034,7 +1038,8 @@ int construct_dom0(struct domain *d,
strncpy((char *)si->cmd_line, dom0_command_line, sizeof(si->cmd_line));
si->cmd_line[sizeof(si->cmd_line)-1] = 0;
- bp = (struct ia64_boot_param *)(si + 1);
+ bp = (struct ia64_boot_param *)((unsigned char *)si +
+ sizeof(start_info_t));
bp->command_line = pstart_info + offsetof (start_info_t, cmd_line);
/* We assume console has reached the last line! */
@@ -1048,6 +1053,16 @@ int construct_dom0(struct domain *d,
(PAGE_ALIGN(ia64_boot_param->initrd_size) + 4*1024*1024);
bp->initrd_size = ia64_boot_param->initrd_size;
+ ci = (dom0_vga_console_info_t *)((unsigned char *)si +
+sizeof(start_info_t) +
+sizeof(struct ia64_boot_param));
+
+ if (fill_console_start_info(ci)) {
+ si->console.dom0.info_off = sizeof(start_info_t) +
+ sizeof(struct ia64_boot_param);
+ si->console.dom0.info_size = sizeof(dom0_vga_console_info_t);
+ }
+
vcpu_init_regs (v);
vcpu_regs(v)->r28 = bp_mpa;
diff -r b7cf184c3008 xen/arch/ia64/xen/vga.c
--- a/xen/arch/ia64/xen/vga.c Tue Aug 15 17:20:11 2006 -0600
+++ b/xen/arch/ia64/xen/vga.c Tue Aug 15 17:57:48 2006 -0600
@@ -19,9 +19,9 @@
*/
#include
+#include
int detect_vga(void)
{
- /* disabled completely for now */
-return 0;
+return (efi_mem_type(0xA) != EFI_CONVENTIONAL_MEMORY);
}
diff -r b7cf184c3008 xen/drivers/video/vga.c
--- a/xen/drivers/video/vga.c Tue Aug 15 17:20:11 2006 -0600
+++ b/xen/drivers/video/vga.c Tue Aug 15 17:57:48 2006 -0600
@@ -472,7 +472,9 @@ int vga_load_font(const struct font_desc
{
unsigned i, j;
const uint8_t *data = font->data;
-uint8_t *map = (uint8_t *)__va(0xA) + font_slot*2*CHAR_MAP_SIZE;
+uint8_t *map = (uint8_t *)0xA + font_slot*2*CHAR_MAP_SIZE;
+
+map = ioremap(map, CHAR_MAP_SIZE);
for ( i = j = 0; i < CHAR_MAP_SIZE; )
{
diff -r b7cf184c3008 xen/include/asm-ia64/vga.h
--- a/xen/include/asm-ia64/vga.hTue Aug 15 17:20:11 2006 -0600
+++ b/xen/include/asm-ia64/vga.hTue Aug 15 17:57:48 2006 -0600
@@ -24,10 +24,4 @@
#define vgabase 0
#define VGA_OUTW_WRITE
-static int detect_vga(void)
-{
- /* disabled completely for now */
- return 0;
-}
-
#endif /* _ASM_VGA_H_ */
diff -r b7cf184c3008 linux-2.6-xen-sparse/arch/ia64/dig/setup.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux-2.6-xen-sparse/arch/ia64/dig/setup.cTue Aug 15 17:57:48
2006 -0600
@@ -0,0 +1,110 @@
+/*
+ * Platform dependent support for DIG64 platforms.
+ *
+ * Copyright (C) 1999 Intel Corp.
+ * Copyright (C) 1999, 2001 Hewlett-Packard Co
+ * Copyright (C) 1999, 2001, 2003 David Mosberger-Tang <[EMAIL PROTECTED]>
+ * Copyright (C) 1999 VA Linux Systems
+ * Copyright (C) 1999 Walt Drummond <[EMAIL PROTECTED]>
+ * Copyright (C) 1999 Vijay Chander <[EMAIL PROTECTED]>
+ */
+#include
+
+#include
+#include
+#inc
