('gnttab: allow setting max version per-domain')
> Signed-off-by: Roger Pau Monné
Acked-by: Marek Marczykowski-Górecki
> ---
> Cc: Ian Jackson
>
> Without this fix the python bindings won't be usable, as they will
> attempt to pass a max version of 0 which will be refused by the
still wonder why it
wasn't an issue before, although it could just be a race that was less
likely to loose before.
You can find some analysis of mine here:
https://lore.kernel.org/xen-devel/YXFxKC4shCATB913@mail-itl/
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature
the cache with appropriate value
- get_msr_xss() is not used anywhere - and thus not before any
set_msr_xss() that will fill the cache
Fixes: aca2a985a55a "xen: don't free percpu areas during suspend"
Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Jan Beulich
---
Changes in v2:
-
On Thu, Oct 21, 2021 at 03:44:27PM +0200, Roger Pau Monné wrote:
> On Mon, Oct 18, 2021 at 10:21:28AM +0200, Jan Beulich wrote:
> > On 24.08.2021 23:11, Andrew Cooper wrote:
> > > On 18/08/2021 13:44, Andrew Cooper wrote:
> > >> On 18/08/2021 12:30, Ma
if (balloon_state == BP_DONE && n_pages != -credit &&
n_pages < totalreserve_pages)
balloon_state = BP_EAGAIN;
It would be bad to finish waiting in this case.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
On Fri, Oct 29, 2021 at 12:22:18PM +0200, Juergen Gross wrote:
> On 29.10.21 11:57, Marek Marczykowski-Górecki wrote:
> > On Fri, Oct 29, 2021 at 06:48:44AM +0200, Juergen Gross wrote:
> > > On 28.10.21 22:16, Marek Marczykowski-Górecki wrote:
> > > > On Thu, Oc
On Fri, Oct 29, 2021 at 06:48:44AM +0200, Juergen Gross wrote:
> On 28.10.21 22:16, Marek Marczykowski-Górecki wrote:
> > On Thu, Oct 28, 2021 at 12:59:52PM +0200, Juergen Gross wrote:
> > > When running as PVH or HVM guest with actual memory < max memory the
> > >
tarted, which can consume lots of memory.
>
> In order to avoid random boot crashes in such cases, add a late init
> call to wait for ballooning down having finished for PVH/HVM guests.
>
> Cc:
> Reported-by: Marek Marczykowski-Górecki
> Signed-off-by: Juergen Gross
It may happen that i
wait for initial balloon down before
starting userspace
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Organization: Invisible Things Lab
Cc: Marek Marczykowski-Górecki
When HVM/PVH guest with maxmem > memory, a populate on demand feature is
used. Thi
On Sun, Jan 31, 2021 at 03:15:30AM +0100, Marek Marczykowski-Górecki wrote:
> On Tue, Sep 29, 2020 at 05:27:48PM +0200, Jürgen Groß wrote:
> > On 29.09.20 17:16, Marek Marczykowski-Górecki wrote:
> > > On Tue, Sep 29, 2020 at 05:07:11PM +0200, Jürgen Groß wrote:
> > >
On Tue, Oct 05, 2021 at 10:05:39AM +0200, Juergen Gross wrote:
> On 04.10.21 11:14, Marek Marczykowski-Górecki wrote:
> > On Mon, Oct 04, 2021 at 07:31:40AM +0200, Juergen Gross wrote:
> > > On 03.10.21 06:47, Marek Marczykowski-Górecki wrote:
> > > > Hi,
> > &g
On Mon, Oct 04, 2021 at 07:31:40AM +0200, Juergen Gross wrote:
> On 03.10.21 06:47, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > After updating a PVH domU to 5.4.150, I see xen-balloon thread using
> > 100% CPU (one thread).
> > This is a domain started
ink Xen
version matters here much.
I have _not_ managed to reproduce the issue on 5.10.70, nor 5.14.9. In
both cases, just after starting the domain, I see
current_kb=target_kb=716412. And writing 716924 to target_kb manually
does not cause xen-balloon thread to spin.
--
Best Regards,
Mar
on various VirtIO on Xen
approaches (since there is more than one) in a single place, including:
- key characteristics, differences
- who is involved
- status
- links to relevant threads, maybe
I'd propose to revive https://wiki.xenproject.org/wiki/Virtio_On_Xen
--
Best Regards,
Marek Marczykowski-Gó
to avoid such problems.
>
> Cc: sta...@vger.kernel.org
> Fixes: a799c2bd29d19c565 ("x86/setup: Consolidate early memory reservations")
> Reported-by: Marek Marczykowski-Górecki
> Signed-off-by: Juergen Gross
I confirm this fixes my boot issue too.
Tested-by: Marek Marczykowsk
On Tue, Sep 14, 2021 at 10:39:10AM +0200, Jan Beulich wrote:
> On 14.09.2021 09:14, Juergen Gross wrote:
> > On 13.09.21 14:50, Marek Marczykowski-Górecki wrote:
> >> Hi,
> >>
> >> Since 5.13, the Xen (PV) dom0 crashes on boot, before even printing the
> &
to avoid such problems.
>
> Cc: sta...@vger.kernel.org
> Fixes: a799c2bd29d19c565 ("x86/setup: Consolidate early memory reservations")
> Reported-by: Marek Marczykowski-Górecki
> Signed-off-by: Juergen Gross
Thanks, it works!
Tested-by: Marek Marczykowski-Górecki
> ---
> arc
Link: [1] https://lore.kernel.org/lkml/20201217201214.3414100-2-g...@fb.com
Link: https://lkml.kernel.org/r/20210302100406.22059-2-r...@kernel.org
Since this seems to affect Xen boot only, I'm copying xen-devel too.
Any ideas?
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Thin
On Tue, Aug 24, 2021 at 05:33:10PM +0200, Jan Beulich wrote:
> On 24.08.2021 12:28, Juergen Gross wrote:
> > It should be mentioned that a similar series has been posted some years
> > ago by Marek Marczykowski-Górecki, but this series has not been applied
> > due to a Xen h
req;
> + *final_extra_ring_req = *extra_ring_req;
>
> if (new_persistent_gnts)
> gnttab_free_grant_references(setup.gref_head);
> --
> 2.26.2
>
>
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
result will skip all the CPUs. The value is retrieve from a CPUID
> leaf. So it sounds like we don't set the leaft correctly.
>
> FWIW, I have also tried on Xen 4.11 and could spot the same issue. Does this
> ring any bell to you?
Is it maybe this:
https://lore.kernel.org/xen-devel/20201106003529.391649-1-bmas...@redhat.com/T/#u
?
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
I/MSI: Mask all unused MSI-X entries")
Cc: sta...@vger.kernel.org
Signed-off-by: Marek Marczykowski-Górecki
---
Cc: xen-devel@lists.xenproject.org
Changes in v2:
- update commit message (MSI -> MSI-X)
---
drivers/pci/msi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pci/
t MSI, so
> please update the subject line and the "masking MSI" below to reflect
> that.
Sure, thanks for pointing this out. Is the patch otherwise ok? Should I
post v2 with just updated commit message?
> On Thu, Aug 26, 2021 at 03:43:37PM +0200, Marek Marczykowski-Górecki wrote:
&
I: Mask all unused MSI-X entries")
Cc: sta...@vger.kernel.org
Signed-off-by: Marek Marczykowski-Górecki
---
Cc: xen-devel@lists.xenproject.org
---
drivers/pci/msi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index e5e75331b415..3a9f4f8ad8f9 1006
On Wed, Aug 25, 2021 at 05:55:09PM +0200, Jan Beulich wrote:
> On 25.08.2021 17:47, Marek Marczykowski-Górecki wrote:
> > If so, I guess the issue is the kernel trying to write directly, instead
> > of via some hypercall, right?
>
> Indeed. Or to be precise - the
On Wed, Aug 25, 2021 at 05:33:54PM +0200, Jan Beulich wrote:
> On 25.08.2021 17:24, Marek Marczykowski-Górecki wrote:
> > On recent kernel I get kernel panic when starting a Xen PV domain with
> > PCI devices assigned. This happens on 5.10.60 (worked on .54) and
> > 5.
ab9fc06f399f
Author: Thomas Gleixner
Date: Thu Jul 29 23:51:41 2021 +0200
PCI/MSI: Mask all unused MSI-X entries
I can reliably reproduce it on Xen 4.14 and Xen 4.8, so I don't think
Xen version matters here.
Any idea how to fix it?
--
Best Regards,
Marek Marczykowski-Górecki
Invisibl
or working 115200bps at the very least.
The specification for the 2-port card is available at:
https://www.maxlinear.com/product/interface/uarts/pcie-uarts/xr17v352
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v2:
- use read-modify-write for enabling ECB
- handle also 4- and 8-p
They don't modify it, after all.
Signed-off-by: Marek Marczykowski-Górecki
---
New in v3. There was "ns16550: do not override fifo size if explicitly
set" here before, but it's already committed.
---
xen/drivers/char/ns16550.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletion
On Thu, Aug 19, 2021 at 06:01:31PM +0200, Marek Marczykowski-Górecki wrote:
> On Thu, Aug 19, 2021 at 05:57:21PM +0200, Jan Beulich wrote:
> > On 18.08.2021 14:16, Marek Marczykowski-Górecki wrote:
> > > @@ -169,6 +172,29 @@ static void handle_dw_usr_busy_quirk(struct ns
On Thu, Aug 19, 2021 at 05:57:21PM +0200, Jan Beulich wrote:
> On 18.08.2021 14:16, Marek Marczykowski-Górecki wrote:
> > @@ -169,6 +172,29 @@ static void handle_dw_usr_busy_quirk(struct ns16550
> > *uart)
> > }
> > }
> >
> > +static void enable_
On Wed, Aug 18, 2021 at 01:44:31PM +0100, Andrew Cooper wrote:
> On 18/08/2021 12:30, Marek Marczykowski-Górecki wrote:
> > set_xcr0() and set_msr_xss() use cached value to avoid setting the
> > register to the same value over and over. But suspend/resume implicitly
> >
or working 115200bps at the very least.
The specification for the 2-port card is available at:
https://www.maxlinear.com/product/interface/uarts/pcie-uarts/xr17v352
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v2:
- use read-modify-write for enabling ECB
- handle also 4- and 8-p
If fifo size is already set via uart_params, do not force it to 16 - which
may not match the actual hardware. Specifically Exar cards have fifo of
256 bytes.
Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Jan Beulich
---
xen/drivers/char/ns16550.c | 3 ++-
1 file changed, 2 insertions
On Wed, Aug 18, 2021 at 02:05:05PM +0200, Jan Beulich wrote:
> On 18.08.2021 13:30, Marek Marczykowski-Górecki wrote:
> > --- a/xen/arch/x86/xstate.c
> > +++ b/xen/arch/x86/xstate.c
> > @@ -642,6 +642,13 @@ void xstate_init(struct cpuinfo_x86 *c
the cache with appropriate value
- get_msr_xss() is not used anywhere - and thus not before any
set_msr_xss() that will fill the cache
Fixes: aca2a985a55a "xen: don't free percpu areas during suspend"
Signed-off-by: Marek Marczykowski-Górecki
---
xen/arch/x86/xstate.c | 7 +++
1 file
than my
> suggested 6 year cutoff, so if this patch is applied to staging and
> not applied retrospectively, they could be removed.
>
> I'm not sure if this policy should be here in README (where the
> version support was until now) or in SUPPORT.md.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
On Wed, Aug 18, 2021 at 08:24:39AM +0200, Juergen Gross wrote:
> Marek,
>
> On 17.08.21 17:15, Juergen Gross wrote:
> > On 17.08.21 16:50, Marek Marczykowski-Górecki wrote:
> > I'll be looking into that.
>
> Could you please try the attached patch?
It works, thanks!
On Tue, Aug 17, 2021 at 04:04:24PM +0200, Jan Beulich wrote:
> On 17.08.2021 15:48, Marek Marczykowski-Górecki wrote:
> > On Tue, Aug 17, 2021 at 02:29:20PM +0100, Andrew Cooper wrote:
> >> On 17/08/2021 14:21, Jan Beulich wrote:
> >>> On 17.08.2021 15:06, Andrew C
CPU 0:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=]
(XEN) Faulting linear address: 0028
(XEN) ****
This is after adding brutal `this_cpu(xcr0) = 0` in xstate_init().
> What we actually want to do is read the hardware register into the
> cached location. %xcr0 is possibly the only lazy register we also do
> extra sanity checks on.
Yes, better load the actual XCR0 value into cache, instead of 0
(although in this very case, it will get immediately overwritten).
I've added similar cache init for XSS - and this one should be safe-ish
- get_msr_xss() is not used anywhere.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
On Tue, Aug 17, 2021 at 12:17:31PM +0100, Andrew Cooper wrote:
> On 17/08/2021 12:14, Marek Marczykowski-Górecki wrote:
> > On Tue, Aug 17, 2021 at 11:56:56AM +0100, Andrew Cooper wrote:
> >> Some versions of GCC complain with:
> >>
> >> traps.c:405:2
On Tue, Aug 17, 2021 at 12:14:36PM +0100, Andrew Cooper wrote:
> On 17/08/2021 12:02, Marek Marczykowski-Górecki wrote:
> > On Tue, Aug 17, 2021 at 03:25:21AM +0200, Marek Marczykowski-Górecki wrote:
> >> Hi,
> >>
> >> I've got another S3 issue:
> >>
arn,run_fn}")
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
> CC: Wei Liu
> CC: Marek Marczykowski-Górecki
>
> Not actually tested. I don't seem to have a new enough GCC to hand.
I have just compile-tested it and it seems to fix th
On Tue, Aug 17, 2021 at 03:25:21AM +0200, Marek Marczykowski-Górecki wrote:
> Hi,
>
> I've got another S3 issue:
>
> (XEN) Preparing system for ACPI S3 state.
> (XEN) Disabling non-boot CPUs ...
> (XEN) Broke affinity for IRQ1, new:
> (XEN) Broke affinity for IRQ16,
mpressed_size(feature_mask));
}
As can be seen above - the xsave size differs between BSP and other
CPU(s) - likely because of (not) loaded ucode update there.
I guess it's a matter of moving ucode loading somewhere else, right?
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
On Mon, Aug 16, 2021 at 02:18:33PM +0200, Jan Beulich wrote:
> On 16.08.2021 12:25, Marek Marczykowski-Górecki wrote:
> > On Mon, Aug 16, 2021 at 11:18:31AM +0200, Jan Beulich wrote:
> >> Hard to tell without knowing whether the extra reg - as per the spec -
> &
On Mon, Aug 16, 2021 at 11:18:31AM +0200, Jan Beulich wrote:
> On 16.08.2021 10:39, Marek Marczykowski-Górecki wrote:
> > On Mon, Aug 16, 2021 at 09:55:16AM +0200, Jan Beulich wrote:
> >> On 13.08.2021 20:31, Marek Marczykowski-Górecki wrote:
> >>> Besides standard
On Mon, Aug 16, 2021 at 09:55:16AM +0200, Jan Beulich wrote:
> On 13.08.2021 20:31, Marek Marczykowski-Górecki wrote:
> > Besides standard UART setup, this device needs enabling
> > (vendor-specific) "Enhanced Control Bits" - otherwise disabling hardware
> > contro
If fifo size is already set via uart_params, do not force it to 16 - which
may not match the actual hardware. Specifically Exar cards have fifo of
256 bytes.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/char/ns16550.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
cards only (based on vendor ID).
Additionally, Exar card supports fractional divisor (DLD[3:0] register,
at 0x10). This part is not supported here yet, and seems to not
be required for working 115200bps at the very least.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/char/ns165
19b50 ("x86/extable: Adjust extable handling to be shadow stack
> compatible")
> Reported-by: Marek Marczykowski-Górecki
> Signed-off-by: Andrew Cooper
With this path, I don't observe the crash anymore. Thanks!
Tested-by: Marek Marczykowski-Górecki
--
Best Regards,
Mare
On Tue, Aug 03, 2021 at 03:44:10PM +0200, Jan Beulich wrote:
> On 03.08.2021 15:30, Marek Marczykowski-Górecki wrote:
> > On Tue, Aug 03, 2021 at 03:16:14PM +0200, Jan Beulich wrote:
> >> On 03.08.2021 15:12, Marek Marczykowski-Górecki wrote:
> >>> On Tue, Aug 03,
On Tue, Aug 03, 2021 at 03:16:14PM +0200, Jan Beulich wrote:
> On 03.08.2021 15:12, Marek Marczykowski-Górecki wrote:
> > On Tue, Aug 03, 2021 at 03:06:50PM +0200, Jan Beulich wrote:
> >> On 03.08.2021 15:01, Marek Marczykowski-Górecki wrote:
> >>> Ok, then, jus
On Tue, Aug 03, 2021 at 03:06:50PM +0200, Jan Beulich wrote:
> On 03.08.2021 15:01, Marek Marczykowski-Górecki wrote:
> > Ok, then, just setting iommu_intremap=false should do the right thing,
>
> ... if "iommu=force" is in use (but not otherwise), ...
But that's t
On Tue, Aug 03, 2021 at 02:29:01PM +0200, Jan Beulich wrote:
> On 03.08.2021 14:21, Marek Marczykowski-Górecki wrote:
> > If we would have an option (in
> > toolstack, or Xen) to force interrupt remapping, then indeed when it's
> > broken, PCI passthrough should be refused
isiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
On Tue, Jul 27, 2021 at 02:56:01PM +0100, Ian Jackson wrote:
> Marek Marczykowski-Górecki writes ("[PATCH] autoconf: fix handling absolute
> $PYTHON path"):
> > Don't strip full path from $PYTHON variable. This is especially
> > relevant, if it points outsid
On Wed, Jun 02, 2021 at 05:32:06AM +0200, Marek Marczykowski-Górecki wrote:
> Don't strip full path from $PYTHON variable. This is especially
> relevant, if it points outside of $PATH. This is the case
> for RPM build on CentOS 8 (%{python3} macro points at
> /usr/libexec/pla
CI devices are hot-plugged
only when QEMU is already running (not sure why).
> With the stubdom getting unpaused before relabel, do you have to give
> the stubdom some extra flask policy permissions to handle that case?
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signat
ease build a new xen without this stupid disablement or please add an
> override boot command for it.
>
> Please see the attached upgrade manual of Z600 and the errata "spec update"
> by Intel.
> You see that the C2 stepping is not affected by the bugs refered to in the
>
be interested in learning why his patches haven't been taken back
> then.
Mostly it was waiting in limbo on "public: add RING_COPY_RESPONSE()"[1] patch
to the Xen tree, to be then synchronized back to Linux headers. That patch
was finally committed in March this year. I should've followed up o
s) for %: 'bytes' and 'tuple'
>
> It happens to work with python 2.7 and 3.6.
> To support older Py3, format as strings and explicitly encode as ASCII.
>
> Signed-off-by: Olaf Hering
> Reviewed-by: Andrew Cooper
Acked-by: Marek Marczykowski-Górecki
> ---
> tools/python/script
ap name not NUL terminated
>
> To handle both python variants, cast to bytearray().
>
> Signed-off-by: Olaf Hering
> Reviewed-by: Andrew Cooper
Acked-by: Marek Marczykowski-Górecki
> ---
> tools/python/scripts/convert-legacy-stream | 2 +-
> 1 file changed, 1 insertion(+
b"%x" % (size, ),
> +root = bytes(("physmap/%x" % phys).encode('utf-8'))
> +kv = [root + b"/start_addr", bytes(("%x" % start).encode('utf-8')),
> + root + b"/size", bytes(("%x" % size).encode(
absolute path, so make it conditional.
Signed-off-by: Marek Marczykowski-Górecki
---
m4/python_devel.m4 | 6 +-
tools/configure.ac | 1 -
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/m4/python_devel.m4 b/m4/python_devel.m4
index bbf1e0354b2b..676489b8e978 100644
--- a/m4
. It pushes to
the container registry conveniently provided by gitlab too :)
In my case I build trigger it via push to a specific branch, but
connecting to schedule should be trivial too.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
+---
> drivers/tty/hvc/hvc_xen.c | 15 +-
> include/xen/interface/io/ring.h | 278 ++--
> 4 files changed, 369 insertions(+), 226 deletions(-)
>
> --
> 2.26.2
>
>
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
On Tue, May 18, 2021 at 09:48:25AM +, Durrant, Paul wrote:
> > -Original Message-
> > From: Marek Marczykowski-Górecki
> >
> > On Tue, May 18, 2021 at 09:34:45AM +, Durrant, Paul wrote:
> > > > -Original Message-----
>
On Tue, May 18, 2021 at 07:57:16AM +0100, Paul Durrant wrote:
> On 17/05/2021 22:43, Marek Marczykowski-Górecki wrote:
> > On Tue, May 11, 2021 at 12:46:38PM +, Durrant, Paul wrote:
> > > I really can't remember any detail. Perhaps try reverting both patches
&g
On Mon, May 17, 2021 at 10:51:38PM +0100, Michael Brown wrote:
> On 17/05/2021 22:43, Marek Marczykowski-Górecki wrote:
> > In any case, the issue is not calling the hotplug script, responsible
> > for configuring newly created vif interface. Not kernel waiting for it.
> > So,
On Tue, May 11, 2021 at 12:46:38PM +, Durrant, Paul wrote:
> > -Original Message-
> > From: Marek Marczykowski-Górecki
> > Sent: 11 May 2021 11:45
> > To: Durrant, Paul
> > Cc: Michael Brown ; p...@xen.org;
> > xen-devel@lists.xenproject.
On Tue, May 11, 2021 at 12:40:54PM +0200, Marek Marczykowski-Górecki wrote:
> On Tue, May 11, 2021 at 07:06:55AM +, Durrant, Paul wrote:
> > > -Original Message-
> > > From: Marek Marczykowski-Górecki
> > > Sent: 10 May 2021 20:43
> > > To: M
On Tue, May 11, 2021 at 07:06:55AM +, Durrant, Paul wrote:
> > -Original Message-
> > From: Marek Marczykowski-Górecki
> > Sent: 10 May 2021 20:43
> > To: Michael Brown ; p...@xen.org
> > Cc: p...@xen.org; xen-devel@lists.xenproject.org; net...@vger.kerne
ssumes I guessed correctly why it was done in the first place...
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
On Mon, May 10, 2021 at 07:47:01PM +0100, Michael Brown wrote:
> On 10/05/2021 19:32, Marek Marczykowski-Górecki wrote:
> > On Tue, Apr 13, 2021 at 04:25:12PM +0100, Michael Brown wrote:
> > > The logic in connect() is currently written with the assumption that
> >
"hotplug-status");
> + if (err)
> + goto err;
> be->have_hotplug_status_watch = 1;
> + }
>
> netif_tx_wake_all_queues(be->vif->dev);
>
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
esult in NULL
> >>> dereferences.
> >>>
> >>> One reason for failure is e.g. a signal pending for the running
> >>> process.
> >>>
> >>> Fixes: d3eeb1d77c5d0af ("xen/gntdev: use mmu_interval_notifier_insert")
> >>&g
xenstore entries, but is
called always in the toolstack domain (dom0).
libxl__hoplug_disk() is called from libxl__get_hotplug_script_info(),
which may not sound like the most logical place to actually change
some state, but it is called when we need it.
Signed-off-by: Marek Marczykowski-Górecki
Signed-off-by: Marek Marczykowski-Górecki
---
tools/libs/light/libxl_linux.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/libs/light/libxl_linux.c b/tools/libs/light/libxl_linux.c
index 8d62dfd255cb..cc8baf5c3eae 100644
--- a/tools/libs/light/libxl_linux.c
, but is a very
atractive one. Few questions:
1. Is it acceptable approach at all?
2. Is empty 'script' parameter value going to fly? Unfortunately, NULL is
already taken as "use default".
Marek Marczykowski-Górecki (2):
libxl: rename 'error' label to 'out' as it is used for success t
initially here:
https://lore.kernel.org/xen-devel/20180216204031.5...@gmail.com/
Apparently this alone is already enough to get massive speedup.
Signed-off-by: Marek Marczykowski-Górecki
---
hw/i386/pc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/i386/pc.c b/hw/i386
fier_remove().
>
> One reason for failure is e.g. a signal pending for the running
> process.
>
> Fixes: d3eeb1d77c5d0af ("xen/gntdev: use mmu_interval_notifier_insert")
> Cc: sta...@vger.kernel.org
> Reported-by: Marek Marczykowski-Górecki
> Signed-off-by: Ju
49 8b 9c 24 b0 03 00mov0x3b0(%r12),%rbx
812f5965: 00
If my calculation is right, it means map->notifier->mm is NULL.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
rek/350158269b77ebb8492d7c9392db686f
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
because of loop devices
part, but also because of writing xen-blkback specific xenstore entry).
[1] https://xen.markmail.org/thread/ytikjjbs4kpihzi5
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
think it is reasonably safe
to have it included in the release, even at such late time.
> This is not a good set of options.
>
> Of them, I still think I would choose (2). But I would love it if
> someone were to come up with a better suggestion (perhaps a variant on
> one of the above).
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
issue" you meant "Xen using legacy stuff that stops being
supported by the hardware", right? Yes it is an issue. But for most
users of Xen, having it broken more likely will results in "lets switch
to something that works" (perhaps not after the first such case, but
this
e to either Monday.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
ating the same domain with the same config.
>
> Anyone has any idea what might be going on here?
Make sure your kernel has this patch:
https://lore.kernel.org/xen-devel/4c9af052a6e0f6485d1de43f2c38b1461996db99.ca...@infradead.org/
I'm not sure about the 5.8.x, but for 5.10 it is in >= 5.10.13.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
o, I'm cc-ing Trammell, who might be interested too.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
0058660
[ 43.618313] Kernel panic - not syncing: Fatal exception
[ 43.619137] Kernel Offset: disabled
The original report:
https://github.com/QubesOS/qubes-issues/issues/6397#issuecomment-788879968
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
>
> > The information to do that is not saved in libxl__dm_resume_state for
> > non-HVM domains.
> >
> > Fixes: 6298f0eb8f443 ("libxl: Re-introduce libxl__domain_resume")
> > Reported-by: Marek Marczykowski-Górecki
> > Signed-off-by: Juergen Gross
>
> Re
On Wed, Feb 17, 2021 at 07:51:42AM +0100, Jürgen Groß wrote:
> On 17.02.21 06:12, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > I'm observing Linux PV/PVH guest crash when I resume it from sleep. I do
> > this with:
> >
> > virsh -c xen
ote the time besides "register_vcpu_info failed" - it is in the future.
I think the offset depends on the uptime, with shorter uptime I get much
smaller difference (like 49 vs 51).
Any ideas?
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
ristic seems like a bit too much, maybe instead add an explicit
option to skip hvmloader?
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
On Tue, Sep 29, 2020 at 05:27:48PM +0200, Jürgen Groß wrote:
> On 29.09.20 17:16, Marek Marczykowski-Górecki wrote:
> > On Tue, Sep 29, 2020 at 05:07:11PM +0200, Jürgen Groß wrote:
> > > On 29.09.20 16:27, Marek Marczykowski-Górecki wrote:
> > > > On Mon, Mar 23, 2
r 4.14, 4.19, 5.4 and 5.10.
Hmm, I can't find it in LKML archive, nor stable@ archive. And also it
isn't included in 5.10.12 released yesterday, nor included in
queue/5.10 [1]. Are you sure it wasn't lost somewhere in the meantime?
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux
and it's cherry-picked variants
> > on linux-5.4.y and linux-5.10.y.
>
>
> You most likely need 5f46400f7a6a4fad635d5a79e2aa5a04a30ffea1. It hit Linus
> tree a few hours ago.
I can confirm this fixes the same issue for me (too?), thanks!
Shouldn't this patch have Cc: stable?
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
() macro added in 3f20b8def0.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v2:
- action -> type
- drop leading underscores from macro parameters (keep it in
RING_GET_RESPONSE for consistency with RING_GET_REQUEST)
---
xen/include/public/io/ring.h | 19 +++
1 f
() macro added in 3f20b8def0.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/include/public/io/ring.h | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/xen/include/public/io/ring.h b/xen/include/public/io/ring.h
index d68615ae2f67..b63d7362f0e9 100644
--- a/xen
601 - 700 of 1237 matches
Mail list logo
