The man page for xf.cfg doesn't say much about strings in the Xen
configuration files, instead it simply says:
"STRING"
A string, surrounded by either single or double quotes. But if the
STRING is part of a SPEC_STRING, the quotes should be omitted.
Nothing about whether single-quotes
On Mon, Mar 25, 2019 at 10:20:05PM +, YOUNG, MICHAEL A. wrote:
> I have been testing the python3 changes committed to xen and found a few
> issues. There are a couple of ocaml python build scripts that don't work
> for me with python3, and I needed a few fixes to get pygrub to work,
>
On Fri, Feb 15, 2019 at 03:58:49AM -0700, Jan Beulich wrote:
> >>> On 15.02.19 at 05:23, wrote:
> > The MCE/EDAC support code appears to be in rather poor shape.
> >
> > The AMD code mentions Family 10h, which might have been available 10
> > years ago. They've likely been findable used with
The MCE/EDAC support code appears to be in rather poor shape.
The AMD code mentions Family 10h, which might have been available 10
years ago. They've likely been findable used with difficulty more
recently, but no hardware made in the past 5 years matches this profile.
The Intel code has had
On Sat, May 02, 2020 at 12:35:29PM -0500, Corey Minyard wrote:
> On Sat, May 02, 2020 at 12:46:14PM +0100, Julien Grall wrote:
> >
> > On 02/05/2020 03:16, Corey Minyard wrote:
> > >
> > > Nope. If you say 4096M of RAM, your issue is almost certainly DMA, but
> > > it's not (just) the Linux
On Tue, May 12, 2020 at 08:54:26PM +0100, Andrew Cooper wrote:
> On 12/05/2020 20:50, Elliott Mitchell wrote:
> > On Tue, May 12, 2020 at 11:52:25AM -0400, Jason Andryuk wrote:
> >> I was just looking to remove perl since it's a large dependency for
> >> thi
On Tue, May 12, 2020 at 11:52:25AM -0400, Jason Andryuk wrote:
> I was just looking to remove perl since it's a large dependency for
> this single use. I'm not tied to a particular approach.
Have you tried to remove Perl from a system? This is possible, but on
many systems there will be
On Tue, Sep 01, 2020 at 08:01:30AM +0200, Jan Beulich wrote:
> I'm aware, and hence I said "aim for". In cases like this what we
> often do is adjust things incrementally, as lines get touched anyway.
> Of course if you want to clean it up all in one go ...
What I've got has turned into a patch
On Tue, Sep 01, 2020 at 08:01:30AM +0200, Jan Beulich wrote:
> On 01.09.2020 00:55, Elliott Mitchell wrote:
> > On Mon, Aug 31, 2020 at 08:52:45AM +0200, Jan Beulich wrote:
> >> On 31.08.2020 08:37, Elliott Mitchell wrote:
> >>> Preferences in sorting?
> >&g
On Fri, Aug 28, 2020 at 09:24:41AM +0200, Jan Beulich wrote:
> On 28.08.2020 04:57, Elliott Mitchell wrote:
> > Subdirectories which have .gitignore files should not be referenced in
> > the global .gitignore files. Move several lines to appropriate subdirs.
> >
>
On Fri, Aug 28, 2020 at 09:22:14AM +0200, Jan Beulich wrote:
> Against which tree did you develop this? The change you're proposing
> has happened already quite some time ago, and is e.g. part of 4.14.
> Please make sure patch submissions are against at least the master
> branch, but preferably
mmit message by the
> committer; but if you???re going to send v2 anyway, might as well move it in.
>
I'm pretty sure there will be at this point. Just an issue of how many
more adjustments there will be.
On Mon, Aug 31, 2020 at 08:52:45AM +0200, Jan Beulich wrote:
> On 31.08.2020 08:37, E
On Thu, Sep 10, 2020 at 11:13:26AM +0200, Jan Beulich wrote:
> On 27.08.2020 21:09, Elliott Mitchell wrote:
> > --- a/tools/misc/.gitignore
> > +++ b/tools/misc/.gitignore
> > @@ -1 +1,22 @@
> > -xen-ucode
> > +/cpuperf/cpuperf-perfcntr
> > +/cpuperf/cp
On Thu, Sep 10, 2020 at 11:20:11AM +0200, Jan Beulich wrote:
> On 02.09.2020 00:02, Elliott Mitchell wrote:
> > --- a/.gitignore
> > +++ b/.gitignore
> > @@ -1,6 +1,5 @@
> > .hg
> > .*.cmd
> > -.*.tmp
>
> When the shell expands *.tmp, any .*
On Thu, Sep 10, 2020 at 08:10:08AM +0200, Jan Beulich wrote:
> On 09.09.2020 03:28, Elliott Mitchell wrote:
> > The top-level .gitignore file for Xen has gotten rather messy. Looks
> > like at times a few people may have added some blank lines looking
> > towards some later
On Fri, Sep 11, 2020 at 08:29:51AM +0200, Jan Beulich wrote:
> On 10.09.2020 20:22, Elliott Mitchell wrote:
> > I had *thought* "./" would restrict to capturing files in the current
> > directory, but after some testing and then some reading of the
> > docum
slash, "foo" also matches "bar/foo").
As a final step these were either sorted or formatted to match existing
file format.
Signed-off-by: Elliott Mitchell
---
Changes in v2:
- More information in commit message
- Rebased onto correct branch before submission
---
.gitignore
I think patches 01 and 02 are near ready for being committed. Patches
03-09 need varying degrees of polish before being in an official tree.
Patches 10 and 11 are pretty well initial rough outlines.
Elliott Mitchell (11):
gitignore: Move ignores from global to subdirectories
gitignore: Remove
ython is growing in use, since patterns for underscore files seem likely
to be added, add a safety pattern to ensure Python double-underscore
files are preserved.
I'm pretty sure anything .old is unlikely to need to remain in history.
Signed-off-by: Elliott Mitchell
---
Question I have is: Shou
ot;*.bin" were present, go after their duplicates
too.
"docs/txt/" covers "docs/txt/misc/*.txt" and "docs/txt/man/*.txt".
Signed-off-by: Elliott Mitchell
---
.gitignore | 17 -
1 file changed, 17 deletions(-)
diff --git a/.gitignore b/.gitignor
ious authors thought).
Slashes were left at the start of all filenames. Entries without slashes
match files in subdirectories, entries with a slash anywhere are a
specific path. I feel it is more consistent to have leading slashes on
all full paths.
Signed-off-by: Elliott Mitchell
---
Looking at th
ading slashes on
all full paths.
Signed-off-by: Elliott Mitchell
---
This is certainly *not* the final version. Problem is there are a bunch
of adjustments which are needed, but I don't want to include in a patch
without advice.
Notably, earlier in this series underscore patterns have come
with a slash anywhere are a
specific path. I feel it is more consistent to have leading slashes on
all full paths.
Signed-off-by: Elliott Mitchell
---
.gitignore | 12
docs/.gitignore | 8
2 files changed, 8 insertions(+), 12 deletions(-)
create mode 100644 docs/.gitignore
consistent to have leading slashes on
all full paths.
Signed-off-by: Elliott Mitchell
---
Hmm, looking at this and noticing "include/headers*.chk". I added
"/tools/libs/*/headers.chk" for the tools/.gitignore patch. Should this
be generalized to add either "head
leading slashes on
all full paths.
Signed-off-by: Elliott Mitchell
---
.gitignore | 32
stubdom/.gitignore | 32
2 files changed, 32 insertions(+), 32 deletions(-)
create mode 100644 stubdom/.gitignore
diff --git
hen Mercurial seems to be disappearing?
What is/was behind c1df7c6ab655bcbf97024e8b79e55ba554cde83f and are those
still useful? Presently they're still there, but in a situation like
this, removing this is more valuable than leaving them.
Signed-off-by: Elliott Mitchell
---
.gitignore |
in subdirectories, entries with a slash anywhere are a
specific path. I feel it is more consistent to have leading slashes on
all full paths.
Signed-off-by: Elliott Mitchell
---
I have a suspicion several of the patterns *should* be more general
and/or the OCAML area could use some local ignore
consistent to have leading slashes on
all full paths.
Signed-off-by: Elliott Mitchell
---
.gitignore| 5 -
config/.gitignore | 5 +
2 files changed, 5 insertions(+), 5 deletions(-)
create mode 100644 config/.gitignore
diff --git a/.gitignore b/.gitignore
index 3fea6c6b15..877c2579ab
Ick, I guess I'm also demonstrating how close to the head I was versus
how close I /thought/ I was.
Adjustment is pretty simple, "/arch/*/efi/ebmalloc.c" would be added to
xen/.gitignore in patch #06. "/include/*.h" would bd added to
tools/.gitignore in patch #10 (though #10 was pretty beta
of $(LD) since Python distutils appends $CFLAGS
to $LDFLAGS which breaks many linkers.
Signed-off-by: Elliott Mitchell
---
tools/pygrub/Makefile | 9 +
tools/python/Makefile | 9 +
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/tools/pygrub/Makefile b/tools/pygrub
On Mon, Sep 28, 2020 at 03:47:52PM +0900, Masami Hiramatsu wrote:
> This made progress with my Xen boot on DeveloperBox (
> https://www.96boards.org/product/developerbox/ ) with ACPI.
Adding your patch on top of Julien Grall's patch appears to push the Xen
boot of my target device (Raspberry PI
On Thu, Oct 15, 2020 at 03:02:59AM +0200, Marek Marczykowski-G??recki wrote:
> On Tue, Oct 13, 2020 at 01:26:06PM +, Wei Liu wrote:
> > On Sun, Oct 11, 2020 at 06:11:39PM -0700, Elliott Mitchell wrote:
> > > Having looked around a bit, I believe this is a Python 2/3 compati
On Tue, Oct 13, 2020 at 06:06:26PM -0700, Stefano Stabellini wrote:
> On Mon, 12 Oct 2020, Elliott Mitchell wrote:
> > I'm on different hardware, but some folks have setup Tianocore for it.
> > According to Documentation/arm64/acpi_object_usage.rst,
> > "Required: DS
of $(LD) since Python distutils appends $CFLAGS
to $LDFLAGS which breaks many linkers.
Signed-off-by: Elliott Mitchell
---
This is now the *third* time this has been sent to the list. Mark Pryor
has tested and confirms Python cross-building is working. There is one
wart left which I'm unsure
On Fri, Oct 09, 2020 at 06:47:22PM +0100, Julien Grall wrote:
> Would it be possible to consider backporting to 4.14 the following tools
> commit:
>
> d25cc3ec93eb "libxl: workaround gcc 10.2 maybe-uninitialized warning"
>
> This would help to build Xen tools on Debian Testing with GCC 10. I
>
On Mon, Oct 12, 2020 at 12:02:14PM -0700, Stefano Stabellini wrote:
> On Sat, 10 Oct 2020, Julien Grall wrote:
> > Therefore, I think the code should not try to find the STAO. Instead, it
> > should check whether the SPCR table is present.
>
> Yes, that makes sense, but that brings me to the next
On Mon, Sep 28, 2020 at 10:00:35PM +0900, Masami Hiramatsu wrote:
> I've missed the explanation of the attached patch. This prototype
> patch was also needed for booting up the Xen on my box (for the system
> which has no SPCR).
I'm pretty sure of this on the hardware I'm dealing with, but don't
On Fri, Oct 16, 2020 at 03:33:23PM -0700, Elliott Mitchell wrote:
> On the device I'm on (Raspberry PI 4B with Tianocore -> GRUB -> Xen) I
> discovered a SPCR table shows up if I boot with the device the output is
> plugged into is powered down. I'm guessing this causes Tianocore t
On Fri, Oct 09, 2020 at 07:15:20PM +0100, Julien Grall wrote:
> On 09/10/2020 15:22, Elliott Mitchell wrote:
> > Finding all the command-line console settings can be a challenge. I had
> > thought it was supposed to be "console=hvc0 earlycon=hvc0".
> >
> >
hether there is a better way
since I'm not familiar enough with the code.
As such, for both Masami Hiramatsu's "Hide UART address only if STAO..."
and Julien Grall's set of four:
Tested-by: Elliott Mitchell
--
(\___(\___(\__ --=> 8-) EHM <=-- _
On Fri, Oct 09, 2020 at 10:39:26AM +0100, Julien Grall wrote:
> On 08/10/2020 19:39, Elliott Mitchell wrote:
> > Your (Masami Hiramatsu) patch seems plausible, but things haven't
> > progressed enough for me to endorse it. Looks like something closer to
> > the core of ACP
On Wed, Aug 19, 2020 at 04:00:36AM +0200, Marek Marczykowski-G??recki wrote:
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index f360f5e228..b039143b8a 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> }
> memset(un, 0, sizeof(struct
On Wed, Aug 19, 2020 at 11:30:57AM +0100, Ian Jackson wrote:
> Marek Marczykowski-G??recki writes ("Re: [PATCH 2/2] libxl: fix
> -Werror=stringop-truncation in libxl__prepare_sockaddr_un"):
> > On Tue, Aug 18, 2020 at 08:43:56PM -0700, Elliott Mitchell wrote:
> > >
Subdirectories which have .gitignore files should not be referenced in
the global .gitignore files. Move several lines to appropriate subdirs.
Signed-off-by: Elliott Mitchell
---
Hopefully the commit message covers it. When moved to the subdirectories
I'm using "./" as otherwis
There is little reason to specially require CONFIG_EXPERT to come from
the environment. Worse, this makes replicating configurations much more
difficult.
Signed-off-by: Elliott Mitchell
---
This is mostly RFC due to insufficient testing. I am hopeful this
successfully changes things to have
Support for a very early console has existed for ARM for quite some
time. Previously EARLY_PRINTK had to be passed in as a Make variable,
instead of as a configuration option. Create the option to allow
selecting via .config.
Signed-off-by: Elliott Mitchell
---
This is mostly RFC due
of $(LD) since Python distutils appends $CFLAGS
to $LDFLAGS which breaks many linkers.
Signed-off-by: Elliott Mitchell
---
Simply resending this.
Having looked around a bit, I believe this is a Python 2/3 compatibility
issue. "distutils" for Python 2 likely lacked a separate $LDSHA
On Thu, Sep 24, 2020 at 05:44:09PM +0200, Jan Beulich wrote:
> On 02.09.2020 03:08, Elliott Mitchell wrote:
> > @@ -33,12 +38,12 @@ cscope.po.out
> > .vscode
> >
> > dist
> > -stubdom/*.tar.gz
> >
> > autom4te.cache/
> > config.log
On Sat, Sep 26, 2020 at 06:47:08PM -0700, Elliott Mitchell wrote:
> On the ARM device I'm trying to get operational the boot got distinctly
> further along so appears to be a distinct ACPI improvement here.
Just in case it wasn't clear, that does amount to:
Tested-by: Elliott Mitchell
On Fri, Sep 25, 2020 at 08:49:01AM +0200, Jan Beulich wrote:
> I don't think so, no - new ports will similarly have asm-/config.h,
> and there shouldn't be a requirement to "git add -f" them at that point.
> The role of such named files really is too different to have such a top
> level entry imo.
On Sat, Sep 26, 2020 at 09:55:38PM +0100, Julien Grall wrote:
> Xen on ARM has been broken for quite a while on ACPI systems. This
> series aims to fix it.
>
> Unfortunately I don't have a system with ACPI v6.0 or later (QEMU seems
> to only support 5.1). So I did only some light testing.
>
> I
rather tempted to add defaulting enabled, but I'm not yet confident
of going that far yet.
Signed-off-by: Elliott Mitchell
---
I hope a popular ARM device capable of running Xen will soon be running
Xen on ACPI/UEFI, but it isn't quite there yet. As such I would like to
have "default y&qu
Absence of a SPCR table likely means the console is a framebuffer. In
such case acpi_iomem_deny_access() should NOT fail.
Signed-off-by: Elliott Mitchell
---
xen/arch/arm/acpi/domain_build.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/xen/arch/arm
On Fri, Oct 23, 2020 at 04:59:30PM -0700, Stefano Stabellini wrote:
> This is what is going on. kernel/dma/swiotlb.c:swiotlb_init gets called
> and tries to allocate a buffer for the swiotlb. It does so by calling
>
> memblock_alloc_low(PAGE_ALIGN(bytes), PAGE_SIZE);
>
> In your case, the
On Fri, Oct 23, 2020 at 04:59:30PM -0700, Stefano Stabellini wrote:
> On Fri, 23 Oct 2020, Elliott Mitchell wrote:
> > Finally came up with one detail of a change I'd made in the right time
> > frame to trigger this issue. As such I can now control this behavior and
>
On Fri, Oct 23, 2020 at 04:59:30PM -0700, Stefano Stabellini wrote:
> This is what is going on. kernel/dma/swiotlb.c:swiotlb_init gets called
> and tries to allocate a buffer for the swiotlb. It does so by calling
>
> memblock_alloc_low(PAGE_ALIGN(bytes), PAGE_SIZE);
>
> In your case, the
On Fri, Oct 23, 2020 at 04:59:30PM -0700, Stefano Stabellini wrote:
> Note that I tried to repro the issue here at my end but it works for me
> with device tree. So the swiotlb_init memory allocation failure probably
> only shows on ACPI, maybe because ACPI is reserving too much low memory.
Found
d the x86 side so far.
On a Tianocore-utilizing Raspberry PI 4B, this series allows successful
boot (some other distinct issues remain). As such, for the series on an
ARM device:
Tested-by: Elliott Mitchell
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
On Mon, Oct 26, 2020 at 06:44:27PM +, Julien Grall wrote:
> Hi Elliott,
>
> On 26/10/2020 16:03, Elliott Mitchell wrote:
> > On Mon, Oct 26, 2020 at 01:31:42PM +, Julien Grall wrote:
> >> On 24/10/2020 06:35, Elliott Mitchell wrote:
> >>> ACPI has
On Mon, Oct 26, 2020 at 06:44:27PM +, Julien Grall wrote:
> On 26/10/2020 16:03, Elliott Mitchell wrote:
> > On Mon, Oct 26, 2020 at 01:31:42PM +, Julien Grall wrote:
> >> On 24/10/2020 06:35, Elliott Mitchell wrote:
> >>> ACPI has a distinct
> >>&g
ot allocate buffer");
> no_iotlb_memory = true;
> }
> @@ -362,6 +365,7 @@ swiotlb_late_init_with_tbl(char *tlb, unsigned long
> nslabs)
> io_tlb_orig_addr[i] = INVALID_PHYS_ADDR;
> }
> io_tlb_index = 0;
> + no_io
On Mon, Oct 26, 2020 at 01:31:42PM +, Julien Grall wrote:
> On 24/10/2020 06:35, Elliott Mitchell wrote:
> > ACPI has a distinct
> > means of specifying a limited DMA-width; the above fails, because it
> > assumes a *device-tree*.
>
> Do you know if it would be poss
to
device-tree. Add warnings about using ACPI advising users of present
situation.
Signed-off-by: Elliott Mitchell
---
Okay, hopefully this is okay. Warning in Kconfig, warning on boot.
Perhaps "default y if ARM_64" is redundant, yet if someone tries to make
it possible to boot aarch32
While hiding details of build output looks pretty to some, defaulting to
doing so deviates from the rest of Xen. Switch the OCAML tools to match
everything else.
Signed-off-by: Elliott Mitchell
---
Time for a bit of controversy.
Presently the OCAML tools build mismatches the rest of the Xen
This partially reverts commit 16504669c5cbb8b195d20412aadc838da5c428f7.
Signed-off-by: Elliott Mitchell
---
Doesn't look like much of 16504669c5cbb8b195d20412aadc838da5c428f7
actually remains due to passage of time.
Of the 3, both Python and pygrub appear to mostly be building just fine
cross
On Tue, Jul 21, 2020 at 12:26:45PM +, Wei Liu wrote:
> On Fri, Jul 17, 2020 at 08:31:21PM -0700, Elliott Mitchell wrote:
> > This partially reverts commit 16504669c5cbb8b195d20412aadc838da5c428f7.
>
> Ok, so this commit is really old.
Yup. It will still be visible in `
On Wed, Nov 25, 2020 at 10:57:31AM -0800, Stefano Stabellini wrote:
> On Tue, 24 Nov 2020, Elliott Mitchell wrote:
> > I've frankly got no idea how to ensure the correct device-tree is passed
> > to Xen. Is GRUB's `devicetree` command correct when loading Xen? Is a
> >
On Wed, Nov 25, 2020 at 10:57:31AM -0800, Stefano Stabellini wrote:
> On Tue, 24 Nov 2020, Elliott Mitchell wrote:
> > My testing section for Xen is:
> > xen_hypervisor /boot/xen-4.14-arm64.efi
> > xen_module /boot/vmlinuz-5.8.10-2rp4-6.1.7
> > root=U
Python distutils really looks like between 2 and 3, it took two steps
forward and then two steps backward.
First, it broke the linking step off of the compile step. Thus CC and
LDSHARED were separated, thus CFLAGS and LDFLAGS were separated. A
substantial step forwards. Yet then CFLAGS was
domain_build also
ignore these entries.
Signed-off-by: Elliott Mitchell
---
Looking at this, I think the problem is likely even larger than this and
really needs a proper solution closer to the core of the device-tree
code. Likely either all device-tree handling code needs to be audited
for ignoring
On Mon, Dec 07, 2020 at 07:36:11AM -0800, Elliott Mitchell wrote:
> Commit 5a37207df52066efefe419c677b089a654d37afc changed this behavior to
> ignore such banks. Unfortunately this means these empty nodes are
> visible to code which accesses the device trees. Have domain_build also
On Tue, Nov 24, 2020 at 08:45:32PM -0800, Roman Shaposhnik wrote:
> On Tue, Nov 24, 2020 at 8:41 PM Elliott Mitchell wrote:
> >
> > On Tue, Nov 24, 2020 at 08:01:32PM -0800, Roman Shaposhnik wrote:
> > > On Tue, Nov 24, 2020 at 7:37 PM Elliott Mitchell wrote:
> >
I finally have U-Boot -> GRUB -> Xen sort-of operational as an
alternative to Tianocore -> GRUB -> Xen on a Raspberry PI 4B.
Stefano Stabellini, how much of the Raspberry PI 4B hardware have you
observed being operational under Linux on Xen? In particular, have you
ever observed operational
On Tue, Nov 24, 2020 at 08:01:32PM -0800, Roman Shaposhnik wrote:
> On Tue, Nov 24, 2020 at 7:37 PM Elliott Mitchell wrote:
> > Presently I'm using a 5.8 kernel with your patches and haven't seen
> > graphical output under Xen with either boot stack. I've confirmed fully
> >
On Fri, Nov 27, 2020 at 11:59:10PM -0800, Roman Shaposhnik wrote:
> On Wed, Nov 25, 2020 at 7:36 PM Elliott Mitchell wrote:
> > Well, I've now got everything together for a "proper" Debian Raspberry PI
> > installation. Apparently since 5.2 (perhaps earlier, but 5.2 is
On Mon, Dec 21, 2020 at 06:28:35PM +, Julien Grall wrote:
> I was planning to review the first version today, but as you sent a new
> version I will answer on this one directly.
Mostly the commentary has been increasing, not so much the commit.
> On 21/12/2020 17:30, Elliott Mitch
On Tue, Dec 15, 2020 at 08:36:34AM -0800, Stefano Stabellini wrote:
> On Mon, 14 Dec 2020, Elliott Mitchell wrote:
> > The available examples seem geared towards Linux DomUs. I'm looking at a
> > FreeBSD installation image and it appears to expect an EFI firmware.
> >
Previously Xen had stopped processing Device Trees if an empty
(size == 0) memory bank was found.
Commit 5a37207df52066efefe419c677b089a654d37afc changed this behavior to
ignore such banks. Unfortunately this means these empty nodes are
visible to code which accesses the device trees. Have
Somewhat helpful to actually install the example configurations.
Signed-off-by: Elliott Mitchell
---
tools/examples/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/examples/Makefile b/tools/examples/Makefile
index f86ed3a271..fd8fba757d 100644
--- a/tools/examples/Makefile
Finally getting to the truly productive stages of my project with Xen on
ARM.
How many of the OSes which function as x86 DomUs for Xen, function as
ARM DomUs? Getting Linux operational was straightforward, but what of
others?
The available examples seem geared towards Linux DomUs. I'm looking
On Mon, Dec 14, 2020 at 06:35:14PM -0800, Roman Shaposhnik wrote:
> On Mon, Dec 14, 2020 at 6:16 PM Elliott Mitchell wrote:
> >
> > Finally getting to the truly productive stages of my project with Xen on
> > ARM.
> >
> > How many of the OSes which functi
On Thu, Oct 29, 2020 at 12:57:58PM -0700, Stefano Stabellini wrote:
> On Thu, 29 Oct 2020, J??rgen Gro?? wrote:
> > What about having a small domain parsing the ACPI booting first and use
> > that information for booting dom0?
> >
> > That dom would be part of the Xen build and the hypervisor
On Thu, Oct 22, 2020 at 07:38:26PM +0100, Julien Grall wrote:
> I don't think we are very consistent here... I would not add them
> myself, but I don't particularly mind them (I know some editors will add
> them automatically).
>
> I will keep them while committing. For the patch:
I would tend
On Thu, Oct 22, 2020 at 09:42:17AM +0200, Jan Beulich wrote:
> On 22.10.2020 00:12, Elliott Mitchell wrote:
> > --- a/xen/arch/arm/acpi/domain_build.c
> > +++ b/xen/arch/arm/acpi/domain_build.c
> > @@ -42,17 +42,18 @@ static int __init acpi_iomem_deny_access(struct domain
&g
On Thu, Oct 22, 2020 at 02:17:13PM -0700, Stefano Stabellini wrote:
> On Thu, 22 Oct 2020, Julien Grall wrote:
> > On 22/10/2020 02:43, Elliott Mitchell wrote:
> > > Linux requires UEFI support to be enabled on ARM64 devices. While many
> > > ARM64 devices l
On Mon, Oct 26, 2020 at 09:19:49AM +, Julien Grall wrote:
> On 23/10/2020 17:57, Stefano Stabellini wrote:
> > On Fri, 23 Oct 2020, Julien Grall wrote:
> >> I am sort of okay to remove EXPERT.
> >
> > OK. This would help (even without building it by default) because as you
> > go and look at
On Wed, Nov 04, 2020 at 03:57:49PM +0100, Jan Beulich wrote:
> --- a/tools/python/Makefile
> +++ b/tools/python/Makefile
> @@ -8,19 +8,21 @@ PY_CFLAGS = $(CFLAGS) $(PY_NOOPT_CFLAGS)
> PY_LDFLAGS = $(SHLIB_LDFLAGS) $(APPEND_LDFLAGS)
> INSTALL_LOG = build/installed_files.txt
>
> +setup.py =
On Thu, Nov 05, 2020 at 10:31:06PM +, Julien Grall wrote:
> Even if debug trap are only meant for debugging purpose, it is quite
> harsh to crash Xen if one of the trap sent by the guest is not handled.
>
> So switch from a panic() to a printk().
Might this qualify as security due to
On Wed, Oct 28, 2020 at 05:37:02PM -0700, Stefano Stabellini wrote:
> On Tue, 27 Oct 2020, Elliott Mitchell wrote:
> > On Mon, Oct 26, 2020 at 06:44:27PM +, Julien Grall wrote:
> > > On 26/10/2020 16:03, Elliott Mitchell wrote:
> > > > On Mon, Oct 26, 2020 at
Add several features to specify output. Allow omitting potentially
unneeded lines and add argument for exact line format.
Signed-off-by: Elliott Mitchell
---
tools/xl/xl_list.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/tools/xl/xl_list.c b/tools/xl
Often it is desireable to only list a specific subset of fields, or list
them in an unusual order. Previously `xl list` gave output in a fixed
order, now add "-F" to allow specifying fields and formatting.
Signed-off-by: Elliott Mitchell
---
tools/xl/xl_cmdtable.c | 14
format() is meant to be a powerful tool, sweep the remaining bits
away. Unfortunately I am unable to test this portion.
Signed-off-by: Elliott Mitchell
---
tools/xl/xl_list.c | 44
1 file changed, 8 insertions(+), 36 deletions(-)
diff --git a/tools
Implement a generalized output formatting function for the `xl list`
subcommands. Notably `xl list` and `xl vm-list` could make use of
alternative output list formats.
Signed-off-by: Elliott Mitchell
---
I'm a bit unsure of #include . When looking for an
implementation of ARRAY_SIZE
Everything previously done by list_domains() is now done with
build_list_domain_format() and format().
Signed-off-by: Elliott Mitchell
---
tools/xl/xl_list.c | 90 +++---
1 file changed, 53 insertions(+), 37 deletions(-)
diff --git a/tools/xl/xl_list.c b
On Mon, Dec 21, 2020 at 06:28:35PM +, Julien Grall wrote:
> On 21/12/2020 17:30, Elliott Mitchell wrote:
> > I doubt this is the only bug exposed by
> > 5a37207df52066efefe419c677b089a654d37afc.
>
> Are you saying that with my patch dropped, Xen will boot but with it
&
Anything *_is_empty(), *_is_default(), or *_gen_json() is going to be
examining the pointed to thing, not modifying it. This potentially
results in higher-performance output. This also allows spreading
constants further, allowing more checking and security.
Signed-off-by: Elliott Mitchell
This should result in fewer branch instructions and a small performance
gain.
Signed-off-by: Elliott Mitchell
---
tools/libs/light/libxl_internal.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/libs/light/libxl_internal.c
b/tools/libs/light/libxl_internal.c
With libxl having gotten a lot more constant, now printf_info_sexp() and
printf_info_one_json() can add consts. May not be particularly
important, but it is best to mark things constant when they are known to
be so.
Signed-off-by: Elliott Mitchell
---
tools/xl/xl.h | 2 +-
tools/xl
Add several features to specify output. Allow omitting potentially
unneeded lines and add argument for exact line format.
Signed-off-by: Elliott Mitchell
---
tools/xl/xl_cmdtable.c | 2 ++
tools/xl/xl_list.c | 16 +---
2 files changed, 15 insertions(+), 3 deletions(-)
diff
While the "vm-list" subcommand has far fewer fields than the "list"
subcommand, one might still desire to list a subset of the fields.
Signed-off-by: Elliott Mitchell
---
tools/xl/xl_cmdtable.c | 7 -
tools/xl/xl_list.c | 66 +--
1 - 100 of 357 matches
Mail list logo
