On Wed, May 15, 2024 at 02:40:31PM +0100, Kelly Choi wrote:
>
> As explained previously, we are happy to help resolve issues and provide
> advice where necessary. However, to do this, our developers need the
> relevant information to provide accurate resolutions. Given that our
> developers have
On Tue, May 14, 2024 at 10:22:51AM +0200, Jan Beulich wrote:
> On 13.05.2024 22:11, Elliott Mitchell wrote:
> > On Mon, May 13, 2024 at 10:44:59AM +0200, Roger Pau Monné wrote:
> >> Why do you mask the device SBDF in the above snippet? I would really
> >> like to u
On Mon, May 13, 2024 at 10:44:59AM +0200, Roger Pau Monné wrote:
> On Fri, May 10, 2024 at 09:09:54PM -0700, Elliott Mitchell wrote:
> > On Thu, Apr 18, 2024 at 09:33:31PM -0700, Elliott Mitchell wrote:
> > >
> > > I suspect this is a case of there is some step which
On Thu, Apr 18, 2024 at 09:33:31PM -0700, Elliott Mitchell wrote:
>
> I suspect this is a case of there is some step which is missing from
> Xen's IOMMU handling. Perhaps something which Linux does during an early
> DMA setup stage, but the current Xen implementation does lazily?
>
On Thu, Apr 18, 2024 at 09:09:51AM +0200, Jan Beulich wrote:
> On 18.04.2024 08:45, Elliott Mitchell wrote:
> > On Wed, Apr 17, 2024 at 02:40:09PM +0200, Jan Beulich wrote:
> >> On 11.04.2024 04:41, Elliott Mitchell wrote:
> >>> On Thu, Mar 28, 2024 at 07:25
On Wed, Apr 17, 2024 at 02:40:09PM +0200, Jan Beulich wrote:
> On 11.04.2024 04:41, Elliott Mitchell wrote:
> > On Thu, Mar 28, 2024 at 07:25:02AM +0100, Jan Beulich wrote:
> >> On 27.03.2024 18:27, Elliott Mitchell wrote:
> >>> On Mon, Mar 25, 2024 at 02:43:44PM
On Thu, Mar 28, 2024 at 07:25:02AM +0100, Jan Beulich wrote:
> On 27.03.2024 18:27, Elliott Mitchell wrote:
> > On Mon, Mar 25, 2024 at 02:43:44PM -0700, Elliott Mitchell wrote:
> >> On Mon, Mar 25, 2024 at 08:55:56AM +0100, Jan Beulich wrote:
> >>>
> >
On Thu, Mar 28, 2024 at 08:22:31AM -0700, Elliott Mitchell wrote:
> On Thu, Mar 28, 2024 at 07:25:02AM +0100, Jan Beulich wrote:
> > On 27.03.2024 18:27, Elliott Mitchell wrote:
> > > On Mon, Mar 25, 2024 at 02:43:44PM -0700, Elliott Mitchell wrote:
> > >> On Mon, Ma
On Thu, Mar 28, 2024 at 07:25:02AM +0100, Jan Beulich wrote:
> On 27.03.2024 18:27, Elliott Mitchell wrote:
> > On Mon, Mar 25, 2024 at 02:43:44PM -0700, Elliott Mitchell wrote:
> >> On Mon, Mar 25, 2024 at 08:55:56AM +0100, Jan Beulich wrote:
> >>> On 22.03.2024
On Mon, Mar 25, 2024 at 02:43:44PM -0700, Elliott Mitchell wrote:
> On Mon, Mar 25, 2024 at 08:55:56AM +0100, Jan Beulich wrote:
> > On 22.03.2024 20:22, Elliott Mitchell wrote:
> > > On Fri, Mar 22, 2024 at 04:41:45PM +, Kelly Choi wrote:
> > >>
> >
On Mon, Mar 25, 2024 at 08:55:56AM +0100, Jan Beulich wrote:
> On 22.03.2024 20:22, Elliott Mitchell wrote:
> > On Fri, Mar 22, 2024 at 04:41:45PM +, Kelly Choi wrote:
> >>
> >> I can see you've recently engaged with our community with some issues you'd
> &
On Fri, Mar 22, 2024 at 04:41:45PM +, Kelly Choi wrote:
>
> I can see you've recently engaged with our community with some issues you'd
> like help with.
> We love the fact you are participating in our project, however, our
> developers aren't able to help if you do not provide the specific
I sent a ping on this about 2 weeks ago. Since the plan is to move x86
IOMMU under general x86, the other x86 maintainers should be aware of
this:
On Mon, Feb 12, 2024 at 03:23:00PM -0800, Elliott Mitchell wrote:
> On Thu, Jan 25, 2024 at 12:24:53PM -0800, Elliott Mitchell wrote:
> > A
On Mon, Mar 04, 2024 at 11:55:07PM +, Andrew Cooper wrote:
> On 25/01/2024 8:24 pm, Elliott Mitchell wrote:
> > The original observation features MD-RAID1 using a pair of Samsung
> > SATA-attached flash devices. The main line shows up in `xl dmesg`:
> >
> >
On Mon, Feb 12, 2024 at 03:23:00PM -0800, Elliott Mitchell wrote:
> On Thu, Jan 25, 2024 at 12:24:53PM -0800, Elliott Mitchell wrote:
> > Apparently this was first noticed with 4.14, but more recently I've been
> > able to reproduce the issue:
> >
> > htt
On Mon, Feb 19, 2024 at 06:01:54PM +0800, George Dunlap wrote:
>
> Looking at the *non*-4.18 downloads, nearly all of them have user
> agents that make it clear they're part of automated build systems:
> user agents like curl and wget, but also "Go-http-client", "libfetch",
On Thu, Jan 25, 2024 at 12:24:53PM -0800, Elliott Mitchell wrote:
> Apparently this was first noticed with 4.14, but more recently I've been
> able to reproduce the issue:
>
> https://bugs.debian.org/988477
>
> The original observation features MD-RAID1 using a pair of Samsu
On Wed, Jan 24, 2024 at 07:20:56AM -0800, Elliott Mitchell wrote:
> On Wed, Jan 24, 2024 at 08:23:15AM +0100, Jan Beulich wrote:
> >
> > Third, as to Dom0's purposes of having the address: If all it is to use
> > it for is to pass it back to Xen, paths in t
Apparently this was first noticed with 4.14, but more recently I've been
able to reproduce the issue:
https://bugs.debian.org/988477
The original observation features MD-RAID1 using a pair of Samsung
SATA-attached flash devices. The main line shows up in `xl dmesg`:
(XEN) AMD-Vi:
On Wed, Jan 24, 2024 at 08:23:15AM +0100, Jan Beulich wrote:
> On 23.01.2024 23:52, Elliott Mitchell wrote:
> > On Tue, Jan 23, 2024 at 11:44:03AM +0100, Jan Beulich wrote:
> >> On 22.01.2024 21:53, Elliott Mitchell wrote:
> >>
> >>> I find the present handli
On Tue, Jan 23, 2024 at 11:44:03AM +0100, Jan Beulich wrote:
> On 22.01.2024 21:53, Elliott Mitchell wrote:
>
> > I find the present handling of MCE in Xen an odd choice. Having Xen do
> > most of the handling of MCE events is a behavior matching a traditional
> > stan
I've been mentioning this on a regular basis, but the state of MCE
handling with Xen seems poor.
I find the present handling of MCE in Xen an odd choice. Having Xen do
most of the handling of MCE events is a behavior matching a traditional
stand-alone hypervisor. Yet Xen was originally pushing
On Sun, Jan 14, 2024 at 10:54:24PM +0100, Paul Leiber wrote:
>
> Am 22.10.2023 um 07:42 schrieb Paul Leiber:
> > Am 13.10.2023 um 20:56 schrieb Paul Leiber:
> >> Hi Xen developers list,
> >>
> >> TL;DR:
> >> --
> >>
> >> Causing certain web server traffic on a secondary VLAN on Raspberry Pi
On Mon, Dec 11, 2023 at 01:41:21PM -0500, Chuck Zmudzinski wrote:
> On 12/11/2023 12:59 PM, Mario Marietto wrote:
> > root@marietto:/mnt/zroot2/zroot2/OS/Chromebook/domU/freebsd-xen/boot-xen/kernel
> > # file
> > /mnt/zroot2/zroot2/OS/Chromebook/domU/freebsd-xen/boot-xen/kernel/kernel
> >
> >
On Mon, Nov 27, 2023 at 09:27:18AM +0100, Roger Pau Monn
> On Fri, Nov 24, 2023 at 05:15:34PM -0800, Elliott Mitchell wrote:
> > On Thu, Nov 23, 2023 at 10:39:37AM +0100, Roger Pau Monn
> > > On Tue, Nov 21, 2023 at 04:56:47PM -0800, Elliott Mitchell wrote:
> > > >
On Tue, Nov 28, 2023 at 03:04:50PM -0800, Elliott Mitchell wrote:
> On Tue, Nov 28, 2023 at 04:10:50PM +0100, Roger Pau Monné wrote:
> > On Tue, Nov 28, 2023 at 03:09:14PM +0100, Mario Marietto wrote:
> > > For booting a FreeBSD kernel as a guest OS on XEN,should we install x
code goes, very simple compatibility)
On Tue, Nov 28, 2023 at 02:45:40PM +0100, Roger Pau Monné wrote:
> On Mon, Nov 27, 2023 at 03:04:30PM -0800, Elliott Mitchell wrote:
> > BTW Roger Pau Monné, now that Xen 4.18 is out, take a look at the
> > "royger" branch?
>
On Mon, Nov 27, 2023 at 10:57:42AM -0500, Chuck Zmudzinski wrote:
> On 11/27/2023 10:22 AM, Chuck Zmudzinski wrote:
> >
> > I have been collaborating with Mario, and I can explain what we have done
> > so far :
> >
> > We are using Julien's patch set against an old development version of
> >
On Thu, Nov 23, 2023 at 10:39:37AM +0100, Roger Pau Monné wrote:
> On Tue, Nov 21, 2023 at 04:56:47PM -0800, Elliott Mitchell wrote:
> > It was insisted that full logs be sent to xen-devel. Perhaps I am
> > paranoid, but I doubt I would have been successful at scrubbing all
>
On Sat, Nov 18, 2023 at 11:33:55AM +, Andrew Cooper wrote:
> On 18/11/2023 3:04 am, Elliott Mitchell wrote:
> > On Fri, Nov 17, 2023 at 11:12:37AM +0100, Neowutran wrote:
> >> On 2023-11-07 11:11, Elliott Mitchell wrote:
> >>> On Mon, Oct 30, 2023 at 04:27:22PM +
On Fri, Nov 17, 2023 at 11:12:37AM +0100, Neowutran wrote:
> On 2023-11-07 11:11, Elliott Mitchell wrote:
> > On Mon, Oct 30, 2023 at 04:27:22PM +01
> > > On Mon, Oct 30, 2023 at 07:50:27AM -0700, Elliott Mitchell wrote:
> > > > On Tue, Oct 24, 2023 at 03:51:50P
On Tue, Nov 07, 2023 at 08:15:32PM +, Andrew Cooper wrote:
> On 07/11/2023 7:53 pm, Elliott Mitchell wrote:
> > I ran into the nestedhvm via the following path. I was considering the
> > feasibility of shedding tasks from a desktop onto a server running Xen.
> > I was l
I ran into the nestedhvm via the following path. I was considering the
feasibility of shedding tasks from a desktop onto a server running Xen.
I was looking at `man xl.cfg` and noticed "nestedhvm".
Since one of the tasks the computer handled was running other OSes in
fully simulated
On Mon, Oct 30, 2023 at 04:27:22PM +0100, Roger Pau Monné wrote:
> On Mon, Oct 30, 2023 at 07:50:27AM -0700, Elliott Mitchell wrote:
> > On Tue, Oct 24, 2023 at 03:51:50PM +0200, Roger Pau Monne wrote:
> > > diff --git a/xen/arch/x86/genapic/x2apic.c b/xen/arch/x86/genapic/x2
On Mon, Oct 30, 2023 at 04:27:22PM +0100, Roger Pau Monné wrote:
> On Mon, Oct 30, 2023 at 07:50:27AM -0700, Elliott Mitchell wrote:
> > On Tue, Oct 24, 2023 at 03:51:50PM +0200, Roger Pau Monne wrote:
> > > diff --git a/xen/arch/x86/genapic/x2apic.c b/xen/arch/x86/genapic/x2
On Tue, Oct 24, 2023 at 03:51:50PM +0200, Roger Pau Monne wrote:
> diff --git a/xen/arch/x86/genapic/x2apic.c b/xen/arch/x86/genapic/x2apic.c
> index 707deef98c27..15632cc7332e 100644
> --- a/xen/arch/x86/genapic/x2apic.c
> +++ b/xen/arch/x86/genapic/x2apic.c
> @@ -220,38 +239,56 @@ static struct
On Thu, Oct 05, 2023 at 09:54:26AM +0100, Julien Grall wrote:
> On 04/10/2023 22:13, Elliott Mitchell wrote:
> >>> I understand the situation is different on Arm vs x86, so if
> >>> edk2 is not supported on arm I guess it doesn't matter much whether
> >>>
On Wed, Oct 04, 2023 at 03:52:54PM -0700, Stefano Stabellini wrote:
> On Wed, 4 Oct 2023, Julien Grall wrote:
> > > > If we want to handle such firmware, I think it would be better if we
> > > > provide
> > > > an hypercall that would return the GFN where it is currently mapped.
> > >
> > > Sure,
On Wed, Oct 04, 2023 at 03:21:04PM -0700, Stefano Stabellini wrote:
> On Wed, 4 Oct 2023, Elliott Mitchell wrote:
> > On Wed, Oct 04, 2023 at 03:39:16PM +0200, Roger Pau Monné wrote:
> > > On Wed, Oct 04, 2023 at 02:03:43PM +0100, Julien Grall wrote:
> > > >
> >
Heavily trimming earlier messages. Also doing one response to cover
several items. Hopefully I'm not missing something which needs a
response.
On Wed, Oct 04, 2023 at 03:39:16PM +0200, Roger Pau Monné wrote:
> On Wed, Oct 04, 2023 at 02:03:43PM +0100, Julien Grall wrote:
> >
> > On 04/10/2023
On Tue, Oct 03, 2023 at 10:26:28AM +0200, Roger Pau Monné wrote:
> On Thu, Sep 28, 2023 at 07:49:18PM -0700, Elliott Mitchell wrote:
> > I'm trying to get FreeBSD/ARM operational on Xen/ARM. Current issue is
> > the changes with the handling of the shared information page app
On Fri, Sep 29, 2023 at 02:13:59PM -0700, Stefano Stabellini wrote:
> On Fri, 29 Sep 2023, Julien Grall wrote:
> > On 29/09/2023 00:19, Stefano Stabellini wrote:
> > > All callers of the bitmap_switch macro (which are all within bitmap.h)
> > > pass an int as first parameter. Do not assign it to
On Fri, Sep 29, 2023 at 08:24:37AM +0100, Julien Grall wrote:
> Hi Stefano,
>
> On 29/09/2023 00:19, Stefano Stabellini wrote:
> > All callers of the bitmap_switch macro (which are all within bitmap.h)
> > pass an int as first parameter. Do not assign it to an unsigned int
> > potentially
I'm trying to get FreeBSD/ARM operational on Xen/ARM. Current issue is
the changes with the handling of the shared information page appear to
have broken things for me.
With a pre-4.17 build of Xen/ARM things worked fine. Yet with a build
of the 4.17 release, mapping the shared information page
On Mon, Sep 25, 2023 at 08:27:31AM +0200, Jan Beulich wrote:
> On 22.09.2023 17:42, Elliott Mitchell wrote:
> > On Fri, Sep 22, 2023 at 10:21:21AM +0200, Jan Beulich wrote:
> >> On 21.09.2023 18:18, Elliott Mitchell wrote:
> >>> As such these incomplete definitions
On Fri, Sep 22, 2023 at 10:21:21AM +0200, Jan Beulich wrote:
> On 21.09.2023 18:18, Elliott Mitchell wrote:
> > Hypercall wrappers need the incomplete type definitions. Only when the
> > actual structure needed.
>
> While in the first sentence "only" looks to be
On Fri, Sep 15, 2023 at 01:56:31PM +0200, Borislav Petkov wrote:
> On Thu, Sep 14, 2023 at 10:02:05AM -0700, Elliott Mitchell wrote:
> > Indeed. At what point is the lack of information and response long
> > enough to simply commit a revert due to those lacks?
>
> At
, the wrapper is likely to be visible to generic source code.
Signed-off-by: Elliott Mitchell
---
trap_info_t and HYPERVISOR_set_trap_table() is something I ran into.
With the incomplete definition, the wrapper is accaptable to an ARM
compiler. Without the incomplete definition, it fails.
Note, this has
On Fri, Sep 08, 2023 at 05:59:11AM +0200, Borislav Petkov wrote:
> On Thu, Sep 07, 2023 at 08:08:00PM -0700, Elliott Mitchell wrote:
> > This reverts commit 767f4b620edadac579c9b8b6660761d4285fa6f9.
> >
> > There are at least 3 valid reasons why a VM may see MCE events/re
This reverts commit 767f4b620edadac579c9b8b6660761d4285fa6f9.
There are at least 3 valid reasons why a VM may see MCE events/registers.
First, the hypervisor may have a bug. Ideally this should be dealt with
by fixing the hypervisor. Failing that, the hypervisor and versions
effected need to
On Thu, Sep 07, 2023 at 08:56:51AM +0200, Jan Beulich wrote:
> On 06.09.2023 23:38, Elliott Mitchell wrote:
> > On Thu, Aug 31, 2023 at 07:52:05PM +, Development wrote:
> >>
> >> However, in 2009-02, "cegger" wrote MCA/MCE_in_Xen, a proposa
On Thu, Aug 31, 2023 at 07:52:05PM +, Development wrote:
>
> However, in 2009-02, "cegger" wrote MCA/MCE_in_Xen, a proposal for having
> xen start checking the information
> Xen started accessing the EDAC information (now called "MCE") at some
> point after that, which blocks the
On Thu, Aug 03, 2023 at 06:48:33PM +0100, Julien Grall wrote:
> Hi,
>
> On 03/08/2023 18:45, Elliott Mitchell wrote:
> > On Thu, Aug 03, 2023 at 05:34:31PM +0100, Julien Grall wrote:
> >>
> >> Not sure if this is related to the lack of answer. But I didn't receive
On Thu, Aug 03, 2023 at 05:34:31PM +0100, Julien Grall wrote:
>
> On 03/08/2023 17:13, Elliott Mitchell wrote:
> >
> > I didn't know which way to go, so with no idea which option to choose the
> > last one ended up winning out. Perhaps that was wrong yet I've still no
&g
On Thu, Aug 03, 2023 at 10:35:53AM +0200, Jan Beulich wrote:
>
> Some of the patches looks to have been posted previously as a 7-patch
> series. It would have been nice if therefore this one was marked as
> v2, indicating in a revision log what the differences are. It appears
> as if at least one
This enumerated value is never used outside of the lowest layer of the
configuration parser. As such, move to the internal header.
Fixes: a30910bfd7 ("libxlu: Handle += in config files")
Signed-off-by: Elliott Mitchell
---
I'm unsure whether this is fixing a30910bfd7. Placing XLU
These functions needs to cross the boundary between core and lower-layer.
As such split them in two. Pass most of the values from XLU_Config as
they can be used by the lower-layer.
Signed-off-by: Elliott Mitchell
---
tools/libs/util/libxlu_cfg.c | 47 ++-
tools
With XLU_ConfigValue now in libxlu_cfg.c, XLU_ConfigList can follow.
Fixes: 1a09c5113a ("libxlu: rework internal representation of setting")
Signed-off-by: Elliott Mitchell
---
Placing XLU_ConfigValue/XLU_ConfigList in libxlu_internal.h was certainly
*wrong*.
---
tools/libs/util/li
Rather than needing the full structure, for many operations the settings
pointer is enough.
Signed-off-by: Elliott Mitchell
---
tools/libs/util/libxlu_cfg.c | 13 -
tools/libs/util/libxlu_cfg_y.y | 1 +
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/tools/libs
The better to isolate the shared portion of the interface from the
low-level implementation.
Signed-off-by: Elliott Mitchell
---
tools/libs/util/libxlu_cfg.c | 7 ++-
tools/libs/util/libxlu_internal.h | 2 ++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/tools/libs/util
(). The new function
encompasses the full functionality of the macro.
Signed-off-by: Elliott Mitchell
---
Someone else can decide where xlu__disk_err() should have its linebreaks
and indentation. That string isn't very good.
I'm wondering about the return codes. *printf() can return errors, but
so many
Potentially allowing a different parser to be substituted.
Omit libxlu_internal.h from libxlu_cfg_i.c, since it is kept in
libxlu_cfg_y.h.
Signed-off-by: Elliott Mitchell
---
tools/libs/util/Makefile | 1 +
tools/libs/util/libxlu_cfg.c | 662
There are far more printf()s inside libxlu_cfg.c, so these had been left
alone briefly. Now attack all of these.
Signed-off-by: Elliott Mitchell
---
Note, several messages change mildly. The message in parse() didn't
previously include the filename.
---
tools/libs/util/libxlu_cfg.c | 78
This better breaks layers apart. xlu_cfg_destroy() now only knows about
the XLU_Config structure, while xlu__cfg_set_free() knows about
XLU_ConfigSetting.
Move declaration of xlu__cfg_set_free() to shared header to indicate it
will bridge layers.
Signed-off-by: Elliott Mitchell
Only the lowest layer of configuration handling looks inside XLU_Config.
As such the structure can move to this header instead of the shared
header.
Mark ->config_source as constant. Most places it truly is constant, only
the free() violates the constant.
Signed-off-by: Elliott Mitch
ce flex to
interface correctly.
Signed-off-by: Elliott Mitchell
---
According to the documentation api.prefix was introduced in Bison 2.6,
while braces became recommended with Bison 3.0. This seems sufficiently
in the past to be worth adopting now.
A better workaround for flex is needed.
---
tools/li
Hopefully make it clearer to others this is the key associated with the
storage value to retrieve.
Signed-off-by: Elliott Mitchell
---
tools/include/libxlutil.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/tools/include/libxlutil.h b/tools/include
The definition was needed due to XLU_ConfigValue being before Bison's
declaration of YYLTYPE. Since XLU_ConfigValue has moved to libxlu_cfg.c,
the duplication is now unnecessary.
Fixes: 1a09c5113a, 6ec86e91c8 ("libxlu: record location when parsing values")
Signed-off-by: Elliot
Update per Bison's obsolete warnings. Testing indicates these are simple
and safe.
Signed-off-by: Elliott Mitchell
---
Someone check for acceptable Bison versions?
I'm testing with Flex 2.6.4 and Bison 3.7.5.
---
tools/libs/util/libxlu_cfg_y.y | 11 +--
1 file changed, 5 insertions
At no point was the complete type for XLU_ConfigValue used anywhere
besides libxlu_cfg.c, overdue for a move.
Fixes: 1a09c5113a ("libxlu: rework internal representation of setting")
Signed-off-by: Elliott Mitchell
---
tools/libs/util/libxlu_cfg.c | 9 +
tools
, 1a09c5113a ("libxlu: rework internal representation of
setting")
Signed-off-by: Elliott Mitchell
---
@1a09c5113a deeper probing should have been done and figured out
everything needed to move to libxlu_cfg_i.h. Making use of %code would
have been better, but moving would have been suffici
of libxlu_internal.h.
Fixes: b104c3762d ('Replace config file parser for "xl"')
Signed-off-by: Elliott Mitchell
---
Ideally at @b104c3762d Bison might already have implemented its %code
feature. Less ideal, but workable CfgParseContext should have been
placed in libxlu_cfg_i.h, betwe
for libxlu_cfg_y.h.
Issue is libxlu_cfg.c's #include order didn't match and thus everything
was fragile.
Fixes: b104c3762d ('Replace config file parser for "xl"')
Signed-off-by: Elliott Mitchell
---
The bug @b104c3762d was the incorrect ordering of #includes in
libxlu_cfg.c. It should instead
The upper layer disk string parser doesn't need the internals of the
lower layer file parser. Split the layers apart. This looks to have
been a copy issue.
Fixes: 5c206536ad ("libxl: disks: new xlu_disk_parse function")
Signed-off-by: Elliott Mitchell
---
tools/libs/util/libxlu_
Warnings from Bison seem less likely to be urgent, but on general
principle enable everything.
Signed-off-by: Elliott Mitchell
---
tools/libs/util/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libs/util/Makefile b/tools/libs/util/Makefile
index c3b21875dc
This was added at b104c3762dc. Appears this was fixed in the intervening
decade. Otherwise this could have been an issue from using advanced
features of Bison. Now this appears unnecessary.
Signed-off-by: Elliott Mitchell
---
tools/libs/util/libxlu_cfg_i.h | 6 --
1 file changed, 6
lue_r". Similar
to other functions this is where the returned value is stored.
Signed-off-by: Elliott Mitchell
---
tools/include/libxlutil.h| 22 +++---
tools/libs/util/libxlu_cfg.c | 6 +++---
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/tools/include
ster, even
if copies are maintained on release branches.
Elliott Mitchell (22):
tools/utils: cleanup formatting of libxlutil.h
tools/utils: rename "n" arguments to "key"
tools/utils: remove old declaration of xlu__cfg_yyparse()
tools/utils: enable all Bison warnings
too
On Mon, Jul 31, 2023 at 06:09:41PM +0100, Ian Jackson wrote:
> Elliott Mitchell writes ("Re: Python in Domain Configurations"):
> > On Mon, Jul 31, 2023 at 05:59:55AM +0200, Marek Marczykowski-Górecki wrote:
> > > So, IMHO reducing config file from a full python (like
On Mon, Jul 31, 2023 at 05:59:55AM +0200, Marek Marczykowski-Górecki wrote:
> On Mon, Jul 24, 2023 at 01:28:24PM -0700, Elliott Mitchell wrote:
> > On Fri, Jul 07, 2023 at 03:13:07PM -0700, Elliott Mitchell wrote:
> > >
> > > The only context I could find was
On Thu, Jul 27, 2023 at 09:53:24PM +, Justin Stitt wrote:
> Technically, my patch yields subtly different behavior. The original
> implementation with `strncpy` would fill the entire destination buffer
> with null bytes [3] while `strscpy` will leave the junk, uninitialized
> bytes trailing
Normal behavior is to be silent. Generating a message for the preferred
input can be mistaken for an error. As such remove this message to match
other conditions.
Signed-off-by: Elliott Mitchell
---
This looks like a bit of printf()-debugging which never got removed. The
message serves
On Fri, Jul 07, 2023 at 03:13:07PM -0700, Elliott Mitchell wrote:
>
> The only context I could find was 54fbaf446b and
> https://wiki.xenproject.org/wiki/PythonInXlConfig which don't explain
> the reasoning.
>
> Would the maintainers be amenable to revisiting the decision t
On Thu, Jul 13, 2023 at 07:01:19PM -0700, Elliott Mitchell wrote:
>
> diff --git a/tools/libs/util/libxlu_cfg.c b/tools/libs/util/libxlu_cfg.c
> index 874f5abfb9..b2947cbfc9 100644
> --- a/tools/libs/util/libxlu_cfg.c
> +++ b/tools/libs/util/libxlu_cfg.c
> @@ -18,12 +18
Correcting the order of #includes and data type declarations allows the
remaining lower-layer structures to move to libxlu_cfg_i.h. Now
libxlu_internal.h is purely generalized routines meant to be shared
between all layers.
Signed-off-by: Elliott Mitchell
---
tools/libs/util/libxlu_cfg.c
This enumerated value is never used outside of the lowest layer of the
configuration parser. As such, move to the internal header.
Fixes: a30910bfd7 ("libxlu: Handle += in config files")
Signed-off-by: Elliott Mitchell
---
I'm unsure whether this is fixing a30910bfd7. Placing XLU
Isolate the lower layer configuration handling from the upper layer. Now
only the lowest layer of configuration handling looks inside XLU_Config.
Also make error messages a bit more consistent. Now PCI device parsing
will report filename.
Signed-off-by: Elliott Mitchell
---
Someone else can
The upper layer disk string parser doesn't need the internals of the
lower layer file parser. Split the layers apart. This is viable due
to the lower-layer internals having been removed from
libxlu_internals.h.
Signed-off-by: Elliott Mitchell
---
tools/libs/util/libxlu_disk.c | 1 -
1 file
XLU_ConfigSetting is only used inside libxl_cfg.c, so no need for it in
the internal header.
Similarly, xlu__cfg_set_free() is no longer used outside libxl_cfg.c, so
remove from header and redeclare static.
Signed-off-by: Elliott Mitchell
---
tools/libs/util/libxlu_cfg.c | 10
Hopefully make it clearer to others this is the key associated with the
storage value to retrieve.
Signed-off-by: Elliott Mitchell
---
tools/include/libxlutil.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/tools/include/libxlutil.h b/tools/include
lue_r". Similar
to other functions this is where the returned value is stored.
Signed-off-by: Elliott Mitchell
---
tools/include/libxlutil.h | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/tools/include/libxlutil.h b/tools/include/libxlut
ltiple layers. I've concluded the *_i.h headers are meant to
be isolated to specific layers.
Elliott Mitchell (7):
tools/utils: cleanup formatting of libxlutil.h
tools/utils: rename "n" arguments to "key"
tools/utils: move XLU_Operation to libxlu_cfg_i.h.h
tools/utils: int
On Wed, Jul 19, 2023 at 08:24:15AM +0200, Jan Beulich wrote:
> On 18.07.2023 22:58, Elliott Mitchell wrote:
> > On Fri, Jul 14, 2023 at 09:21:59AM +0200, Jan Beulich wrote:
> >> On 14.07.2023 05:44, Elliott Mitchell wrote:
> >>> On Fri, Jul 14, 2023 at 03:24:59AM +02
On Fri, Jul 14, 2023 at 09:21:59AM +0200, Jan Beulich wrote:
> On 14.07.2023 05:44, Elliott Mitchell wrote:
> > On Fri, Jul 14, 2023 at 03:24:59AM +0200, Marek Marczykowski-Górecki wrote:
> >> On Thu, Jul 13, 2023 at 05:16:40PM -0700, Elliott Mitchell wrote:
> >>>
On Fri, Jul 14, 2023 at 03:24:59AM +0200, Marek Marczykowski-Górecki wrote:
> On Thu, Jul 13, 2023 at 05:16:40PM -0700, Elliott Mitchell wrote:
> > The better to encourage moving to setting via string mode names.
>
> The numeric values needs to remain documented, otherwise int
The better to encourage moving to setting via string mode names.
Signed-off-by: Elliott Mitchell
---
I'm not actually sure what tsc_mode==0 does. I didn't find other
references, so I'm unsure how that should be modified.
---
docs/man/xen-tscmode.7.pod | 17 +
1 file changed, 9
Normal behavior is to be silent. Generating a message for the preferred
input can be mistaken for an error. As such remove this message to match
other conditions.
Signed-off-by: Elliott Mitchell
---
tools/xl/xl_parse.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/xl/xl_parse.c b
On Thu, Jul 13, 2023 at 08:34:52AM -0700, Elliott Mitchell wrote:
> On Thu, Jul 13, 2023 at 10:38:37AM +0200, Jan Beulich wrote:
> > On 12.07.2023 21:59, Elliott Mitchell wrote:
> > > This series has been seen previously. The issue is pretty simple, if
> > > ACPI e
On Thu, Jul 13, 2023 at 03:12:55PM +0200, Jan Beulich wrote:
> On 17.03.2023 20:53, Elliott Mitchell wrote:
> > --- a/xen/arch/x86/apic.c
> > +++ b/xen/arch/x86/apic.c
> > @@ -1419,12 +1420,13 @@ static void cf_check error_interrupt(struct
> > cpu_user_regs *regs)
>
On Thu, Jul 13, 2023 at 03:08:56PM +0200, Jan Beulich wrote:
> On 17.03.2023 20:45, Elliott Mitchell wrote:
> > Rather than adding ", " with each printf(), simply include them in the
> > string initially. This allows converting to strlcat() or other methods
> > whi
1 - 100 of 357 matches
Mail list logo
