On 04.11.22 06:01, Andrew Cooper wrote:
On 03/11/2022 16:36, Juergen Gross wrote:
The code generated for the call_handlers_*() macros needs to avoid
undefined behavior when multiple handlers share the same priority.
The issue is the hypercall number being unverified fed into the macros
and then
On 03/11/2022 16:36, Juergen Gross wrote:
> The code generated for the call_handlers_*() macros needs to avoid
> undefined behavior when multiple handlers share the same priority.
> The issue is the hypercall number being unverified fed into the macros
> and then used to set a mask via "mask =
flight 174607 xen-unstable real [real]
flight 174612 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/174607/
http://logs.test-lab.xenproject.org/osstest/logs/174612/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
flight 174610 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174610/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf cab1f02565d3b29081dd21afb074f35fdb4e1fd6
baseline version:
ovmf
Hi Andrew,
Following yesterday's community call, there are 4 open release blockers which
we don't know the status. So I am sending this email to ask if you have any
updates on them or if there is anything that I can help to keep these release
blockers processing.
1. APIC hardware assistance
Hi Marek,
> -Original Message-
> From: Xen-devel On Behalf Of
> Subject: [PATCH v8 2/2] drivers/char: suspend handling in XHCI console
> driver
>
> Similar to the EHCI driver - save/restore relevant BAR and command
> register, re-configure DbC on resume and stop/start timer.
> On resume
Hi Edwin,
> -Original Message-
> From: Edwin Török
> Subject: [[PATCH for-4.17 v1]] tools/ocaml/xenstored/store.ml: fix build
> error
>
> Building with Dune in release mode fails with:
> ```
> File "ocaml/xenstored/store.ml", line 464, characters 13-32:
> Warning 18: this type-based
Hi Marek,
> -Original Message-
>
> FWIW, most of the diff is just extracting loop body into a function, the
> only functional difference is a new called for this function, and moving
> one of the checks (MAX_USER_RMRR_PAGES enforcement) outside of it. So,
> my (biased) opinion is, it's
flight 174603 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174603/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-vhd 8 xen-boot fail REGR. vs. 173462
On 03/11/2022 15:08, Michal Orzel wrote:
Hi Ayan,
Hi Michal,
On 31/10/2022 16:13, Ayan Kumar Halder wrote:
The title is a bit ambiguous given that the previous patches were also defining
GIC registers.
Maybe adding "remaining" would result in a better commit title.
Refer "Arm IHI 0069H
On Thu, Nov 03, 2022 at 02:55:31AM +, Henry Wang wrote:
> Hi Jan,
>
> > -Original Message-
> > From: Jan Beulich
> > Subject: Re: [PATCH v8 1/2] IOMMU/VT-d: wire common device reserved
> > memory API
> >
> > Signed-off-by: Marek Marczykowski-Górecki
> > >>>
> >
flight 174599 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174599/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 18 guest-start/debian.repeat fail REGR. vs.
174540
Tests which are
On Thu, Nov 03, 2022 at 07:38:07PM +0100, Dominik Brodowski wrote:
> Am Fri, Nov 04, 2022 at 03:29:44AM +0900 schrieb Krzysztof Wilczyński:
...
> > That said, Dominik is the maintainer of PCMCIA driver, so his is the last
> > word, so to speak. :)
> >
> > > Considering this is done, can you
On Fri, Nov 04, 2022 at 03:29:44AM +0900, Krzysztof Wilczyński wrote:
> > > > -
> > > > - for (i = 0; i < PCI_BRIDGE_RESOURCE_NUM; i++) {
> > > > - res = s->cb_dev->bus->resource[i];
> > > > -#else
> > > > - pci_bus_for_each_resource(s->cb_dev->bus, res, i) {
> > > >
Hello,
[...]
> > > -
> > > - for (i = 0; i < PCI_BRIDGE_RESOURCE_NUM; i++) {
> > > - res = s->cb_dev->bus->resource[i];
> > > -#else
> > > - pci_bus_for_each_resource(s->cb_dev->bus, res, i) {
> > > #endif
> > > +
> > > + pci_bus_for_each_resource_p(s->cb_dev->bus, res) {
> > >
Am Fri, Nov 04, 2022 at 03:29:44AM +0900 schrieb Krzysztof Wilczyński:
> Hello,
>
> [...]
> > > > -
> > > > - for (i = 0; i < PCI_BRIDGE_RESOURCE_NUM; i++) {
> > > > - res = s->cb_dev->bus->resource[i];
> > > > -#else
> > > > - pci_bus_for_each_resource(s->cb_dev->bus,
Building with Dune in release mode fails with:
```
File "ocaml/xenstored/store.ml", line 464, characters 13-32:
Warning 18: this type-based record disambiguation is not principal.
File "ocaml/xenstored/store.ml", line 1:
Error: Some fatal warnings were triggered (1 occurrences)
```
This is a
On Thu, Nov 03, 2022 at 06:25:45PM +0100, Dominik Brodowski wrote:
> Am Thu, Nov 03, 2022 at 07:12:45PM +0200 schrieb Andy Shevchenko:
> > On Thu, Nov 03, 2022 at 06:03:24PM +0100, Dominik Brodowski wrote:
...
> > Considering this is done, can you issue your conditional tag so I will
> >
Am Thu, Nov 03, 2022 at 06:46:44PM +0200 schrieb Andy Shevchenko:
> The pci_bus_for_each_resource_p() hides the iterator loop since
> it may be not used otherwise. With this, we may drop that iterator
> variable definition.
Thanks for your patch!
> diff --git a/drivers/pcmcia/rsrc_nonstatic.c
Am Thu, Nov 03, 2022 at 07:12:45PM +0200 schrieb Andy Shevchenko:
> On Thu, Nov 03, 2022 at 06:03:24PM +0100, Dominik Brodowski wrote:
> > Am Thu, Nov 03, 2022 at 06:46:44PM +0200 schrieb Andy Shevchenko:
>
> ...
>
> > > -
> > > - for (i = 0; i < PCI_BRIDGE_RESOURCE_NUM; i++) {
> > > -
Hi,
+Julien and Stefano
> On 2 Nov 2022, at 09:58, Jan Beulich wrote:
>
> On 01.11.2022 08:56, Juergen Gross wrote:
>> On 29.10.22 23:50, osstest service owner wrote:
>>> flight 174539 linux-linus real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/174539/
>>>
>>> Regressions :-(
On Thu, Nov 03, 2022 at 06:03:24PM +0100, Dominik Brodowski wrote:
> Am Thu, Nov 03, 2022 at 06:46:44PM +0200 schrieb Andy Shevchenko:
...
> > -
> > - for (i = 0; i < PCI_BRIDGE_RESOURCE_NUM; i++) {
> > - res = s->cb_dev->bus->resource[i];
> > -#else
> > -
Hi Roger,
> -Original Message-
> From: Roger Pau Monne
> Subject: [PATCH for-4.17 v3 1/2] amd/virt_ssbd: set SSBD at vCPU context
> switch
>
> The current logic for AMD SSBD context switches it on every
> vm{entry,exit} if the Xen and guest selections don't match. This is
> expensive
The current logic for AMD SSBD context switches it on every
vm{entry,exit} if the Xen and guest selections don't match. This is
expensive when not using SPEC_CTRL, and hence should be avoided as
much as possible.
When SSBD is not being set from SPEC_CTRL on AMD don't context switch
at
Since the VIRT_SPEC_CTRL.SSBD selection is no longer context switched
on vm{entry,exit} there's no need to use a synthetic feature bit for
it anymore.
Remove the bit and instead use a global variable.
No functional change intended.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
Hello,
Just two patches remaining, and the last one is already Acked.
First patch deals with moving the switching of SSBD from guest
vm{entry,exit} to vCPU context switch, and lets Xen run with the guest
SSBD selection under some circumstances by default.
Thanks, Roger.
Roger Pau Monne (2):
On Mon, Oct 24, 2022 at 10:21:25PM -0500, Oskari Pirhonen wrote:
> On Mon, Oct 24, 2022 at 03:46:42 -0700, Denton Liu wrote:
> > A user may wish to use an image that is not sorted as the "latest"
> > version as the top-level entry. For example, in Arch Linux, if a user
> > has the LTS and regular
Hi Stefano,
Thanks!
I used xen-guest-image-minimal(simple console based image) as a guest with
fbcon & fbdev enabled in kernel configurations but still the same error
can't open the display.
below are the outcome of "xenstore-ls":
Hi Juergen and Jan,
> -Original Message-
> From: Jan Beulich
> Subject: Re: [PATCH-for-4.17] xen: fix generated code for calling hypercall
> handlers
>
> On 03.11.2022 17:36, Juergen Gross wrote:
> > The code generated for the call_handlers_*() macros needs to avoid
> > undefined
The pci_bus_for_each_resource_p() hides the iterator loop since
it may be not used otherwise. With this, we may drop that iterator
variable definition.
Signed-off-by: Andy Shevchenko
---
drivers/pcmcia/rsrc_nonstatic.c | 9 +++--
drivers/pcmcia/yenta_socket.c | 3 +--
2 files changed, 4
The pci_bus_for_each_resource_p() hides the iterator loop since
it may be not used otherwise. With this, we may drop that iterator
variable definition.
Signed-off-by: Andy Shevchenko
---
drivers/eisa/pci_eisa.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Provide two new helper macros to iterate over PCI device resources and
convert users.
Looking at it, refactor existing pci_bus_for_each_resource() and convert
users accordingly.
This applies on top of this patch Mika sent out earlier:
Refactor pci_bus_for_each_resource() in the same way as it's done in
pci_dev_for_each_resource() case. This will allow to hide iterator
inside the loop, where it's not used otherwise.
No functional changes intended.
Signed-off-by: Andy Shevchenko
---
.clang-format | 1 +
From: Mika Westerberg
Instead of open-coding it everywhere introduce a tiny helper that can be
used to iterate over each resource of a PCI device, and convert the most
obvious users into it.
While at it drop doubled empty line before pdev_sort_resources().
No functional changes intended.
On 03.11.2022 17:36, Juergen Gross wrote:
> The code generated for the call_handlers_*() macros needs to avoid
> undefined behavior when multiple handlers share the same priority.
> The issue is the hypercall number being unverified fed into the macros
> and then used to set a mask via "mask =
The code generated for the call_handlers_*() macros needs to avoid
undefined behavior when multiple handlers share the same priority.
The issue is the hypercall number being unverified fed into the macros
and then used to set a mask via "mask = 1ULL << ".
Avoid a shift amount of more than 63 by
On 03.11.2022 14:38, Jan Beulich wrote:
> On 29.07.2022 09:04, Jane Malalane wrote:
>> @@ -125,6 +130,9 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_xen_hvm_callback)
>> {
>> struct pt_regs *old_regs = set_irq_regs(regs);
>>
>> +if (xen_percpu_upcall)
>> +ack_APIC_irq();
>> +
>>
Clarify documentation in the use of struct drm_driver.last_close and
struct drm_mode_config_funcs.output_poll_changed. Those callbacks should
not be said for fbdev implementations on top of struct drm_client_funcs.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 6 --
Move the generic fbdev implementation into its own source and header
file. Adapt drivers. No functional changes, but some of the internal
helpers have been renamed to fit into the drm_fbdev_ naming scheme.
v3:
* rename drm_fbdev.{c,h} to drm_fbdev_generic.{c,h}
* rebase onto
Remove include statements for where it is not
required (i.e., most of them). In a few places include other header
files that are required by the source code.
v3:
* fix amdgpu include statements
* fix rockchip include statements
Signed-off-by: Thomas Zimmermann
Reviewed-by:
flight 174598 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174598/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 174549
test-armhf-armhf-libvirt-qcow2 15
Call struct fb_ops.fb_sync in drm_fbdev_{read,write}() to mimic the
behavior of fbdev. Fbdev implementations of fb_read and fb_write in
struct fb_ops invoke fb_sync to synchronize with outstanding operations
before I/O. Doing the same in DRM implementations will allow us to use
them throughout DRM
Uncouple the parameter drm_leak_fbdev_smem from the implementation by
setting a flag in struct drm_fb_helper. This will help to move the
generic fbdev emulation into its own source file, while keeping the
parameter in drm_fb_helper.c. No functional changes.
Signed-off-by: Thomas Zimmermann
---
flight 174597 xen-unstable real [real]
flight 174604 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/174597/
http://logs.test-lab.xenproject.org/osstest/logs/174604/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
Initialize the generic fbdev emulation even if it has been disabled
on the kernel command line. The hotplug and mode initialization will
fail accordingly.
The kernel parameter can still be changed at runtime and the emulation
will initialize after hotplugging the connector.
Signed-off-by: Thomas
Rename drm_fb_helper_unregister_fbi() to drm_fb_helper_unregister_info()
as part of unifying the naming within fbdev helpers. Adapt drivers. No
functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
Pull the test for fb_dirty into the caller to avoid extra work
if no callback has been set. In this case no damage handling is
required and no damage area needs to be computed. Print a warning
if the damage worker runs without getting an fb_dirty callback.
Signed-off-by: Thomas Zimmermann
Include for of_match_ptr().
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/tve200/tve200_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/tve200/tve200_drv.c
b/drivers/gpu/drm/tve200/tve200_drv.c
index
Rename struct drm_fb_helper.fbdev to info. The current name is
misleading as it overlaps with generic fbdev naming conventions.
Adapt to the usual naming in fbdev drivers by calling the field
'info'. No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
Only include what we have to.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
include/drm/drm_fb_helper.h | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index
Rename drm_fb_helper_alloc_fbi() to drm_fb_helper_alloc_info() as
part of unifying the naming within fbdev helpers. Adapt drivers. No
functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
Implement the fbdev's read/write helpers with the same functions. Use
the generic fbdev's code as template. Convert all drivers.
DRM's fb helpers must implement regular I/O functionality in struct
fb_ops and possibly perform a damage update. Handle all this in the
same functions and convert
Don't set struct drm_driver.output_poll_changed. It's used to restore
the fbdev console. But as ingenic uses generic fbdev emulation, the
console is being restored by the DRM client helpers already. See the
functions drm_kms_helper_hotplug_event() and
drm_kms_helper_connector_hotplug_event() in
Include for devm_of_find_backlight().
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
Don't set struct drm_driver.output_poll_changed. It's used to restore
the fbdev console. But as DCSS uses generic fbdev emulation, the
console is being restored by the DRM client helpers already. See the
functions drm_kms_helper_hotplug_event() and
drm_kms_helper_connector_hotplug_event() in
The fbdev helpers implement a damage worker that forwards fbdev
updates to the DRM driver. The worker's update logic depends on
the generic fbdev emulation. Separate the two via function pointer.
The generic fbdev emulation sets struct drm_fb_helper_funcs.fb_dirty,
a new callback that hides the
Don't set struct drm_driver.lastclose. It's used to restore the
fbdev console. But as vboxvideo uses generic fbdev emulation, the
console is being restored by the DRM client helpers already. See
the call to drm_client_dev_restore() in drm_lastclose().
Signed-off-by: Thomas Zimmermann
Don't set struct drm_driver.output_poll_changed. It's used to restore
the fbdev console. But as rockchip uses generic fbdev emulation, the
console is being restored by the DRM client helpers already. See the
functions drm_kms_helper_hotplug_event() and
drm_kms_helper_connector_hotplug_event() in
Don't set struct drm_driver.output_poll_changed. It's used to restore
the fbdev console. But as amdgpu uses generic fbdev emulation, the
console is being restored by the DRM client helpers already. See the
functions drm_kms_helper_hotplug_event() and
drm_kms_helper_connector_hotplug_event() in
Don't set struct drm_driver.output_poll_changed. It's used to restore
the fbdev console. But as logicvc uses generic fbdev emulation, the
console is being restored by the DRM client helpers already. See the
functions drm_kms_helper_hotplug_event() and
drm_kms_helper_connector_hotplug_event() in
Don't set struct drm_driver.lastclose. It's used to restore the
fbdev console. But as mcde uses generic fbdev emulation, the
console is being restored by the DRM client helpers already. See
the call to drm_client_dev_restore() in drm_lastclose().
Signed-off-by: Thomas Zimmermann
Reviewed-by:
Separate generic fbdev emulation from the helper code that is shared
among the various fbdev implementations within DRM. Affects many drivers.
It has become apparent that our fully generic fbdev emulation will
never produce optimal results for all drivers. In its current form,
it is also hard to
Don't set struct drm_driver.lastclose. It's used to restore the
fbdev console. But as komeda uses generic fbdev emulation, the
console is being restored by the DRM client helpers already. See
the call to drm_client_dev_restore() in drm_lastclose().
Signed-off-by: Thomas Zimmermann
Reviewed-by:
Hi Ayan,
On 31/10/2022 16:13, Ayan Kumar Halder wrote:
>
The title is a bit ambiguous given that the previous patches were also defining
GIC registers.
Maybe adding "remaining" would result in a better commit title.
>
> Refer "Arm IHI 0069H ID020922"
> 12.5.23 ICC_SGI1R, Interrupt Controller
On 20.10.2022 08:14, Wei Chen wrote:
> There are some codes in x86/numa.c can be shared by common
> architectures to implememnt NUMA support. Just like some
> variables and functions to check and store NUMA memory map.
> And some variables and functions to do NUMA initialization.
>
> In this
On 03.11.22 12:52, Anthony PERARD wrote:
The text of the licence has been check to be the same as the one at
https://spdx.org/licenses/MIT.html, except we don't have "(including
the next paragraph)".
Mecanical change done with a script.
Signed-off-by: Anthony PERARD
Reviewed-by: Juergen
On 03.11.2022 11:36, Roger Pau Monné wrote:
> On Thu, Nov 03, 2022 at 10:01:49AM +0100, Jan Beulich wrote:
>> On 03.11.2022 09:52, Roger Pau Monné wrote:
>>> On Thu, Nov 03, 2022 at 09:09:41AM +0100, Jan Beulich wrote:
On 02.11.2022 18:38, Roger Pau Monné wrote:
> On Wed, Nov 02, 2022 at
On 31.10.2022 19:37, Andrew Cooper wrote:
> On 31/10/2022 15:55, Jan Beulich wrote:
>> Of course I'm yet to figure out how IRR bit 0x13 ends up being set in
>> the first place.
>
> 0x13 is a legal vector for incoming interrupts (for reasons of Windows
> using 0x1f for self-IPI.)
I was wrong
On 29.07.2022 09:04, Jane Malalane wrote:
> @@ -125,6 +130,9 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_xen_hvm_callback)
> {
> struct pt_regs *old_regs = set_irq_regs(regs);
>
> + if (xen_percpu_upcall)
> + ack_APIC_irq();
> +
> inc_irq_stat(irq_hv_callback_count);
>
>
On 03.11.22 14:19, Brian Gerst wrote:
On Thu, Nov 3, 2022 at 8:37 AM Juergen Gross wrote:
Convert the remaining cases of static_cpu_has(X86_FEATURE_XENPV) and
boot_cpu_has(X86_FEATURE_XENPV) to use cpu_feature_enabled(), allowing
more efficient code in case the kernel is configured without
On Thu, Nov 3, 2022 at 8:37 AM Juergen Gross wrote:
>
> Convert the remaining cases of static_cpu_has(X86_FEATURE_XENPV) and
> boot_cpu_has(X86_FEATURE_XENPV) to use cpu_feature_enabled(), allowing
> more efficient code in case the kernel is configured without
> CONFIG_XEN_PV.
>
> Signed-off-by:
flight 174592 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174592/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-vhd 8 xen-boot fail REGR. vs. 173462
All,
we're pleased to announce the release of Xen 4.16.2. This has been available
for a while from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.16
(tag RELEASE-4.16.2) or from the XenProject download page
Hi Ayan,
On 31/10/2022 16:13, Ayan Kumar Halder wrote:
>
>
> Refer "Arm IHI 0069H ID020922",
> 12.7.1 - Interrupt Controller Hyp Active Priorities Group0 Registers 0-3
> 12.7.2 - Interrupt Controller Hyp Active Priorities Group1 Registers 0-3
>
Commit msg like this is not really beneficial as
Hi Ayan,
On 30/10/2022 00:48, Ayan Kumar Halder wrote:
>
>
> Refer ARM DDI 0487G.b ID072021, B2.2.1
Please refer to the latest spec.
Apart from that...
> "Requirements for single-copy atomicity
>
> - A read that is generated by a load instruction that loads a single
> general-purpose
On Thu, Nov 03, 2022 at 07:58:52AM +0100, Paul Leiber wrote:
>
>
> Am 30.10.2022 um 17:36 schrieb G.R.:
> > On Mon, Jan 10, 2022 at 10:54 PM Roger Pau Monné
> > wrote:
> > > > So looks like at least the imbalance between two directions are not
> > > > related to your patch.
> > > > Likely the
Hi Ayan,
On 31/10/2022 16:13, Ayan Kumar Halder wrote:
>
>
> Refer "Arm IHI 0069H ID020922", 12.4.6, Interrupt Controller List Registers
>
> AArch64 System register ICH_LR_EL2 bits [31:0] are architecturally
> mapped to AArch32 System register ICH_LR[31:0].
> AArch64 System register ICH_LR_EL2
The notice in the COPYING file in "xen/include/public/COPYING" doesn't
really apply to the files that ultimately are been install at
"/usr/include/xen". The issue are headers in the "sys/" subdirectory
that comes from other projects such as Linux or FreeBSD.
The main issue is that there are two
This header have been created by moving code from other part of the
project and miss a licence header. The original source code was some
version of GPL or LGPL but we intend to have the public header to be
MIT so they can be included easily in other projects.
Part of device_tree_defs.h were moved
The headers install in "/usr/include/xen/foreign/" are missing a
licence header. This patch adds a SPDX identifier to clarify that
the MIT licence is used.
The script now check that the licence of the input file is also MIT,
by checking for the presence of the SPDX identifier.
Also add
The script "tools/include/xen-foreign/mkheader.py" is going to do a
sanity check on the licences of those headers. To ease this, we will
replace the verbatim copy of the MIT licence by its SPDX identifier
equivalent.
The text of the licence has been check to be the same as the one at
Fixes: 81f559e97974 ("make error codes a formal part of the ABI")
Reported-by: Andrew Cooper
Signed-off-by: Anthony PERARD
---
xen/include/public/errno.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/include/public/errno.h b/xen/include/public/errno.h
index 5c53af6af9..6bdc8c5079
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.licences-fix-public-headers-v2
Hi,
Andrew pointed out some licences issue:
https://lore.kernel.org/xen-devel/b58f5340-d4fa-df9d-89de-6137005ad...@citrix.com/T/#u
tracked here:
On Wed, Nov 02, 2022 at 01:16:04PM +, Julien Grall wrote:
> Hi,
>
> On 02/11/2022 11:28, Anthony PERARD wrote:
> > This header have been created by moving code from other part of the
> > project and miss a licence header. The original source code was some
> > version of GPL or LGPL but we
flight 174601 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174601/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
Testing for Xen PV guest mode in a 32-bit only code section can be
dropped, as Xen PV guests are supported in 64-bit mode only.
While at it switch from boot_cpu_has() to cpu_feature_enabled() in the
64-bit part of the code.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/switch_to.h | 7
Convert the remaining cases of static_cpu_has(X86_FEATURE_XENPV) and
boot_cpu_has(X86_FEATURE_XENPV) to use cpu_feature_enabled(), allowing
more efficient code in case the kernel is configured without
CONFIG_XEN_PV.
Signed-off-by: Juergen Gross
---
arch/x86/kernel/cpu/amd.c| 2 +-
The check for 64-bit mode when testing X86_FEATURE_XENPV isn't needed,
as Xen PV guests are no longer supported in 32-bit mode.
While at it switch from boot_cpu_has() to cpu_feature_enabled().
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/entry-common.h | 4 ++--
1 file changed, 2
Add X86_FEATURE_XENPV to the features handled specially in
disabled-features.h.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/disabled-features.h | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/disabled-features.h
Make especially kernels without CONFIG_XEN_PV more efficient by
using cpu_feature_enabled(X86_FEATURE_XENPV) instead of boot_cpu_has()
and friends.
Juergen Gross (4):
x86: add X86_FEATURE_XENPV to disabled-features.h
x86: remove unneeded 64-bit dependency in arch_enter_from_user_mode()
x86:
On 11/3/22 12:07, Philippe Mathieu-Daudé wrote:
On 3/11/22 10:33, Laurent Vivier wrote:
On 10/28/22 07:04, Jason Wang wrote:
在 2022/10/21 17:09, Laurent Vivier 写道:
Signed-off-by: Laurent Vivier
Acked-by: Michael S. Tsirkin
---
I got this:
63/63
On 3/11/22 10:33, Laurent Vivier wrote:
On 10/28/22 07:04, Jason Wang wrote:
在 2022/10/21 17:09, Laurent Vivier 写道:
Signed-off-by: Laurent Vivier
Acked-by: Michael S. Tsirkin
---
I got this:
63/63 ERROR:../tests/qtest/netdev-socket.c:139:test_stream_inet_ipv6:
assertion failed (resp ==
On Thu, Nov 03, 2022 at 10:01:49AM +0100, Jan Beulich wrote:
> On 03.11.2022 09:52, Roger Pau Monné wrote:
> > On Thu, Nov 03, 2022 at 09:09:41AM +0100, Jan Beulich wrote:
> >> On 02.11.2022 18:38, Roger Pau Monné wrote:
> >>> On Wed, Nov 02, 2022 at 12:49:17PM +0100, Jan Beulich wrote:
> On
Hi all,
Xen 4.17 rc3 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.17.0-rc3
For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.17.0-rc3/xen-4.17.0-rc3.tar.gz
And the signature is at:
On 10/28/22 07:04, Jason Wang wrote:
在 2022/10/21 17:09, Laurent Vivier 写道:
Signed-off-by: Laurent Vivier
Acked-by: Michael S. Tsirkin
---
I got this:
63/63 ERROR:../tests/qtest/netdev-socket.c:139:test_stream_inet_ipv6: assertion failed
(resp == expect): ("st0:
On 27.10.2022 21:37, Andrew Cooper wrote:
> However, we're also very close to supporting parallel boot. The
> serialising point we currently have is __high_start loading %rsp from
> stack_start, because that's a single pointer adjusted by do_boot_cpu().
> Everything else, even the processor's
On 03.11.2022 09:52, Roger Pau Monné wrote:
> On Thu, Nov 03, 2022 at 09:09:41AM +0100, Jan Beulich wrote:
>> On 02.11.2022 18:38, Roger Pau Monné wrote:
>>> On Wed, Nov 02, 2022 at 12:49:17PM +0100, Jan Beulich wrote:
On 29.10.2022 15:12, Roger Pau Monne wrote:
> ---
On Thu, Nov 03, 2022 at 09:09:41AM +0100, Jan Beulich wrote:
> On 02.11.2022 18:38, Roger Pau Monné wrote:
> > On Wed, Nov 02, 2022 at 12:49:17PM +0100, Jan Beulich wrote:
> >> On 29.10.2022 15:12, Roger Pau Monne wrote:
> >>> --- a/xen/arch/x86/hvm/svm/svm.c
> >>> +++ b/xen/arch/x86/hvm/svm/svm.c
On 31.10.2022 19:37, Andrew Cooper wrote:
> On 31/10/2022 15:55, Jan Beulich wrote:
>> Hello,
>>
>> quite likely this isn't new, but I've ended up noticing it only recently:
>> On an oldish system where I hand a HVM guest an SR-IOV NIC (not sure yet
>> whether that actually matters) all APs have
On 02.11.2022 18:38, Roger Pau Monné wrote:
> On Wed, Nov 02, 2022 at 12:49:17PM +0100, Jan Beulich wrote:
>> On 29.10.2022 15:12, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/hvm/svm/svm.c
>>> +++ b/xen/arch/x86/hvm/svm/svm.c
>>> @@ -973,6 +973,16 @@ static void cf_check
1 - 100 of 102 matches
Mail list logo
