Hi Andrew,
> On 21/08/15 00:33, Chris Brand wrote:
> > Ensure that every bit has a specific value.
> >
> > Reported-by: Julien Grall
> > Signed-off-by: Chris Brand
> > ---
> > v2 adds comments on pxn and avail.
>
> This is no functional change, if the compiler is conforming to the C spec.
>
>
> > 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 p
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
Ensure that every bit has a specific value.
Reported-by: Julien Grall
Signed-off-by: Chris Brand
---
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 01628f3e96cb..7a56b2cb463a 100644
--- a/xen/incl
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
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/include/asm
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
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 c
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
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
>> 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 previou
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
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
> Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN is
> meant,
> I suspect this is because the first support for Xen was for PV. This brough
> some
Typo : "brought"
Perhaps "resulted in" would be better ?
> misimplementation of helpers on ARM and make the developper confused
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 32
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 i
> 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
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
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
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
>>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
>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 a
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 = "brcm,
>Can I get your Tested-by on this patch?
Tested-by: Chris Brand
Chris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
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
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
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()
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 tha
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
29 matches
Mail list logo
