Re: [Xen-devel] [PATCH 2/2 v2] xen: arm: Set all bits in mfn_to_xen_entry()

2015-08-21 Thread Chris (Christopher) Brand
Hi Andrew, On 21/08/15 00:33, Chris Brand wrote: Ensure that every bit has a specific value. Reported-by: Julien Grall julien.gr...@citrix.com Signed-off-by: Chris Brand chris.br...@broadcom.com --- v2 adds comments on pxn and avail. This is no functional change, if the compiler

Re: [Xen-devel] [PATCH 2/2] xen: arm: Set all bits in mfn_to_xen_entry()

2015-08-17 Thread Chris (Christopher) Brand
Hi Julien, Thanks for the review. +.pxn = 0, I would add a comment to explain that this bit is reserved for PL2 stage 1 page table. Will do. +.avail = 0, I don't think this one is necessary. avail is not used by the hardware neither Xen. grep -rF pt.avail

Re: [Xen-devel] [PATCH 0/2] xen: arm: Ensure all PTE bits have a known value

2015-08-17 Thread Chris (Christopher) Brand
P.S. Apologies for any threading issues - I have not yet managed to get git send-email working properly. I'm usually using git format-patch to get a list of files (one per patch) and my cover letter (--cover-letter). Thanks. Then I use git send-email *.patch which will send the patch

Re: [Xen-devel] [PATCH v2] xen: arm: Support 32MB frametables

2015-08-14 Thread Chris (Christopher) Brand
Hi Julien, Thanks for the review. /* Create Xen's mappings of memory. - * Base and virt must be 32MB aligned and size a multiple of 32MB. + * Mapping_size must be either 2MB or 32MB. I would have generalize the function to support any mapping size. But I'm also fine with the current

[Xen-devel] [PATCH 0/2] xen: arm: Ensure all PTE bits have a known value

2015-08-14 Thread Chris (Christopher) Brand
Hi, This is more-or-less what Julien requested. He noted that pt.contig was never set to zero. When I looked further, I found other bits that were also never given a value. Looking at the callsites, they almost all seem to assume a value of zero, so that's what I went with. Patch 1 re-orders the

[Xen-devel] [PATCH 1/2] xen: arm re-order assignments in mfn_to_xen_entry()

2015-08-14 Thread Chris (Christopher) Brand
Shuffle lines around so that the assignments in mfn_to_xen_entry() occur in the same order as the bits are declared in lpae_pt_t. This makes it easier to see which ones are never given a value. No change in behaviour. Also fix a minor comment typo. Signed-off-by: Chris Brand

[Xen-devel] [PATCH 0/2] xen: arm: Ensure all PTE bits have a known value

2015-08-14 Thread Chris (Christopher) Brand
Hi, This is more-or-less what Julien requested. He noted that pt.contig was never set to zero. When I looked further, I found other bits that were also never given a value. Looking at the callsites, they almost all seem to assume a value of zero, so that's what I went with. Patch 1 re-orders the

[Xen-devel] [PATCH 2/2] xen: arm: Set all bits in mfn_to_xen_entry()

2015-08-14 Thread Chris (Christopher) Brand
Ensure that every bit has a specific value. Reported-by: Julien Grall julien.gr...@citrix.com Signed-off-by: Chris Brand chris.br...@broadcom.com --- xen/include/asm-arm/page.h | 5 + 1 file changed, 5 insertions(+) diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h index

Re: [Xen-devel] [PATCH v2] xen: arm: Support 32MB frametables

2015-08-13 Thread Chris (Christopher) Brand
Any thoughts on v2 ? Chris -Original Message- From: Chris (Christopher) Brand Sent: Friday, 07 August, 2015 1:41 PM To: 'Julien Grall'; xen-devel@lists.xen.org Cc: Stefano Stabellini; Ian Campbell (ian.campb...@citrix.com) Subject: [PATCH v2] xen: arm: Support 32MB frametables

[Xen-devel] [PATCH v2] xen: arm: Support 32MB frametables

2015-08-07 Thread Chris (Christopher) Brand
setup_frametable_mappings() rounds frametable_size up to a multiple of 32MB. This is wasteful on systems with less than 4GB of RAM, although it does allow the contig bit to be set in the PTEs. Where the frametable is less than 32MB in size, instead round up to a multiple of 2MB, not setting the

Re: [Xen-devel] [PATCH] xen: arm: Support 32MB frametables

2015-08-07 Thread Chris (Christopher) Brand
OOI, you win 30MB of RAM but how does this affect the performance? Fair question. :-) All I can say is that I don't see any noticeable difference on my system. Are there performance tests that you suggest I run ? Also, note that the new code is only executed if you specify a

Re: [Xen-devel] [PATCH] xen: arm: Support 32MB frametables

2015-08-07 Thread Chris (Christopher) Brand
Hi Julien, Thanks for the review. OOI, you win 30MB of RAM but how does this affect the performance? Fair question. :-) All I can say is that I don't see any noticeable difference on my system. Are there performance tests that you suggest I run ? Also, note that the new code is only executed

[Xen-devel] [PATCH] xen: arm: Support 32MB frametables

2015-08-06 Thread Chris (Christopher) Brand
setup_frametable_mappings() rounds frametable_size up to a multiple of 32MB. This is wasteful on systems with less than 4GB of RAM, although it does allow the contig bit to be set in the PTEs. Where the frametable is less than 32MB in size, instead round up to a multiple of 2MB, not setting the

[Xen-devel] [PATCH] xen: arm: Document xenheap_megabytes limitation

2015-07-23 Thread Chris (Christopher) Brand
In setup_mm(), the value passed as xenheap_megabytes gets converted to pages and passed to setup_xenheap_mappings(), which in turn passes it to create_32mb_mappings(), which contains an ASSERT that the value passed is a multiple of 32MB. So specifying any value that is not an integer multiple of

Re: [Xen-devel] ARM - why does setup_frametable_size() round frametable_size to 32MB ?

2015-07-20 Thread Chris (Christopher) Brand
Thanks, Ian. I tried that, and it does seem to work (everything boots, I can still bring up VMs, and I see an extra 16MB of free memory). The patch I came up with follows (it would be nice to share code between create_32mb_mappings() and create_2mb_mappings(), but the setting of the contig bit

[Xen-devel] [PATCH] xen: arm: Avoid reading beyond the last module

2015-07-17 Thread Chris (Christopher) Brand
nr_mods is set in add_boot_module() to the number of module array elements used. This function also ensures that nr_mods never exceeds MAX_MODULES (the size of the array). When looping through the array, the correct maximum index is nr_mods-1, not nr_mods. If the array is full, using the latter

[Xen-devel] ARM - why does setup_frametable_size() round frametable_size to 32MB ?

2015-07-17 Thread Chris (Christopher) Brand
Hi, I'm working on a platform with a mere 2GB of RAM, and trying to trim the Xen footprint down as much as possible. I've found two places where Xen uses more memory than it seems it needs to, one of which is the frametable. On a 2GB system, frametable_size is initially calculated as 16MB, but is

Re: [Xen-devel] [PATCH] xen: arm: Avoid reading beyond the last module

2015-07-17 Thread Chris (Christopher) Brand
It looks like the mail as been sent in HTML. Can you resend it in plain text? Re-sent, hopefully correctly this time. Chris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] Bug in devicetree_for_each_node() in xen/arch/arm/bootfdt.c ?

2015-07-15 Thread Chris (Christopher) Brand
As said by David, Xen will parse reg using the #address-cells and #size-cells of the parent. So it's normal to see 2GB. Does the same device tree reports 3GB on Linux? I suspect no. I'm not in the office today, so I can't test this, but I believe the answer is yes. But in fact the answer is

Re: [Xen-devel] Bug in devicetree_for_each_node() in xen/arch/arm/bootfdt.c ?

2015-06-24 Thread Chris (Christopher) Brand
As said by David, Xen will parse reg using the #address-cells and #size-cells of the parent. So it's normal to see 2GB. Does the same device tree reports 3GB on Linux? I suspect no. I'm not in the office today, so I can't test this, but I believe the answer is yes. I have this log from an

[Xen-devel] Bug in devicetree_for_each_node() in xen/arch/arm/bootfdt.c ?

2015-06-22 Thread Chris (Christopher) Brand
I've been trying to figure out why Xen only reports 2GB on my ARM platform that actually has 3GB, and I think I've found a bug, but I'm not familiar enough with the Xen code to fix it. The relevant parts of my dts are: /dts-v1/; / { model = Broadcom STB (7445d0); compatible =

Re: [Xen-devel] [PATCH] xen/arm: Propagate clock-frequency to DOMU if present in the DT timer node

2015-06-12 Thread Chris (Christopher) Brand
Can I get your Tested-by on this patch? Tested-by: Chris Brand chris.br...@broadcom.com Chris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen/arm: Propagate clock-frequency to DOMU if present in the DT timer node

2015-06-11 Thread Chris (Christopher) Brand
Hi Julien, The patch does work exactly as advertised. When I used dtc to convert CONFIG_DTB_FILE from dtb to dts, I could see that it didn't in fact have a timer clock-frequency node. After re-creating the dtb and rebuilding Xen, ls /proc/device-tree/timer/ shows a clock-frequency file. When

Re: [Xen-devel] [PATCH] xen/arm: Propagate clock-frequency to DOMU if present in the DT timer node

2015-06-10 Thread Chris (Christopher) Brand
Hi Julien, A simple export CONFIG_DTB_FILE= Are you using an absolute path? Absolute path, yes. So your patch isn't designed to help in this case (CNTFRQ set on core 0 only, no clock-frequency property in timer node of DT). Well, my patch is designed to propagate the clock-frequency

Re: [Xen-devel] [PATCH] xen/arm: Propagate clock-frequency to DOMU if present in the DT timer node

2015-06-08 Thread Chris (Christopher) Brand
Hi Julien, My test was limited as I don't have a platform where CNTFRQ/CNTFRQ_EL0 is not valid. I may have done a mistake in the code. Understood. That's why I thought it would be worthwhile posting my results :-) What I see is that in preinit_xen_time(), the call to dt_property_read_u32()

Re: [Xen-devel] [PATCH] xen/arm: Propagate clock-frequency to DOMU if present in the DT timer node

2015-06-05 Thread Chris (Christopher) Brand
Hi Julien, When the property clock-frequency is present in the DT timer node, it means that the bootloader/firmware didn't correctly configured the CNTFRQ/CNTFRQ_EL0 on each processor. I did try this out, and it didn't affect my results. I don't understand why, though :-) What I see is that

Re: [Xen-devel] [PATCH] xen/arm: Propagate clock-frequency to DOMU if present in the DT timer node

2015-06-04 Thread Chris (Christopher) Brand
Hi Julien, When the property clock-frequency is present in the DT timer node, it means that the bootloader/firmware didn't correctly configured the CNTFRQ/CNTFRQ_EL0 on each processor. I will test this patch, but it doesn't apply cleanly to the version of Xen I'm currently using, so I need to