On Sat, Aug 23, 2025 at 08:59:13AM +0100, Julien Grall wrote:
>
> On 22/08/2025 21:09, Elliott Mitchell wrote:
> > There may be many more using it. Perhaps this
> > should even be done on the 4.20 branch given how long this has been
> > working?
>
> I am guessi
On Mon, Aug 25, 2025 at 10:07:18AM +0200, Jan Beulich wrote:
> On 22.08.2025 22:09, Elliott Mitchell wrote:
> > On Fri, Aug 15, 2025 at 10:14:42AM +0200, Jan Beulich wrote:
> >> On 14.08.2025 23:27, Demi Marie Obenour wrote:
> >>> On 8/14/25 02:55, Jan Beulic
On Sat, Aug 23, 2025 at 08:59:13AM +0100, Julien Grall wrote:
>
> On 22/08/2025 21:09, Elliott Mitchell wrote:
> > Since you're not pointing to anything definite, could it be everything
> > has been resolved?
>
> Unfortunately, the situation has not changed
On Fri, Aug 15, 2025 at 10:14:42AM +0200, Jan Beulich wrote:
> On 14.08.2025 23:27, Demi Marie Obenour wrote:
> > On 8/14/25 02:55, Jan Beulich wrote:
> >> On 06.08.2025 06:30, Elliott Mitchell wrote:
> >>> On Tue, Jul 01, 2025 at 10:01:13PM +0200, Paul Leiber wrote:
Sigh, resending as I lost some of the intended Cc targets when originally
creating the message. Sorry about the duplication for people who have
already seen, but I thought this might be worthy of wider discussion.
I would like to draw the attention of a few people on xen-devel to the
thread whi
On Thu, Jul 17, 2025 at 07:29:51AM -0700, Jakub Kicinski wrote:
> On Tue, 15 Jul 2025 16:11:29 + Anthoine Bourgeois wrote:
> > Fixes: b27d47950e48 ("xen/netfront: harden netfront against event channel
> > storms")
>
> Not entirely sure who you expect to apply this patch, but if networking
> t
On Wed, Jul 16, 2025 at 11:31:06AM -0700, Elliott Mitchell wrote:
> On Wed, Jul 16, 2025 at 07:47:48AM +, Anthoine Bourgeois wrote:
> > On Tue, Jul 15, 2025 at 12:19:34PM -0700, Elliott Mitchell wrote:
> > >On Tue, Jul 15, 2025 at 08:21:40AM +, Anthoine Bourgeois wrote:
&
On Wed, Jul 16, 2025 at 07:47:48AM +, Anthoine Bourgeois wrote:
> On Tue, Jul 15, 2025 at 12:19:34PM -0700, Elliott Mitchell wrote:
> >On Tue, Jul 15, 2025 at 08:21:40AM +, Anthoine Bourgeois wrote:
> >> On Mon, Jul 14, 2025 at 05:37:51PM -0700, Elliott Mitchell wrote:
&g
On Tue, Jul 15, 2025 at 08:21:40AM +, Anthoine Bourgeois wrote:
> On Mon, Jul 14, 2025 at 05:37:51PM -0700, Elliott Mitchell wrote:
> >On Mon, Jul 14, 2025 at 07:11:06AM +, Anthoine Bourgeois wrote:
> >> On Fri, Jul 11, 2025 at 05:33:43PM +0200, Juergen Gross wrote:
>
On Mon, Jul 14, 2025 at 07:11:06AM +, Anthoine Bourgeois wrote:
> On Fri, Jul 11, 2025 at 05:33:43PM +0200, Juergen Gross wrote:
> >On 10.07.25 18:11, Anthoine Bourgeois wrote:
> >> We found at Vates that there are lot of spurious interrupts when
> >> benchmarking the PV drivers of Xen. This is
On Fri, Jul 11, 2025 at 07:41:02AM +, Anthoine Bourgeois wrote:
> On Thu, Jul 10, 2025 at 01:05:47PM -0700, Elliott Mitchell wrote:
> >On Thu, Jul 10, 2025 at 04:11:15PM +, Anthoine Bourgeois wrote:
> >> We found at Vates that there are lot of spurious interrupts when
>
On Thu, Jul 10, 2025 at 04:11:15PM +, Anthoine Bourgeois wrote:
> We found at Vates that there are lot of spurious interrupts when
> benchmarking the PV drivers of Xen. This issue appeared with a patch
> that addresses security issue XSA-391 (see Fixes below). On an iperf
> benchmark, spurious
On Fri, May 23, 2025 at 12:22:44AM +0100, m...@alex0.net wrote:
> I think I’ve just uncovered a rather nasty bug in the xen_acpi_processor
> driver in dom0. If the vcpu count in dom0 is set to anything other than the
> exact number of physical cores, the xen_acpi_processor kernel driver will
> f
On Mon, May 12, 2025 at 03:00:18PM +0200, Jan Beulich wrote:
> On 12.05.2025 14:09, Andrew Cooper wrote:
> >
> > Now for the (new) controversial part. Since sending this, Linux has
> > decided to just #define auto __auto_type for C < 23, in order to start
> > writing C23 compatible code from now.
On Mon, Jan 27, 2025 at 10:44:33AM +0100, Roger Pau Monné wrote:
> On Fri, Jan 24, 2025 at 01:26:23PM -0800, Elliott Mitchell wrote:
> >
> > In fact what seems a likely reproduction on Intel hardware is the Intel
> > sound card issue. I notice that issue occurs when sound
On Thu, Mar 06, 2025 at 07:08:20PM +0800, Penny Zheng wrote:
> From: Roger Pau Monne
>
> When running as a PVH dom0 the ACPI MADT is crafted by Xen in order to
> report the correct numbers of vCPUs that dom0 has, so the host MADT is
> not provided to dom0. This creates issues when parsing the po
On Mon, Jan 27, 2025 at 10:44:33AM +0100, Roger Pau Monné wrote:
> On Fri, Jan 24, 2025 at 01:26:23PM -0800, Elliott Mitchell wrote:
> > On Fri, Jan 24, 2025 at 03:31:30PM +0100, Roger Pau Monné wrote:
> > >
> > > I think I've figured out the cause for those fau
On Fri, Jan 24, 2025 at 03:31:30PM +0100, Roger Pau Monné 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:
> >
> > https://bug
On Fri, Nov 15, 2024 at 07:46:07AM +0100, Jürgen Groß wrote:
> On 15.11.24 01:11, Elliott Mitchell wrote:
> > On Wed, Nov 13, 2024 at 08:20:02PM +0100, Jürgen Groß wrote:
> > > On 13.11.24 18:25, Elliott Mitchell wrote:
> > > >
> > > > Hopefully I'm
On Wed, Nov 13, 2024 at 08:20:02PM +0100, Jürgen Groß wrote:
> On 13.11.24 18:25, Elliott Mitchell wrote:
> > On Tue, Jul 09, 2024 at 08:36:18AM +, Andrei Semenov wrote:
> > >
> > > After some investigations we notices a huge performances drop (perfs
> > >
On Tue, Jul 09, 2024 at 08:36:18AM +, Andrei Semenov wrote:
>
> After some investigations we notices a huge performances drop (perfs divided
> by
> factor of 5) starting from 5.10.88 Linux kernel version on the AMD EPYC
> platforms. The patch introduced in this kernel version that allows to
>
On Tue, Sep 10, 2024 at 01:17:03PM +0200, Takashi Iwai wrote:
> On Mon, 09 Sep 2024 22:02:08 +0200,
> Elliott Mitchell wrote:
> >
> > On Sat, Sep 07, 2024 at 11:38:50AM +0100, Andrew Cooper wrote:
> > >
> > > Individual subsystems ought not to know or car
On Sat, Sep 07, 2024 at 11:38:50AM +0100, Andrew Cooper wrote:
> On 07/09/2024 8:46 am, Takashi Iwai wrote:
> > On Fri, 06 Sep 2024 20:42:09 +0200,
> > Ariadne Conill wrote:
> >> This patch attempted to work around a DMA issue involving Xen, but
> >> causes subtle kernel memory corruption.
> >>
> >
On Thu, Aug 15, 2024 at 10:33:52AM +0200, Jürgen Groß wrote:
> On 14.08.24 22:26, Elliott Mitchell wrote:
> > On Wed, Aug 14, 2024 at 08:15:38AM +0200, Jürgen Groß wrote:
> > > On 14.08.24 00:36, Elliott Mitchell wrote:
> > > >
> > > > Drat. I haven
On Wed, Aug 14, 2024 at 08:15:38AM +0200, Jürgen Groß wrote:
> On 14.08.24 00:36, Elliott Mitchell wrote:
> > On Tue, Aug 13, 2024 at 08:55:42PM +0200, Jürgen Groß wrote:
> > > On 13.08.24 19:49, Elliott Mitchell wrote:
> > > >
> > > > There is a possib
On Tue, Aug 13, 2024 at 08:55:42PM +0200, Jürgen Groß wrote:
> On 13.08.24 19:49, Elliott Mitchell wrote:
> > On Tue, Aug 13, 2024 at 01:16:06PM +0200, Jürgen Groß wrote:
> > >
> > > I don't see a connection here, as spurious interrupts (as seen by the
> > &
On Tue, Aug 13, 2024 at 01:16:06PM +0200, Jürgen Groß wrote:
> On 13.08.24 03:10, Elliott Mitchell wrote:
> > On Tue, Jul 09, 2024 at 11:37:07AM +0200, Jürgen Groß wrote:
> > >
> > > In both directories you can see the number of spurious events by looking
> >
On Tue, Jul 09, 2024 at 11:37:07AM +0200, Jürgen Groß wrote:
>
> In both directories you can see the number of spurious events by looking
> into the spurious_events file.
>
> In the end the question is why so many spurious events are happening. Finding
> the reason might be hard, though.
Hopeful
On Wed, Jul 10, 2024 at 12:19:20PM -0700, Elliott Mitchell wrote:
> On Tue, Jul 09, 2024 at 08:36:18AM +, Andrei Semenov wrote:
> >
> > Does anybody notice this behavior on his side? Can we do something
> > about it?
>
> I hadn't previously noticed this ma
On Tue, Jul 09, 2024 at 08:36:18AM +, Andrei Semenov wrote:
>
> Does anybody notice this behavior on his side? Can we do something
> about it?
I hadn't previously noticed this manifestation, but now that I know where
to look seems I'm also seeing the issue.
It also effects other lines of A
On Thu, Jul 04, 2024 at 03:08:00PM -0700, Elliott Mitchell wrote:
> On Mon, Jul 01, 2024 at 11:07:57AM -0700, Elliott Mitchell wrote:
> > On Thu, Jun 27, 2024 at 05:18:15PM -0700, Elliott Mitchell wrote:
> >
> > Most processors were mentioned roughly equally. Several had fe
On Mon, Jul 01, 2024 at 11:07:57AM -0700, Elliott Mitchell wrote:
> On Thu, Jun 27, 2024 at 05:18:15PM -0700, Elliott Mitchell wrote:
> > I'm rather surprised it was so long before the next system restart.
> > Seems a quiet period as far as security updates go. Good news i
On Thu, Jun 27, 2024 at 05:18:15PM -0700, Elliott Mitchell wrote:
> I'm rather surprised it was so long before the next system restart.
> Seems a quiet period as far as security updates go. Good news is I made
> several new observations, but I don't know how valuable these ar
On Thu, Aug 26, 2021 at 09:51:54AM +0200, Jan Beulich wrote:
> On 26.08.2021 03:18, Elliott Mitchell wrote:
>
> > What you're writing about would be looking for bugs in development
> > branches.
>
> Very much so, in case there are issues left, or ones have got
&g
I'm rather surprised it was so long before the next system restart.
Seems a quiet period as far as security updates go. Good news is I made
several new observations, but I don't know how valuable these are.
On Mon, May 13, 2024 at 10:44:59AM +0200, Roger Pau Monné wrote:
>
> Does booting with
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 r
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 de
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:
> >
> > https://bug
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
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: IO_PAGE_FAULT:
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 a
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
> >
> > EL
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
s, register naming and where
the op 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
> &
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
> > Fr
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 environments,
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 n
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 pag
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 an
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 introduc
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 no po
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 be
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 proposal fo
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 lin
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 re
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 s
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 X
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
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, b
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
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
---
This is the
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
1 - 100 of 395 matches
Mail list logo
