know
yet which IOMMU driver will be used.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/passthrough/iommu.c | 40 ++-
xen/include/xen/iommu.h | 11 +-
2 files changed, 51 insertions(+)
diff --git a/xen/drivers/passthrough/iommu.c
On Mon, Jul 04, 2022 at 08:05:06AM +0200, Jan Beulich wrote:
> On 03.07.2022 14:17, Marek Marczykowski-Górecki wrote:
> > On Thu, Jun 23, 2022 at 11:29:31AM +0200, Jan Beulich wrote:
> >> On 22.06.2022 17:47, Marek Marczykowski-Górecki wrote:
> >>> On Wed, Jun 15,
On Thu, Jun 23, 2022 at 11:29:31AM +0200, Jan Beulich wrote:
> On 22.06.2022 17:47, Marek Marczykowski-Górecki wrote:
> > On Wed, Jun 15, 2022 at 04:25:54PM +0200, Jan Beulich wrote:
> >> On 07.06.2022 16:30, Marek Marczykowski-Górecki wrote:
> >>> +
On Wed, Jun 15, 2022 at 04:25:54PM +0200, Jan Beulich wrote:
> On 07.06.2022 16:30, Marek Marczykowski-Górecki wrote:
> > From: Connor Davis
> > --- /dev/null
> > +++ b/xen/drivers/char/xue.c
> > @@ -0,0 +1,957 @@
> > +/*
> > + * drivers/char/xue.c
> &
s
an awful hack - re-enabling bus mastering behind dom0's backs.
Linux driver does similar thing - see
drivers/usb/early/xhci-dbc.c:xdbc_handle_events().
To avoid Linux messing with the DbC, mark this MMIO area as read-only.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/dri
MAX_SERCONS (4) is arbitrary,
inspired by the number of SERHND_IDX values.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/char/console.c | 58 ++-
1 file changed, 45 insertions(+), 13 deletions(-)
diff --git a/xen/drivers/char/console.c b/xen
Re-use rmrr= parameter handling code to handle common device reserved
memory.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/passthrough/vtd/dmar.c | 201 +-
1 file changed, 119 insertions(+), 82 deletions(-)
diff --git a/xen/drivers/passthrough/vtd
Register common device reserved memory similar to how ivmd= parameter is
handled.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/passthrough/amd/iommu_acpi.c | 16
1 file changed, 16 insertions(+)
diff --git a/xen/drivers/passthrough/amd/iommu_acpi.c
b/xen/drivers
Handle parameters similar to dbgp=ehci.
Implement this by not resettting xhc_cf8 again in xue_init_xhc(), but
using a value found there if non-zero. Additionally, add xue->xhc_num to
select n-th controller.
Signed-off-by: Marek Marczykowski-Górecki
---
docs/misc/xen-command-line.pandoc |
ed-off-by: Connor Davis
Signed-off-by: Marek Marczykowski-Górecki
---
xen/arch/x86/Kconfig | 1 +-
xen/arch/x86/include/asm/fixmap.h | 4 +-
xen/arch/x86/setup.c | 1 +-
xen/drivers/char/Kconfig | 7 +-
xen/drivers/char/Makefile | 1 +-
x
Reset ports, to force host system to re-enumerate devices. Otheriwse it
will require the cable to be re-plugged, or will wait in the
"configuring" state indefinitely.
Trick and code copied from Linux:
drivers/usb/early/xhci-dbc.c:xdbc_start()->xdbc_reset_debug_port()
Signed-
The ehci number was parsed but ignored.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/char/ehci-dbgp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/drivers/char/ehci-dbgp.c b/xen/drivers/char/ehci-dbgp.c
index 16c8ff394d5c..92c588ec0aa3 100644
--- a/xen
rt for Xue USB3 debugger
Marek Marczykowski-Górecki (9):
xue: reset XHCI ports when initializing dbc
xue: add support for selecting specific xhci
ehci-dbgp: fix selecting n-th ehci controller
console: support multiple serial console simultaneously
IOMMU: add common API for device reser
, prevent anything else being placed on those pages by adding
artificial padding.
Using this API for DbC pages requires raising MAX_USER_RMRR_PAGES.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/char/xue.c | 45 ---
xen/drivers/passthrough/vtd/dmar.c
know
yet which IOMMU driver will be used.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/passthrough/iommu.c | 40 ++-
xen/include/xen/iommu.h | 11 +-
2 files changed, 51 insertions(+)
diff --git a/xen/drivers/passthrough/iommu.c
On Mon, Jun 06, 2022 at 12:57:26PM -0400, Tamas K Lengyel wrote:
> On Mon, Jun 6, 2022 at 10:10 AM Tamas K Lengyel
> wrote:
> >
> > On Mon, Jun 6, 2022 at 10:03 AM Marek Marczykowski-Górecki
> > wrote:
> > >
> > > On Mon, Jun 06, 2022
SB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 NHI #0
(rev 01)
00:14.0 USB controller: Intel Corporation Tiger Lake-LP USB 3.2 Gen 2x1 xHCI
Host Controller (rev 20)
So, I need dbgp=xue2 or dbgp=xue@pci00:14.0.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
On Mon, Jun 06, 2022 at 01:18:45PM +, Andrew Cooper wrote:
> On 06/06/2022 04:40, Marek Marczykowski-Górecki wrote:
> > This is integration of https://github.com/connojd/xue into mainline Xen.
> > This patch series includes several patches that I made in the process, some
&
s
an awful hack - re-enabling bus mastering behind dom0's backs.
Linux driver does similar thing - see
drivers/usb/early/xhci-dbc.c:xdbc_handle_events().
To avoid Linux messing with the DbC, mark this MMIO area as read-only.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/dri
Mark config space of the device as read-only, to prevent dom0 (or
others) re-configuring the USB controller while it's used as a debug
console.
This isn't strictly necessary, as the xhci and xhci-dbc drivers can
co-exists, but that's a simpler option.
Signed-off-by: Marek Marcz
know
yet which IOMMU driver will be used.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/passthrough/iommu.c | 40 ++-
xen/include/xen/iommu.h | 11 +-
2 files changed, 51 insertions(+)
diff --git a/xen/drivers/passthrough/iommu.c
From: Connor Davis
Xue is a cross-platform USB 3 debugger that drives the Debug
Capability (DbC) of xHCI-compliant host controllers. This patch
implements the operations needed for xue to initialize the host
controller's DbC and communicate with it. It also implements a struct
uart_driver that us
, prevent anything else being placed on those pages by adding
artificial padding.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/char/xue.c | 46 ---
xen/drivers/passthrough/vtd/dmar.c | 2 +-
2 files changed, 32 insertions(+), 16 deletions(-)
diff
Register common device reserved memory similar to how ivmd= parameter is
handled.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/passthrough/amd/iommu_acpi.c | 16
1 file changed, 16 insertions(+)
diff --git a/xen/drivers/passthrough/amd/iommu_acpi.c
b/xen/drivers
Re-use rmrr= parameter handling code to handle common device reserved
memory.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/passthrough/vtd/dmar.c | 201 +-
1 file changed, 119 insertions(+), 82 deletions(-)
diff --git a/xen/drivers/passthrough/vtd
Tian
Connor Davis (1):
drivers/char: Add support for Xue USB3 debugger
Marek Marczykowski-Górecki (11):
xue: annotate functions with cf_check
xue: reset XHCI ports when initializing dbc
xue: add support for selecting specific xhci
ehci-dbgp: fix selecting n-th ehci controller
console:
MAX_SERCONS (4) is arbitrary,
inspired by the number of SERHND_IDX values.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/char/console.c | 58 ++-
1 file changed, 45 insertions(+), 13 deletions(-)
diff --git a/xen/drivers/char/console.c b/xen
The ehci number was parsed but ignored.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/char/ehci-dbgp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/drivers/char/ehci-dbgp.c b/xen/drivers/char/ehci-dbgp.c
index 16c8ff394d5c..92c588ec0aa3 100644
--- a/xen
Reset ports, to force host system to re-enumerate devices. Otheriwse it
will require the cable to be re-plugged, or will wait in the
"configuring" state indefinitely.
Trick and code copied from Linux:
drivers/usb/early/xhci-dbc.c:xdbc_start()->xdbc_reset_debug_port()
Signed-
Handle parameters similar to dbgp=ehci.
Implement this by not resettting xhc_cf8 again in xue_init_xhc(), but
using a value found there if non-zero. Additionally, add xue->xhc_num to
select n-th controller.
Signed-off-by: Marek Marczykowski-Górecki
---
docs/misc/xen-command-line.pandoc |
Annotate indirectly called functions for IBT.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/char/xue.c | 12 ++--
xen/include/xue.h | 24
2 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/xen/drivers/char/xue.c b/xen/drivers/char
On Fri, May 20, 2022 at 11:47:02AM +0200, Jan Beulich wrote:
> On 20.05.2022 10:53, Marek Marczykowski-Górecki wrote:
> > Intel LPSS has INTERRUPT_LINE set to 0xff by default, that is declared
> > by the PCI Local Bus Specification Revision 3.0 (from 2004) as
> > &qu
On Fri, May 20, 2022 at 11:42:37AM +0200, Jan Beulich wrote:
> On 20.05.2022 10:53, Marek Marczykowski-Górecki wrote:
> > This is purely based on the spec:
> > - Intel 500 Series PCH: 635218-006
> > - Intel 600 Series PCH: 691222-001, 648364-003
> >
> > Th
_X86 anyway.
Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Roger Pau Monné
---
Changes in v6:
- wrap the check in additional CONFIG_X86, with appropriate comment
Changes in v5:
- drop IRQ 0 from the log message
Changes in v4:
- adjust log message, change it from WARNING to INFO
- re-
This is purely based on the spec:
- Intel 500 Series PCH: 635218-006
- Intel 600 Series PCH: 691222-001, 648364-003
This is tested only on TGL-LP added initially, but according to the
spec, they should behave the same.
Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Andrew Cooper
cause unstable ABIs
force rebuilds of several parts in that case. But I guess testing just
Xen with its native toolstack won't have this problem (and you build all
of it in gitlab already).
I'm open for any questions about this setup :)
--
Best Regards,
Marek Marczykowski-Górecki
I
, Jan Beulich wrote:
> >>>> On 11.05.2022 16:30, Marek Marczykowski-Górecki wrote:
> >>>>> --- a/xen/drivers/char/ns16550.c
> >>>>> +++ b/xen/drivers/char/ns16550.c
> >>>>> @@ -1238,6 +1238,13 @@ pci_uart_config(struct ns16550 *ua
ES: CR0: 80050033
CR2: 0050 CR3: e932e002 CR4: 003706e0
Kernel panic - not syncing: Fatal exception
Kernel Offset: disabled
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
_X86 anyway.
Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Roger Pau Monné
---
Changes in v5:
- drop IRQ 0 from the log message
Changes in v4:
- adjust log message, change it from WARNING to INFO
- re-add x86 reference in the commit message
Changes in v3:
- change back to checking 0xff
This is purely based on the spec:
- Intel 500 Series PCH: 635218-006
- Intel 600 Series PCH: 691222-001, 648364-003
This is tested only on TGL-LP added initially, but according to the
spec, they should behave the same.
Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Andrew Cooper
_X86 anyway.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v4:
- adjust log message, change it from WARNING to INFO
- re-add x86 reference in the commit message
Changes in v3:
- change back to checking 0xff explicitly
- adjust commit message, include spec reference
- change warnin
This is purely based on the spec:
- Intel 500 Series PCH: 635218-006
- Intel 600 Series PCH: 691222-001, 648364-003
This is tested only on TGL-LP added initially, but according to the
spec, they should behave the same.
Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Andrew Cooper
Intel LPSS has INTERRUPT_LINE set to 0xff by default, that is declared
by the PCI Local Bus Specification Revision 3.0 (from 2004) as
"unknown"/"no connection". Fallback to poll mode in this case.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v3:
- change b
This is purely based on the spec:
- Intel 500 Series PCH: 635218-006
- Intel 600 Series PCH: 691222-001, 648364-003
This is tested only on TGL-LP added initially, but according to the
spec, they should behave the same.
Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Andrew Cooper
On Tue, May 10, 2022 at 05:46:12PM +0200, Roger Pau Monné wrote:
> On Tue, May 10, 2022 at 02:30:41PM +, Andrew Cooper wrote:
> > On 10/05/2022 12:55, Marek Marczykowski-Górecki wrote:
> > > Intel LPSS has INTERRUPT_LINE set to 0xff by default, that can't
> > &g
This is purely based on the spec:
- Intel 500 Series PCH: 635218-006
- Intel 600 Series PCH: 691222-001, 648364-003
This is tested only on TGL-LP added initially, but according to the
spec, they should behave the same.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v2:
- new patch
_init()). Currently it's
x86-specific, as the surrounding code is guarded with CONFIG_X86 anyway.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v2:
- add log message
- extend commit message
- code style fix
---
xen/drivers/char/ns16550.c | 9 +
1 file changed, 9 insertions(+)
di
o make both versions work at the same time, but TBH
I'm not sure how to do that with C extension.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
On Wed, Apr 06, 2022 at 07:13:18AM +0200, Juergen Gross wrote:
> On 05.04.22 18:24, Marek Marczykowski-Górecki wrote:
> > On Tue, Apr 05, 2022 at 01:03:57PM +0200, Juergen Gross wrote:
> > > Hi Marek,
> > >
> > > On 31.03.22 14:36, Marek Marczykowski-Górecki wr
On Tue, Apr 05, 2022 at 01:03:57PM +0200, Juergen Gross wrote:
> Hi Marek,
>
> On 31.03.22 14:36, Marek Marczykowski-Górecki wrote:
> > On Thu, Mar 31, 2022 at 02:22:03PM +0200, Juergen Gross wrote:
> > > Maybe some kernel config differences, or other udev rules (memory on
On Mon, Apr 04, 2022 at 03:42:09PM +0200, Jan Beulich wrote:
> On 01.04.2022 15:46, Marek Marczykowski-Górecki wrote:
> > On Wed, Mar 30, 2022 at 12:16:00PM +0200, Jan Beulich wrote:
> >> All,
> >>
> >> while 4.14's general support period ended in January
respective
> staging branch and the list above, but which you consider relevant.
I'm not sure if "just" bugfix qualify for 4.14 at this point, but if so,
I'd propose:
0a20a53df158 tools/libs/light: set video_mem for PVH guests
In any case, the above should be backported to 4.15 and 4.16.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
TTR{state}="online"
But I don't think they are conflicting.
> What type of guest are you using? Mine was a PVH guest.
PVH here too.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
On Thu, Mar 31, 2022 at 08:41:19AM +0200, Juergen Gross wrote:
> On 31.03.22 05:51, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > I'm trying to make use of CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y to increase
> > domain memory beyond initial maxmem, but I hit few i
the extra memory still doesn't
seem to be used.
Any ideas?
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
On Mon, Mar 28, 2022 at 04:12:29AM +0200, Marek Marczykowski-Górecki wrote:
> On Mon, Mar 28, 2022 at 12:45:24PM +1100, Damien Miller wrote:
> > On Fri, 25 Mar 2022, Demi Marie Obenour wrote:
> >
> > > Linux’s netfront and blkfront drivers recently had a security
>
gh dom0 (which has no network interfaces at all!). You
can read more about it at the link below (especially look for the
diagram at the end, if you want just a quick look):
https://www.qubes-os.org/doc/architecture/
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
rmally
> fairly trusted) sys-firewall or sys-whonix qubes.
I'm with Roger on this - when security support is external, such
information in xen.git could easily become stale. If anything, there
could be a link to OpenBSD security status info, maintained by whoever
such support provides.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
On Tue, Mar 22, 2022 at 08:12:53AM +0100, Juergen Gross wrote:
> Hi Marek,
>
> On 21.03.22 23:26, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > After updating from 5.14.15 dom0 kernel to 5.16.13 I started getting
> > this on resume from S3:
> >
> &
nges I see e25a8d959992 "x86/Xen: streamline (and fix) PV
CPU enumeration", which was backported to 5.16.11, although that's just
a hunch.
Any ideas? If necessary, I can run bisect to find specific commit, but I
hope the above message gives enough hints.
--
Best Regards,
Marek
uot; means. 1h is enough, 1min is
not.
Another user reported similar issue here:
https://github.com/QubesOS/qubes-issues/issues/7340
That system uses totally different firmware (Lenovo vs Coreboot + EDK2).
While it doesn't completely rule out firmware issue, I'd say it's
un
e would still need to figure how to
> handle that specific Line value. I haven't looked at the docs, will do
> on Monday hopefully.
... having fallback to a poll mode is still better than crashing the
hypervisor or not using such console at all.
--
Best Regards,
Marek Ma
On Fri, Mar 11, 2022 at 10:23:03AM +, Julien Grall wrote:
> Hi Marek,
>
> On 10/03/2022 16:37, Marek Marczykowski-Górecki wrote:
> > On Thu, Mar 10, 2022 at 04:21:50PM +, Julien Grall wrote:
> > > Hi,
> > >
> > > On 10/03/2022 16:12, Roger Pau Mo
022 at 04:23:00PM +0100, Jan Beulich wrote:
> > > > > On 10.03.2022 15:34, Marek Marczykowski-Górecki wrote:
> > > > > > --- a/xen/drivers/char/ns16550.c
> > > > > > +++ b/xen/drivers/char/ns16550.c
> > > > > > @
This adds support for serial console as found in a laptop with TGL-LP
(StarBook MkV). Since the device is on the bus 0, it needs to be enabled
via "com1=...,amt", not just "...,pci".
Device specification is in Intel docs 631119-007 and 631120-001.
Signed-off-by: Marek
Intel LPSS has INTERRUPT_LINE set to 0xff by default, that can't
possibly work. While a proper IRQ configuration may be useful,
validating value retrieved from the hardware is still necessary. If it
fails, use the device in poll mode.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/dr
ificant target for Qubes OS).
> But I don't think I see the full picture here yet, unless your
> mentioning of TXT was actually implying that TXT was active at the
> point of the crash (which I don't think was said anywhere).
No, TXT wasn't (intentionally) active. I think Andrew mentioned it as
explanation why VMX behaves this way: to let the OS do something _if_ TXT
is active (the check for TXT is the OS responsibility here). But that's
my guess only...
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
sta...@vger.kernel.org
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v2:
- use xennet_uninit, as suggested by Jakub Kicinski
---
drivers/net/xen-netfront.c | 39 ++
1 file changed, 23 insertions(+), 16 deletions(-)
diff --git a/drivers/net/xen-ne
On Tue, Feb 22, 2022 at 12:03:01PM -0800, Jakub Kicinski wrote:
> On Mon, 21 Feb 2022 07:27:32 +0100 Juergen Gross wrote:
> > On 20.02.22 14:42, Marek Marczykowski-Górecki wrote:
> > > xennet_destroy_queues() relies on info->netdev->real_num_tx_queues to
&g
mebody will need to do this. If it's not done right away, someone
> (else) will hit a build issue on a perhaps just slightly older platform.
That's why declare what version _should_ work (and test that via CI),
instead of trying to find what is the minimum version that is actually
; By "find the actual minimum version", do you mean to get to know the version
> number, or install that version on developer's machine?
I think it's something else (closer to the second one): finding what
version is required for features actually used in the code.
On Tue, Feb 22, 2022 at 09:31:31AM +0100, Roger Pau Monné wrote:
> On Tue, Feb 22, 2022 at 01:18:17AM +0100, Marek Marczykowski-Górecki wrote:
> > This reverts commit 2afeec08ab5c86ae21952151f726bfe184f6b23d.
> >
> > The reasoning in the commit was wrong - the code expected t
to skip the call is wrong
and leads to not configured interface.
More discussion at
https://lore.kernel.org/xen-devel/afedd7cb-a291-e773-8b0d-4db9b291f...@ipxe.org/T/#u
Cc: sta...@vger.kernel.org
Signed-off-by: Marek Marczykowski-Górecki
---
Cc: Michael Brown
Changes in v2:
- build fix, rep
afedd7cb-a291-e773-8b0d-4db9b291f...@ipxe.org/T/#u
Cc: sta...@vger.kernel.org
Signed-off-by: Marek Marczykowski-Górecki
---
I believe this is the same issue as discussed at
https://lore.kernel.org/xen-devel/20220113111946.ga4133...@dingwall.me.uk/
Cc: James Dingwall
---
drivers/net/xen-net
stroy_queues()?
Tried that and no issues spotted.
> In case your test with the added ASSERT_RTNL() doesn't show any
> problem you can add my:
>
> Reviewed-by: Juergen Gross
Thanks.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
afedd7cb-a291-e773-8b0d-4db9b291f...@ipxe.org/T/#u
Cc: sta...@vger.kernel.org
Signed-off-by: Marek Marczykowski-Górecki
---
I believe this is the same issue as discussed at
https://lore.kernel.org/xen-devel/20220113111946.ga4133...@dingwall.me.uk/
Cc: James Dingwall
---
drivers/net/xen-net
to skip the call is wrong
and leads to not configured interface.
More discussion at
https://lore.kernel.org/xen-devel/afedd7cb-a291-e773-8b0d-4db9b291f...@ipxe.org/T/#u
Cc: sta...@vger.kernel.org
Signed-off-by: Marek Marczykowski-Górecki
---
Cc: Michael Brown
---
drivers/net/xen-netback/xen
t;)
Cc: sta...@vger.kernel.org # 5.16+
Signed-off-by: Marek Marczykowski-Górecki
---
While this fixes the issue, I'm not sure if that is the correct thing
to do. xennet_remove() calls xennet_destroy_queues() under rtnl_lock,
which may be important here? Just moving xennet_destroy_queues() before
t; CC: w...@xen.org
> CC: Anthony PERARD
> CC: Juergen Gross
> CC: jul...@xen.org
> ---
> tools/xenstore/xenstored_domain.c | 15 ++-
Isn't the same necessary in oxenstored too? Otherwise, I think it needs
some explicit documentation, that late PV with dom0less r
it doesn't change
> behaviors.
>
> Signed-off-by: Luca Miccio
> Signed-off-by: Stefano Stabellini
I realize there is not much sense in making the parameter usable in the
Python API, since it's only useful for xenstored. So, for the Python part:
Acked-by: Marek Marczy
te, or should I go with a
> file based approach (and if yes, 9pfs or pvcalls based)?
Personally, I'd go with memory, as IMHO it the cleanest design from
disaggregation point of view (what was in stubomain, remains in
stubdomain, no extra external interface necessary).
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
-f 1 -d :|xargs printf
'%x\n' > all-addrs
join -v 2 <(sort valid-addrs) <(sort all-addrs) | awk '{ printf "%x\n",
0x'$offset' + strtonum("0x" $1)}' | addr2line -e xen-syms
Currently it finds just one match:
xen/arch/x86/alternative.c:145
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
('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 ref
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
sign
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
> > > hy
hich 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
Subject: [PATCH] WIP: xen/balloon: 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 popu
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
3 too. Anyway, I don't think 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 t
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
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
avid Hildenbrand
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 Marczykows
601 - 700 of 1326 matches
Mail list logo
