On 07.12.2021 20:11, Julien Grall wrote:
>
>
> On 07/12/2021 08:37, Michal Orzel wrote:
>> Hi Julien,
>
> Hi,
>
>> On 06.12.2021 16:29, Julien Grall wrote:
>>> Hi,
>>>
>>> On 06/12/2021 14:20, Michal Orzel wrote:
to hypervisor when switching to AArch32 state.
>> I will change to "from
As was briefly discussed on the December Community Call, I'd like to
propose to widen Anthony's maintainership to all of tools/. This then
means that the special LIBXENLIGHT entry can go away.
Signed-off-by: Jan Beulich
---
Note that we're still looking for a 2nd maintainer there, considering
tha
flight 167222 linux-linus real [real]
flight 167227 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167222/
http://logs.test-lab.xenproject.org/osstest/logs/167227/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
flight 167221 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167221/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 167121
test-amd64-amd64-qemuu-nested-amd 2
Hi,
I have posted my query in xen-users mailing list one week ago. I was not
able to get any response from the community. Could you please look into it
and help me out here? I am trying to install xen(from source code), on
LInux from Scratch build system. I just want to know the list of xorg
packa
flight 167224 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167224/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
Hi Bertrand,
On Fri, 26 Nov 2021 at 03:32, Bertrand Marquis wrote:
>
> Hi Mathieu,
>
> > On 25 Nov 2021, at 22:59, Mathieu Poirier
> > wrote:
> >
> > Good day,
> >
> > I am in the process of adding support for aarch64 to the xen-sys
> > crate[1]. The crate currently supports x86_64 and include
On Thu, 25 Nov 2021, Oleksandr wrote:
> > > Please note the following:
> > > for V3 arch_xen_unpopulated_init() was moved to init() as was agreed
> > > and gained __init specifier. So the target_resource is initialized there.
> > >
> > > With current patch series applied if CONFIG_XEN_UNPOPULATED_
Cedric,
On Tue, Dec 07 2021 at 18:42, Cédric Le Goater wrote:
>
> This is breaking nvme on pseries but it's probably one of the previous
> patches. I haven't figured out what's wrong yet. Here is the oops FYI.
Hrm.
> [ 32.494562] WARNING: CPU: 26 PID: 658 at kernel/irq/chip.c:210
> irq_startu
On Mon, Dec 06, 2021 at 11:51:33PM +0100, Thomas Gleixner wrote:
> Replace the about to vanish iterators and make use of the filtering. Take
> the descriptor lock around the iterators.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/controller/pci-hyperv.c | 1
On Mon, Dec 06, 2021 at 11:51:18PM +0100, Thomas Gleixner wrote:
> Use the new iterator functions which pave the way for dynamically extending
> MSI-X vectors.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/msi/irqdomain.c |4 ++--
> drivers/pci/msi/legacy.
On Mon, Dec 06, 2021 at 11:51:16PM +0100, Thomas Gleixner wrote:
> Set the domain info flag which tells the core code to free the MSI
> descriptors from msi_domain_free_irqs() and add an explicit call to the
> core function into the legacy code.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Bjorn
On Mon, Dec 06, 2021 at 11:51:15PM +0100, Thomas Gleixner wrote:
> Simplify the allocation of MSI descriptors by using msi_add_msi_desc()
> which moves the storage handling to core code and prepares for dynamic
> extension of the MSI-X vector space.
>
> Signed-off-by: Thomas Gleixner
Acked-by: B
On Mon, Dec 06, 2021 at 11:27:47PM +0100, Thomas Gleixner wrote:
> msi.c is getting larger and really could do with a splitup. Move it into
> it's own directory to prepare for that.
s/it's/its/
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by
On Mon, Dec 06, 2021 at 11:27:49PM +0100, Thomas Gleixner wrote:
> These functions are required even when CONFIG_PCI_MSI is not set. Move them
> to their own file.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> dr
On Mon, Dec 06, 2021 at 11:51:13PM +0100, Thomas Gleixner wrote:
> To prepare for dynamic extension of MSI-X vectors, protect the MSI
> operations for MSI and MSI-X. This requires to move the invocation of
> irq_create_affinity_masks() out of the descriptor lock section to avoid
> reverse lock orde
On Mon, Dec 06, 2021 at 11:27:59PM +0100, Thomas Gleixner wrote:
> Get rid of yet another irqdomain callback and let the core code return the
> already available information of how many descriptors could be allocated.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: J
On Mon, Dec 06, 2021 at 11:39:41PM +0100, Thomas Gleixner wrote:
> Use msi_get_vector() and handle the return value to be compatible.
>
> No functional change intended.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Bjorn Helgaas
> ---
> V2: Handle the INTx case directly instead of trying to be
On Mon, Dec 06, 2021 at 11:39:36PM +0100, Thomas Gleixner wrote:
> Provide a domain info flag which makes the core code check for a contiguous
> MSI-X index on allocation. That's simpler than checking it at some other
> domain callback in architecture code.
>
> Signed-off-by: Thomas Gleixner
> Re
On Mon, Dec 06, 2021 at 11:39:26PM +0100, Thomas Gleixner wrote:
> Store the properties which are interesting for various places so the MSI
> descriptor fiddling can be removed.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Bjorn Helgaas
> ---
> V2: Use the setter function
> ---
> drivers/pci/
On Mon, Dec 06, 2021 at 11:39:23PM +0100, Thomas Gleixner wrote:
> The usage of msi_desc::pci::entry_nr is confusing at best. It's the index
> into the MSI[X] descriptor table.
>
> Use msi_desc::msi_index which is shared between all MSI incarnations
> instead of having a PCI specific storage for n
On Mon, Dec 06, 2021 at 11:39:09PM +0100, Thomas Gleixner wrote:
> Set the domain info flag which makes the core code handle sysfs groups and
> put an explicit invocation into the legacy code.
>
> Signed-off-by: Thomas Gleixner
> Reviewed-by: Greg Kroah-Hartman
> Reviewed-by: Jason Gunthorpe
A
On Mon, Dec 06, 2021 at 11:39:00PM +0100, Thomas Gleixner wrote:
> Allocate MSI device data on first use, i.e. when a PCI driver invokes one
> of the PCI/MSI enablement functions.
>
> Signed-off-by: Thomas Gleixner
> Reviewed-by: Greg Kroah-Hartman
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjor
On Mon, Dec 06, 2021 at 11:28:00PM +0100, Thomas Gleixner wrote:
> The irqdomain code already returns the information. Move the loop to the
> legacy code.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> drivers/pci
On Mon, Dec 06, 2021 at 11:27:57PM +0100, Thomas Gleixner wrote:
> No users outside of that file.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/msi/irqdomain.c |5 +++--
> include/linux/msi.h
On Mon, Dec 06, 2021 at 11:27:56PM +0100, Thomas Gleixner wrote:
> It's only required for PCI/MSI. So no point in having it in every struct
> device.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Bjorn Helgaas
> ---
> V2: New patch
> ---
> drivers/base/core.c|1 -
> drivers/pci/msi/msi
On Mon, Dec 06, 2021 at 11:27:54PM +0100, Thomas Gleixner wrote:
> Unmapping the MSIX base mapping in the loops which allocate/free MSI
> desciptors is daft and in the way of allowing runtime expansion of MSI-X
> descriptors.
s/MSIX/MSI-X/ (subject and first use in commit log)
s/desciptors/descrip
On Mon, Dec 06, 2021 at 11:27:52PM +0100, Thomas Gleixner wrote:
> Move the irqdomain specific code into it's own file.
s/it's/its/
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/msi/Makefile|1
On Mon, Dec 06, 2021 at 11:27:51PM +0100, Thomas Gleixner wrote:
> Split out the non irqdomain code into its own file.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> V2: Add proper includes and fix variable name -
On Mon, Dec 06, 2021 at 11:27:46PM +0100, Thomas Gleixner wrote:
> No need to walk the descriptors and check for each one whether the entries
> pointer function argument is NULL. Do it once.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by:
On Mon, Dec 06, 2021 at 11:27:44PM +0100, Thomas Gleixner wrote:
> Get rid of the pile of unneeded includes which accumulated over time.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
Nice, thanks!
> ---
> V2: Address bui
On Mon, Dec 06, 2021 at 11:27:42PM +0100, Thomas Gleixner wrote:
> Make arch_restore_msi_irqs() return a boolean which indicates whether the
> core code should restore the MSI message or not. Get rid of the indirection
> in x86.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Rev
On Mon, Dec 06, 2021 at 11:27:36PM +0100, Thomas Gleixner wrote:
> instead of fiddling with msi descriptors.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
s/msi/MSI/ above if you have a chance. Nice cleanup, thanks!
> -
On Mon, Dec 06, 2021 at 11:27:34PM +0100, Thomas Gleixner wrote:
> Last user is gone long ago.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/msi.c |8
> include/linux/msi.h |5 -
On Mon, Dec 06, 2021 at 11:27:33PM +0100, Thomas Gleixner wrote:
> There is no point to have this function public as it is set by the PCI core
> anyway when a PCI/MSI irqdomain is created.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bj
On Mon, Dec 06, 2021 at 11:27:26PM +0100, Thomas Gleixner wrote:
> pci_irq_vector() and pci_irq_get_affinity() use the list position to find the
> MSI-X descriptor at a given index. That's correct for the normal case where
> the entry number is the same as the list position.
>
> But it's wrong for
Cedric,
On Tue, Dec 07 2021 at 16:50, Cédric Le Goater wrote:
> On 12/7/21 12:36, Michael Ellerman wrote:
>>
>> This patch should drop those selects I guess. Can you send an
>> incremental diff for Thomas to squash in?
>
> Sure.
>
>> Removing all the tendrils in various device tree files will pro
flight 167218 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167218/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 166959
test-amd64-amd64-xl-qemuu-win7-a
Hi Bertrand and Luca,
On 07/12/2021 11:09, Bertrand Marquis wrote:
On 7 Dec 2021, at 10:52, Luca Fancellu wrote:
On 6 Dec 2021, at 17:05, Julien Grall wrote:
Hi Luca,
On 06/12/2021 15:37, Luca Fancellu wrote:
Currently the maximum number of memory banks is fixed to
128, but on some new
Hi Jan,
On 07/12/2021 09:55, Jan Beulich wrote:
--- a/xen/arch/arm/arm64/entry.S
+++ b/xen/arch/arm/arm64/entry.S
@@ -109,8 +109,16 @@
* If 0, we rely on the on x0/x1 to have been saved at the correct
* position on the stack before.
*/
- .macro entry, hyp, compat, save_x0_x1=
On 07/12/2021 08:37, Michal Orzel wrote:
Hi Julien,
Hi,
On 06.12.2021 16:29, Julien Grall wrote:
Hi,
On 06/12/2021 14:20, Michal Orzel wrote:
to hypervisor when switching to AArch32 state.
I will change to "from AArch32 state".
According to section D1.20.2 of Arm Arm(DDI 0487A.j):
"I
Hi,
On 07/12/2021 07:10, Michal Orzel wrote:
On 06.12.2021 17:40, Julien Grall wrote:
On 06/12/2021 15:00, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 06.12.2021 15:39, Julien Grall wrote:
Hi Michal,
On 06/12/2021 14:19, Michal Orzel wrote:
vtimer_update_irqs, vtimer_update_irq and v
Thomas,
On 12/6/21 23:39, Thomas Gleixner wrote:
Replace open coded MSI descriptor chasing and use the proper accessor
functions instead.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
---
drivers/pci/msi/msi.c | 26 ++
flight 167217 xen-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167217/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 166387
Tests which did not suc
On 12/7/21 12:36, Michael Ellerman wrote:
Cédric Le Goater writes:
Hello Thomas,
On 12/6/21 23:27, Thomas Gleixner wrote:
This code is broken since day one. ppc4xx_setup_msi_irqs() has the
following gems:
1) The handling of the result of msi_bitmap_alloc_hwirqs() is completely
broke
hi Stefano, Julien,
On 11/10/21 11:12 пп, Stefano Stabellini wrote:
On Mon, 8 Nov 2021, Julien Grall wrote:
[..]
A few years ago, I attempted to disable the swiotlb when Xen configured the
IOMMU for the device (see [1]). Did you have a chance to go through the
thread? In particular, I think Ia
On 03.12.2021 14:34, Andrew Cooper wrote:
> Hello,
>
> Following the __ro_after_init work, I tried to complete a few pieces of
> cleanup that I'd accrued, and everything has unravelled.
>
> On x86, the __2M_* symbols haven't really been 2M aligned since their
> introduction, and the utter mess th
On 02/12/2021 20:24, Ashley Weltz wrote:
Hi everyone,
Hi Ahsley,
Our next meeting is on Tuesday, December 7th at 1500 UTC.
The calendar invitation is for 4PM UTC. Can you clarify which time is it?
Cheers,
--
Julien Grall
On 06.12.21 18:02, Anthony PERARD wrote:
Also change stubdom to depends on Makefile.common.
Signed-off-by: Anthony PERARD
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
On 06.12.21 18:02, Anthony PERARD wrote:
This new "Makefile.common" is intended to be used by both tools/ and
stubdom/ build system without stubdom needed to use tools/ build
system.
It should contain the necessary list of objects and CFLAGS needed to
build a static library.
Change stubdom/ to
On 06.12.2021 14:30, Jan Beulich wrote:
> From: Lasse Collin
>
> It's good style. I was also told that GCC 7 is more strict and might
> give a warning when such comments are missing.
>
> Suggested-by: Andrei Borzenkov
> Signed-off-by: Lasse Collin
> Signed-off-by: Jiri Kosina
> [Linux commit:
On 06.12.21 18:02, Anthony PERARD wrote:
With "xentoolcore_internal.h" been in LIBHEADER, it was installed. But
its dependency "_xentoolcore_list.h" wasn't installed so the header
couldn't be used anyway.
This patch also mean that the rule "headers.chk" doesn't check it
anymore as well.
Signed-
On 06.12.21 18:02, Anthony PERARD wrote:
For PERL_FLAGS, use make's shell rather than a backquote.
Rather than relying on the VCS to create an empty directory for us,
we can create one before generating the *.c file for the bindings.
Make use of generic variable names to build a shared library
On 06.12.21 18:02, Anthony PERARD wrote:
Fix the dependency on the library, $(SHLIB) variable doesn't exist
anymore.
Rework dependency on the include file, we can let `swig` generate the
dependency for us with the use of "-M*" flags.
The xenstat.h file has moved so we need to fix the include lo
On 07.12.2021 11:53, Andrew Cooper wrote:
> cpu0_stack is contained within .data, which means the memcpy() already takes a
> snapshot at the start of the critical region.
>
> Later, when we switch to the relocated Xen, we do end up losing updates to the
> local variables,
You word this as if that
On 07.12.2021 13:00, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH 1/7] xz: add fall-through comments to a
> switch statement"):
>> I'm unwilling only as long as I don't understand the need for them. As
>> indicated, while I appreciate your "make verification easier for
>> reviewers", I ass
On 06.12.21 18:02, Anthony PERARD wrote:
Signed-off-by: Anthony PERARD
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
On 06.12.21 18:02, Anthony PERARD wrote:
Remove '-Werror -Wmissing-progress -I./include $(CFLAGS_xeninclude)',
those flags are already added via "libs.mk".
Flag "-I." isn't needed, we just need to fix the #include of
"xg_core.h" as this header isn't expected to be installed.
Make use of "-iquot
The difference between ->handle_output() and ->handle_aio_output() was
that ->handle_aio_output() returned a bool return value indicating
progress. This was needed by the old polling API but now that the bool
return value is gone, the two functions can be unified.
Signed-off-by: Stefan Hajnoczi
-
Now that virtio-blk and virtio-scsi are ready, get rid of
the handle_aio_output() callback. It's no longer needed.
Signed-off-by: Stefan Hajnoczi
---
include/hw/virtio/virtio.h | 4 +--
hw/block/dataplane/virtio-blk.c | 16 ++
hw/scsi/virtio-scsi-dataplane.c | 54 --
On 06.12.21 18:02, Anthony PERARD wrote:
It seems a better name. Latter, we will introduce LIBX86_OBJS to
s/Latter/Later/
collect lib/x86/* objects.
Signed-off-by: Anthony PERARD
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenP
Prepare virtio_scsi_handle_cmd() to be used by both dataplane and
non-dataplane by making the condition for starting ioeventfd more
specific. This way it won't trigger when dataplane has already been
started.
Signed-off-by: Stefan Hajnoczi
---
hw/scsi/virtio-scsi.c | 2 +-
1 file changed, 1 inse
Adaptive polling measures the execution time of the polling check plus
handlers called when a polled event becomes ready. Handlers can take a
significant amount of time, making it look like polling was running for
a long time when in fact the event handler was running for a long time.
For example,
The return value of virtio_blk_handle_vq() is no longer used. Get rid of
it. This is a step towards unifying the dataplane and non-dataplane
virtqueue handler functions.
Prepare virtio_blk_handle_output() to be used by both dataplane and
non-dataplane by making the condition for starting ioeventfd
The virtqueue host notifier API
virtio_queue_aio_set_host_notifier_handler() polls the virtqueue for new
buffers. AioContext previously required a bool progress return value
indicating whether an event was handled or not. This is no longer
necessary because the AioContext polling API has been split
On 06.12.21 18:02, Anthony PERARD wrote:
The only thing done thing done with $(SRCS-y) is to replace ".c" by
".o". It is more useful to collect which object we want to build as
make will figure out how to build it and from which source file.
Signed-off-by: Anthony PERARD
Reviewed-by: Juergen
v3:
- Fixed FUSE export aio_set_fd_handler() call that I missed and double-checked
for any other missing call sites using Coccinelle [Rich]
v2:
- Cleaned up unused return values in nvme and virtio-blk [Stefano]
- Documented try_poll_mode() ready_list argument [Stefano]
- Unified virtio-blk/scsi d
On 06.12.21 18:02, Anthony PERARD wrote:
There is no need for an extra "cleanlocal" target, we can use
double-colon rules instead.
Generated headers are now in tools/include/, so remove those file
there.
Remove -f flag as it's already in $(RM).
libs.mk:
- don't try to remove "*.rpm" anymore
On 06.12.21 18:02, Anthony PERARD wrote:
There is no need for an extra "installlocal" target, we can use
double-colon rules instead.
Doesn't that mean that with the ultimate goal of including all
Makefiles of the tree that all "install" and "uninstall" rules in the
tree will have to be double-c
On Tue, Dec 07 2021 at 13:47, Thomas Gleixner wrote:
> On Tue, Dec 07 2021 at 10:04, Cédric Le Goater wrote:
>>> +/**
>>> + * msi_device_set_properties - Set device specific MSI properties
>>> + * @dev: Pointer to the device which is queried
>>> + * @prop: Properties to set
>>> + */
>>> +void ms
On Tue, Dec 07 2021 at 10:04, Cédric Le Goater wrote:
>> +/**
>> + * msi_device_set_properties - Set device specific MSI properties
>> + * @dev:Pointer to the device which is queried
>> + * @prop: Properties to set
>> + */
>> +void msi_device_set_properties(struct device *dev, unsigned long p
On Tue, Dec 07 2021 at 09:21, Greg Kroah-Hartman wrote:
> On Mon, Dec 06, 2021 at 11:51:49PM +0100, Thomas Gleixner wrote:
>> #include
>> #include
>> #include
>>
> Ah, to be young and idealistic and hope that kernel developers read
> comments in header files :)
Hope dies last.
> You might
On 06.12.21 18:02, Anthony PERARD wrote:
LDLIBS is more appropriate and intended to be used to add library
dependencies. APPEND_LDFLAGS wasn't intended to be changed by the
build system.
Signed-off-by: Anthony PERARD
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Descr
On 06.12.21 18:02, Anthony PERARD wrote:
"libs" is odd and has been introduced without a reason by c7d3afbb44.
Instead, only use "all".
Also remove "build" target as "all" is more appropriate and nothing is
using "build" in libs/ in the xen.git repo.
Signed-off-by: Anthony PERARD
Reviewed-by
On 07.12.2021 11:53, Andrew Cooper wrote:
> @@ -1243,7 +1196,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> * data until after we have switched to the relocated pagetables!
> */
> barrier();
> -move_memory(e, XEN_IMG_OFFSET, _end -
Jan Beulich writes ("Re: [PATCH 1/7] xz: add fall-through comments to a switch
statement"):
> I'm unwilling only as long as I don't understand the need for them. As
> indicated, while I appreciate your "make verification easier for
> reviewers", I assign that at least no higher priority than my de
Hi, Julien!
On 03.12.21 18:10, Durrant, Paul wrote:
> On 23/11/2021 23:59, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> vPCI may map and unmap PCI device memory (BARs) being passed through which
>> may take a lot of time. For this those operations may be deferred to be
>>
On Tue, Dec 07, 2021 at 11:23:26AM +0100, Jan Beulich wrote:
> On 25.11.2021 14:39, Anthony PERARD wrote:
> > clang 6.0 and newer behave like gcc in regards for the FILE symbol, so
> > only the filename rather than the full path to the source file.
> >
> > clang 3.8.1-24 (in our debian:stretch con
On 07.12.2021 11:53, Andrew Cooper wrote:
> This check has existed in one form or another since c/s 369bafdb1c1 "xen: Big
> changes to x86 start-of-day" in 2007. Even then, AFAICT, it wasn't necessary
> because there was a clean split between the statically created entries (L3 and
> higher) and th
Cédric Le Goater writes:
> Hello Thomas,
>
> On 12/6/21 23:27, Thomas Gleixner wrote:
>> This code is broken since day one. ppc4xx_setup_msi_irqs() has the
>> following gems:
>>
>> 1) The handling of the result of msi_bitmap_alloc_hwirqs() is completely
>> broken:
>>
>> When the
On 07.12.2021 12:04, Anthony PERARD wrote:
> On Thu, Dec 02, 2021 at 03:06:54PM +0100, Jan Beulich wrote:
>> On 25.11.2021 14:39, Anthony PERARD wrote:
>>> +export XEN_BUILD_EFI XEN_BUILD_PE MKRELOC
>>> +export EFI_LDFLAGS
>>> +endif
>>
>> Exporting MKRELOC in particular isn't very nice. I wonder w
On Mon, Dec 06, 2021 at 05:52:51PM +0100, Jan Beulich wrote:
> On 25.11.2021 14:39, Anthony PERARD wrote:
>
> Nit: In the title, do you mean "set ALL_OBJS in main Makefile; ..."?
>
> > --- a/xen/Makefile
> > +++ b/xen/Makefile
> > @@ -285,8 +285,21 @@ CFLAGS += -flto
> > LDFLAGS-$(CONFIG_CC_IS_C
On 06.12.21 18:02, Anthony PERARD wrote:
Regroup *FLAGS together, use $(LDLIBS).
Remove $(LDLIBS_xenstored) which was the wrong name name as it doesn't
decribe how to link to a potential libxenstored.so, instead add the
value to $(LDLIBS) of xenstored.
Add SYSTEMD_LIBS into $(LDLIBS) instead of
On 25.11.2021 14:39, Anthony PERARD wrote:
> We are going to start building kconfig with HOSTCFLAGS from Config.mk,
> it has the flag "-Wdeclaration-after-statement".
>
> Signed-off-by: Anthony PERARD
Reviewed-by: Jan Beulich
flight 167216 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167216/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 166348
test-amd64-amd64-xl-qemut-win7-a
On 25.11.2021 14:39, Anthony PERARD wrote:
> A subdirectory is now built by setting "$(obj)" instead of changing
> directory. "$(obj)" should always be set when using "Rules.mk" and
> thus a shortcut "$(build)" is introduced and should be used.
>
> A new variable "$(need-builtin)" is introduce. It
Hi,
> On 7 Dec 2021, at 10:52, Luca Fancellu wrote:
>
>
>
>> On 6 Dec 2021, at 17:05, Julien Grall wrote:
>>
>> Hi Luca,
>>
>> On 06/12/2021 15:37, Luca Fancellu wrote:
>>> Currently the maximum number of memory banks is fixed to
>>> 128, but on some new platforms that have a large amount
>
On Thu, Dec 02, 2021 at 03:06:54PM +0100, Jan Beulich wrote:
> On 25.11.2021 14:39, Anthony PERARD wrote:
> > +efi-check-o := arch/x86/efi/check.o
>
> How about making this
>
> efi-check := arch/x86/efi/check
>
> That way you wouldn't need to replace the extension in a number of places,
> but si
On 06.12.21 18:02, Anthony PERARD wrote:
And replace the one defined in libs.mk.
Signed-off-by: Anthony PERARD
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
cpu0_stack is contained within .data, which means the memcpy() already takes a
snapshot at the start of the critical region.
Later, when we switch to the relocated Xen, we do end up losing updates to the
local variables, but that's fine because the only variables we've modified go
out of scope aft
More cleanup, following on from the __ro_after_init work.
Andrew Cooper (3):
x86/boot: Drop pte_update_limit from physical relocation logic
x86/boot: Drop move_memory() and use memcpy() directly
x86/boot: Don't double-copy the stack during physical relocation
xen/arch/x86/setup.c | 105 +++
The way move_memory() sets up the virtual mappings means that there are always
two non-overlapping regions. The virtual layout means that memmove()'s
forward/backwards check doesn't do what the caller intends, as the check ought
to be performed in physical space rather than virtual.
Luckily both
This check has existed in one form or another since c/s 369bafdb1c1 "xen: Big
changes to x86 start-of-day" in 2007. Even then, AFAICT, it wasn't necessary
because there was a clean split between the statically created entries (L3 and
higher) and the dynamically created ones (L2 and lower).
Withou
On 07.12.21 11:49, Anthony PERARD wrote:
On Tue, Dec 07, 2021 at 11:08:55AM +0100, Juergen Gross wrote:
On 06.12.21 18:02, Anthony PERARD wrote:
This avoid the need to generate the _paths.h header when the
information is from autoconf anyway.
They are no more users of the "buildmakevars2header
> On 6 Dec 2021, at 17:05, Julien Grall wrote:
>
> Hi Luca,
>
> On 06/12/2021 15:37, Luca Fancellu wrote:
>> Currently the maximum number of memory banks is fixed to
>> 128, but on some new platforms that have a large amount
>> of memory, this value is not enough
>
Hi Julien,
> Can you pr
On Tue, Dec 07, 2021 at 11:08:55AM +0100, Juergen Gross wrote:
> On 06.12.21 18:02, Anthony PERARD wrote:
> > This avoid the need to generate the _paths.h header when the
> > information is from autoconf anyway.
> >
> > They are no more users of the "buildmakevars2header" macro, so it can
> > be r
On 25.11.2021 14:39, Anthony PERARD wrote:
> clang 6.0 and newer behave like gcc in regards for the FILE symbol, so
> only the filename rather than the full path to the source file.
>
> clang 3.8.1-24 (in our debian:stretch container) and 3.5.0-10
> (in our debian:jessie container) do store the fu
On 06.12.21 18:02, Anthony PERARD wrote:
Use both ZLIB_CFLAGS and ZLIB_LIBS instead of cherry-picking flags
from a single "ZLIB" variable.
Signed-off-by: Anthony PERARD
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
D
On 07.12.2021 10:59, Julien Grall wrote:
> On 07/12/2021 09:11, Jan Beulich wrote:
>> On 06.12.2021 17:21, Julien Grall wrote:
>>> I still have have no way to verify
>>> what you did is correct.
>>>
>>> For instance, the tags in patch #2 are:
>>>
>>> Link: http://lkml.kernel.org/r/20191104185107.3b
On 06.12.21 18:02, Anthony PERARD wrote:
This avoid the need to generate the _paths.h header when the
information is from autoconf anyway.
They are no more users of the "buildmakevars2header" macro, so it can
be removed from "Config.mk".
Also removed the extra "-f" flag where "$(RM)" is used (x
1 - 100 of 115 matches
Mail list logo
