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
, 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
/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: support multiple serial consol
of 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
-
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
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
Invisible Things Lab
sig
:31PM +0200, 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
> > > po
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
()). 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(+)
diff --git
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
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,
ranch 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
tate}="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 issues
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
>
(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
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 Marc
ough, 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
unlikely in this case.
--
Best Rega
ill 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 Marczykowski-Góre
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
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/drivers
icture 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
ta...@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-netfron
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
y 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
required. This
; 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.
--
Best R
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
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, reported by kernel test
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-netback/xenbus.c | 12
1 file changed, 4
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
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-netback/xenbus.c | 12
1 file changed, 4
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/xenbus.c | 2 +-
1 file
c: 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
unregister
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 requir
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 Marczykowski-Gór
r 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
ll-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 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
501 - 600 of 1198 matches
Mail list logo
