On 24.06.23 16:07, Julien Grall wrote:
Hi Yann,
Adding Juergen.
On 31/05/2023 11:35, Yann Dirson wrote:
Signed-off-by: Yann Dirson
Reviewed-by: Julien Grall
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Descrip
On 6/26/23 23:19, Olaf Hering wrote:
I need advice on how to debug this.
One thing that stands out is uhci_irq().
It reads a u16 from the USBSTS register.
On the qemu side, this read is served from bmdma_read. Since the read
size is 2, the result is ~0, and uhci_irq() turns the controller off.
On 16.06.23 08:36, Jan Beulich wrote:
First of all move PV-only ELF notes inside the XEN_PV conditional; note
that
- HV_START_LOW is dropped altogether, as it was meaningful for 32-bit PV
only,
- the 32-bit instance of VIRT_BASE is dropped, as it would be dead code
once inside the condition
On 27.06.23 06:44, Hugh Dickins wrote:
On Mon, 26 Jun 2023, Vishal Moola (Oracle) wrote:
The MM subsystem is trying to shrink struct page. This patchset
introduces a memory descriptor for page table tracking - struct ptdesc.
...
39 files changed, 686 insertions(+), 455 deletions(-)
I don'
On 12.06.23 16:25, Christoph Hellwig wrote:
Remove the dangerous late initialization of xen-swiotlb in
pci_xen_swiotlb_init_late and instead just always initialize
xen-swiotlb in the boot code if CONFIG_XEN_PCIDEV_FRONTEND is
enabled and Xen PV PCI is possible.
Signed-off-by: Christoph Hellwig
On 12.06.23 16:25, Christoph Hellwig wrote:
Drivers have no business looking at dma-mapping or swiotlb internals.
Signed-off-by: Christoph Hellwig
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP d
As discussed in Xen Summit, we likely don't want to merge it as is after
all, but rather acknowledge that XAPI has taken the opposite route and
allow the toolstack to give ownership of ~/control (or at least write
permission?) to the guest -- maybe also recommending not to do that.
Would that s
On 25/06/2023 22:49, Julien Grall wrote:
>
>
> From: Julien Grall
>
> The instruction CBNZ can only jump to a pc-relative that is in the
> range +/- 1MB.
>
> Alternative instructions replacement are living in a separate
> subsection of the init section. This is usually placed towards
> the
v2, adjusted per the discussion at XenSummit
https://cirrus-ci.com/build/6611877547999232
https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/912782128
Andrew Cooper (3):
xen/types: Drop #ifdefary for __{SIZE,PTRDIFF}_TYPE__
treewide: Avoid including asm/types.h
xen/types: Rework
We're about to rearrange the common and arch types.h split. While most
users already include , a few do not and some files fail to
compile as a result.
Almost all logic is going to have types very early in the include chain. Drop
the include entirely from C files, and swap to the common types.h
Xen uses the stdint types. Rearrange the types headers to define the
compatibility __{u,s}$N types in terms of the stdint types, not the other way
around.
All all supported compilers on architectures other than x86 support the stdint
__*_TYPE__ macros. Move these into a new xen/stdint.h to avoid
All supported compilers have these types.
No functional change.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Reviewed-by: Alistair Francis
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC:
Hi Julien,
On 26/06/2023 14:56, Julien Grall wrote:
>
>
> Hi,
>
> On 26/06/2023 12:56, Michal Orzel wrote:
>>
>>
>> On 25/06/2023 22:49, Julien Grall wrote:
>>>
>>>
>>> From: Julien Grall
>>>
>>> UBSAN has been enabled a few years ago on x86 but was never
>>> enabled on Arm because the final b
Reviewed-by: Oleksii Kurochko
On Tue, 2023-06-27 at 08:56 +0100, Andrew Cooper wrote:
> All supported compilers have these types.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
> Reviewed-by: Jan Beulich
> Reviewed-by: Alistair Francis
> ---
> CC: Jan Beulich
> CC: Roger Pau Mon
Reviewed-by: Oleksii Kurochko
On Tue, 2023-06-27 at 08:56 +0100, Andrew Cooper wrote:
> Xen uses the stdint types. Rearrange the types headers to define the
> compatibility __{u,s}$N types in terms of the stdint types, not the
> other way
> around.
>
> All all supported compilers on architectur
flight 181607 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181607/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail REGR. vs. 181597
Tests which are fa
From: Petr Tesarik
The value returned by default_swiotlb_limit() should not change, because it
is used to decide whether DMA can be used. To allow allocating memory pools
on the fly, use the maximum possible physical address rather than the
highest address used by the default pool.
For swiotlb_i
From: Petr Tesarik
Add some kernel-doc comments and move the existing documentation of struct
io_tlb_slot to its correct location. The latter was forgotten in commit
942a8186eb445 ("swiotlb: move struct io_tlb_slot to swiotlb.c").
Use the opportunity to give swiotlb_do_find_slots() a more descri
From: Petr Tesarik
Try to allocate a transient memory pool if no suitable slots can be found,
except when allocating from a restricted pool. The transient pool is just
enough big for this one bounce buffer. It is inserted into a per-device
list of transient memory pools, and it is freed again whe
From: Petr Tesarik
SWIOTLB implementation details should not be exposed to the rest of the
kernel. This will allow to make changes to the implementation without
modifying non-swiotlb code.
To avoid breaking existing users, provide helper functions for the few
required fields. Enhance is_swiotlb_
From: Petr Tesarik
Carve out memory pool specific fields from struct io_tlb_mem. The original
struct now contains shared data for the whole allocator, while the new
struct io_tlb_pool contains data that is specific to one memory pool of
(potentially) many.
Allocate both structures together for r
From: Petr Tesarik
Skip searching the software IO TLB if a device has never used it, making
sure these devices are not affected by the introduction of multiple IO TLB
memory pools.
Additional memory barrier is required to ensure that the new value of the
flag is visible to other CPUs after mappi
From: Petr Tesarik
When swiotlb_find_slots() cannot find suitable slots, schedule the
allocation of a new memory pool. It is not possible to allocate the pool
immediately, because this code may run in interrupt context, which is not
suitable for large memory allocations. This means that the memor
From: Petr Tesarik
Note: This patch series depends on fixes from this thread:
https://lore.kernel.org/linux-iommu/cover.1687784289.git.petr.tesarik@huawei.com/T/
Motivation
==
The software IO TLB was designed with these assumptions:
1) It would not be used much. Small systems (lit
Background:
https://design-sessions.xenproject.org/uid/discussion/disc_MEXyUIXV6clI8n1kgzQ9/view
Possible solutions:
Andrew Cooper: use get domain info list instead of querying domains one-by-one
to reduce number of hypercalls, even though Alejandro's patch makes the
get_domainfo lookups O(1).
On Tue, Jun 27, 2023 at 11:54:23AM +0200, Petr Tesarik wrote:
> +/**
> + * is_swiotlb_active() - check if the software IO TLB is initialized
> + * @dev: Device to check, or %NULL for the default IO TLB.
> + */
> bool is_swiotlb_active(struct device *dev)
> {
> - struct io_tlb_mem *mem = d
On 27.06.23 12:21, Edwin Torok wrote:
Background:
https://design-sessions.xenproject.org/uid/discussion/disc_MEXyUIXV6clI8n1kgzQ9/view
Possible solutions:
Andrew Cooper: use get domain info list instead of querying domains one-by-one
to reduce number of hypercalls, even though Alejandro's patc
On 27/06/2023 11:24 am, Greg Kroah-Hartman wrote:
On Tue, Jun 27, 2023 at 11:54:23AM +0200, Petr Tesarik wrote:
+/**
+ * is_swiotlb_active() - check if the software IO TLB is initialized
+ * @dev: Device to check, or %NULL for the default IO TLB.
+ */
bool is_swiotlb_active(struct device
flight 181609 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181609/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd 11 leak-check/basis(11) fail REGR. vs. 180278
test-amd64-amd64-x
On Tue, 27 Jun 2023 11:55:00 +0100
Robin Murphy wrote:
> On 27/06/2023 11:24 am, Greg Kroah-Hartman wrote:
> > On Tue, Jun 27, 2023 at 11:54:23AM +0200, Petr Tesarik wrote:
> >> +/**
> >> + * is_swiotlb_active() - check if the software IO TLB is initialized
> >> + * @dev: Device to check, or %
Am 27. Juni 2023 07:11:33 UTC schrieb Paolo Bonzini :
>On 6/26/23 23:19, Olaf Hering wrote:
>> I need advice on how to debug this.
>>
>> One thing that stands out is uhci_irq().
>> It reads a u16 from the USBSTS register.
>>
>> On the qemu side, this read is served from bmdma_read. Since the r
Oops, originally sent only to Robin. Restoring the recipient list here...
On Tue, 27 Jun 2023 11:55:00 +0100
Robin Murphy wrote:
> On 27/06/2023 11:24 am, Greg Kroah-Hartman wrote:
> > On Tue, Jun 27, 2023 at 11:54:23AM +0200, Petr Tesarik wrote:
> >> +/**
> >> + * is_swiotlb_active() - ch
Mon, 26 Jun 2023 23:19:01 +0200 Olaf Hering :
> So far I was unable to decipher how the pci_set_word calls can
> possibly affect the outcome and the owner of memory_region_ops_read.
It is enough to return from piix_ide_reset right after
pci_set_word(pci_conf + PCI_COMMAND, 0) to trigger the issue
Tue, 27 Jun 2023 10:12:50 + Bernhard Beschow :
> Bits 4..15 represent the BAR address, and pci_set_byte() only clears bits
> 4..7, leaving bits 8..15 unchanged. Perhaps this causes the BAR to be moved
> into the UHCI region? Does changing the call to pci_set_long() fix the
> problem?
Thank
Tue, 27 Jun 2023 10:12:50 + Bernhard Beschow :
> The BAR is a 32 bit register whose default value is 0x0001. I think
> what's supposed to happen here is a pci_set_long() rather than a
> pci_set_byte().
Indeed, the u32 at that address changes from c121 to c101 with the current code.
Ola
xs_daemon_tdb() in xs_lib.c is no longer used at all, so it can be
removed. xs_domain_dev() and xs_write_all() are not used by xenstored,
so they can be moved to tools/libs/store/xs.c.
xs_daemon_rootdir() is used by xenstored only and it only calls
xs_daemon_rundir(), so replace its use cases with
Instead of including the same small C source in multiple binaries from
2 source directories, use a header file with inline functions as a
replacement.
As some of the functions are exported by libxenstore, rename the inline
functions from xs_*() do xenstore_*() and add xs_*() wrappers to
libxenstor
Some more cleanups of Xenstore.
Changes in V2:
- rebase
- one small modification of patch 10
- added patches 11-13
Changes in V3:
- rebase
- modified patch 4
- added patches 10, 11 and 13
Changes in V4:
- patches 1-11 already committed
- modified patch 3
- rebased patch 4 after modifying patch 3
Instead of using #ifdef in xenstored_control.c split out the code of
environment specific functions (daemon or Mini-OS) to dedicated source
files.
Signed-off-by: Juergen Gross
---
V4:
- split lu_destroy() in common and specific parts (Julien Grall)
---
tools/xenstore/Makefile.common | 8
Move the rest of live update related code from xenstored_control.c to
a dedicated new source file.
Signed-off-by: Juergen Gross
---
tools/xenstore/Makefile.common | 2 +-
tools/xenstore/xenstored_control.c | 417 -
tools/xenstore/xenstored_control.h | 8 -
too
Remove the hlist defines/functions and the rcu related functions from
tools/xenstore/list.h, as they are not used.
Signed-off-by: Juergen Gross
Acked-by: Julien Grall
---
tools/xenstore/list.h | 227 --
1 file changed, 227 deletions(-)
diff --git a/tools
On Mon, Jun 26, 2023 at 08:07:46PM +0200, Marek Marczykowski-Górecki wrote:
> On Thu, Jun 08, 2023 at 02:59:13PM +0100, Luca Fancellu wrote:
> > Commit 56a7aaa16bfe introduced a memory leak on the error path for a
> > Py_BuildValue built object that on some newly introduced error path
> > has not t
On 24/6/23 19:41, Philippe Mathieu-Daudé wrote:
Most of the codebase uses 'CPUState *cpu' or 'CPUState *cs'.
While 'cpu_state' is kind of explicit, it makes the code
harder to review. Simply rename as 'cs'.
Acked-by: Richard Henderson
Signed-off-by: Philippe Mathieu-Daudé
---
target/i386/hvf
On 24/6/23 19:41, Philippe Mathieu-Daudé wrote:
We want all accelerators to share the same opaque pointer in
CPUState.
Rename the 'hvf_vcpu_state' structure as 'AccelCPUState'.
Use the generic 'accel' field of CPUState instead of 'hvf'.
Replace g_malloc0() by g_new0() for readability.
Signed-
flight 181612 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181612/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 28eb51dd54217d48869a8f02534243404308482a
baseline version:
ovmf 81cb0371f9db299048525
On 27.06.23 09:35, Yann Dirson wrote:
As discussed in Xen Summit, we likely don't want to merge it as is after
all, but rather acknowledge that XAPI has taken the opposite route and
allow the toolstack to give ownership of ~/control (or at least write
permission?) to the guest -- maybe also recom
flight 181610 libvirt real [real]
flight 181614 libvirt real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/181610/
http://logs.test-lab.xenproject.org/osstest/logs/181614/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-arm64-li
On 24/6/23 19:41, Philippe Mathieu-Daudé wrote:
This series is part of the single binary effort.
All accelerator will share their per-vCPU context in
an opaque 'accel' pointer within the CPUState.
First handle HAX/NVMM/WHPX/HVF. KVM and TCG will follow
as two different (bigger) follow-up series
On Tue, Jun 27, 2023 at 01:30:06PM +0200, Petr Tesařík wrote:
> Xen is the only user of an "is SWIOTLB present" interface. IIUC Xen
> needs bounce buffers for the PCI frontend driver, but if there is no
> other reason to have a SWIOTLB, the system does not set up one at boot.
Please take a look at
On Mon, Jun 26, 2023 at 09:44:08PM -0700, Hugh Dickins wrote:
> On Mon, 26 Jun 2023, Vishal Moola (Oracle) wrote:
>
> > The MM subsystem is trying to shrink struct page. This patchset
> > introduces a memory descriptor for page table tracking - struct ptdesc.
> ...
> > 39 files changed, 686 inser
When building a domain, xc_domain_setmaxmem() is called with target_memkb
(memory in domain config file).
If a config specifies maxmem > memory, any attempts to increase the domain
memory size to its max,
outside of xl mem-set or xl mem-max, which already call xc_domain_setmaxmem()
properly, wil
On Mon, Jun 26, 2023 at 08:14:01PM -0700, Vishal Moola (Oracle) wrote:
> Currently, page table information is stored within struct page. As part
> of simplifying struct page, create struct ptdesc for page table
> information.
>
> Signed-off-by: Vishal Moola (Oracle)
> Acked-by: Mike Rapoport (IBM
On Mon, 19 Jun 2023 11:19:41 +0200
Christoph Hellwig wrote:
> Any comments? I'd really like to finish this off this merge window..
Let me second this request. My dynamic SWIOTLB patch series also has a
dependence on this.
Petr T
Hi Marek,
On 27/06/2023 13:29, Marek Marczykowski-Górecki wrote:
On Mon, Jun 26, 2023 at 08:07:46PM +0200, Marek Marczykowski-Górecki wrote:
On Thu, Jun 08, 2023 at 02:59:13PM +0100, Luca Fancellu wrote:
Commit 56a7aaa16bfe introduced a memory leak on the error path for a
Py_BuildValue built o
When a grant entry is still in use by the remote domain, Linux must put
it on a deferred list. Normally, this list is very short, because
the PV network and block protocols expect the backend to unmap the grant
first. However, Qubes OS's GUI protocol is subject to the constraints
of the X Window
On Tue, 27 Jun 2023 17:48:02 +0200
Christoph Hellwig wrote:
> On Tue, Jun 27, 2023 at 01:30:06PM +0200, Petr Tesařík wrote:
> > Xen is the only user of an "is SWIOTLB present" interface. IIUC Xen
> > needs bounce buffers for the PCI frontend driver, but if there is no
> > other reason to have a S
On Mon, Jun 26, 2023 at 10:47 PM Guenter Roeck wrote:
>
> On Thu, Jun 22, 2023 at 01:57:38PM -0700, Vishal Moola (Oracle) wrote:
> > Part of the conversions to replace pgtable constructor/destructors with
> > ptdesc equivalents.
> >
> > Signed-off-by: Vishal Moola (Oracle)
> > Acked-by: Mike Rapo
On Tue, Jun 27, 2023 at 9:07 AM Peter Xu wrote:
>
> On Mon, Jun 26, 2023 at 08:14:01PM -0700, Vishal Moola (Oracle) wrote:
> > Currently, page table information is stored within struct page. As part
> > of simplifying struct page, create struct ptdesc for page table
> > information.
> >
> > Signed
flight 181615 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181615/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ea7a3015a2404e1358218463dd25df5ae7615352
baseline version:
ovmf 28eb51dd54217d48869a8
flight 181613 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181613/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd 11 leak-check/basis(11) fail REGR. vs. 180278
test-amd64-amd64-x
On 6/27/23 10:42, Vishal Moola wrote:
On Mon, Jun 26, 2023 at 10:47 PM Guenter Roeck wrote:
On Thu, Jun 22, 2023 at 01:57:38PM -0700, Vishal Moola (Oracle) wrote:
Part of the conversions to replace pgtable constructor/destructors with
ptdesc equivalents.
Signed-off-by: Vishal Moola (Oracle)
nd it worked, but let me know if something fails
when its applied on top of those patches (or the rest of the patchset).
No, I did not try to apply this patch on its own. I tried to build yesterday's
pending-fixes branch of linux-next.
A quick check shows that the build fails with next-2023062
s architecture and it worked, but let me know if something fails
> >> when its applied on top of those patches (or the rest of the patchset).
> >
> >
> > No, I did not try to apply this patch on its own. I tried to build
> > yesterday's
> > pending-fixes branc
;s
pending-fixes branch of linux-next.
A quick check shows that the build fails with next-20230627. See log below.
Ah it looks like this one slipped into -next on its own somehow? Stephen, please
drop this patch from -next; it shouldn't be in without the rest of the
patchset which
I intend
flight 181616 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181616/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1a39bdf2c53858ebb39e6de1362203c65c163c63
baseline version:
ovmf ea7a3015a2404e1358218
On Tue, 27 Jun 2023, David Hildenbrand wrote:
> On 27.06.23 06:44, Hugh Dickins wrote:
> > On Mon, 26 Jun 2023, Vishal Moola (Oracle) wrote:
> >
> >> The MM subsystem is trying to shrink struct page. This patchset
> >> introduces a memory descriptor for page table tracking - struct ptdesc.
> > ...
On Tue, 27 Jun 2023, Matthew Wilcox wrote:
> On Mon, Jun 26, 2023 at 09:44:08PM -0700, Hugh Dickins wrote:
> > On Mon, 26 Jun 2023, Vishal Moola (Oracle) wrote:
> >
> > > The MM subsystem is trying to shrink struct page. This patchset
> > > introduces a memory descriptor for page table tracking -
s own. I tried to build yesterday's
pending-fixes branch of linux-next.
A quick check shows that the build fails with next-20230627. See log below.
Ah it looks like this one slipped into -next on its own somehow? Stephen, please
drop this patch from -next; it shouldn't be in without
chset).
No, I did not try to apply this patch on its own. I tried to build
yesterday's
pending-fixes branch of linux-next.
A quick check shows that the build fails with next-20230627. See log
below.
Ah it looks like this one slipped into -next on its own somehow?
Stephen, please
drop
s (or the rest of the patchset).
No, I did not try to apply this patch on its own. I tried to build yesterday's
pending-fixes branch of linux-next.
A quick check shows that the build fails with next-20230627. See log below.
Ah it looks like this one slipped into -next on its own someho
The pull request you sent on Tue, 27 Jun 2023 08:09:06 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-6.5-rc1-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/18eb3b6dff007f2e4ef4f0d8567dfb5cdb6086fc
Thank you!
--
Deet-doot-dot, I
flight 181617 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181617/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd 11 leak-check/basis(11) fail REGR. vs. 180278
test-amd64-amd64-x
Hi Jan
On 2023/6/26 14:00, Jan Beulich wrote:
On 26.06.2023 05:34, Penny Zheng wrote:
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -27,6 +27,7 @@ config X86
select HAS_PDX
select HAS_SCHED_GRANULARITY
select HAS_UBSAN
+ select HAS_VMAP
With this being
Hi Jan
On 2023/6/26 15:01, Jan Beulich wrote:
On 26.06.2023 05:34, Penny Zheng wrote:
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -54,6 +54,9 @@ config HAS_IOPORTS
config HAS_KEXEC
bool
+config HAS_PAGING_MEMPOOL
+ bool
+
config HAS_PDX
bool
--- a/xen/c
24.06.2023 20:41, Philippe Mathieu-Daudé пишет:
> r.bolsha...@yadro.com is bouncing: Update Roman's email address
> using one found somewhere on the Internet; this way he can Ack-by.
>
> (Reorder Taylor's line to keep the section sorted alphabetically).
>
> Signed-off-by: Philippe Mathieu-Daudé
>
75 matches
Mail list logo
