On 24.02.2022 14:23, Jan Beulich wrote:
> 1: AMD: collect checking for bugs in a single function
> 2: correct fencing around CLFLUSH
It would be nice to get this bug fix in (and perhaps even backported), no
matter that we haven't had reports of the wrong behavior actually causing
any noticeable pr
On 05.04.22 10:57, Luca Fancellu wrote:
Currently cpupool0 can use only the default scheduler, and
cpupool_create has an hardcoded behavior when creating the pool 0
that doesn't allocate new memory for the scheduler, but uses the
default scheduler structure in memory.
With this commit it is poss
On 07.04.2022 03:01, Andrew Cooper wrote:
> c/s 1a914256dca5 increased the AMD max leaf from 0x801c to 0x8021, but
> did not adjust anything in the calculate_*_policy() chain. As a result, on
> hardware supporting these leaves, we read the real hardware values into the
> raw policy, then c
flight 169202 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169202/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 05.04.22 10:57, Luca Fancellu wrote:
Introduce a way to create different cpupools at boot time, this is
particularly useful on ARM big.LITTLE system where there might be the
need to have different cpupools for each type of core, but also
systems using NUMA can have different cpu pools for each
flight 169195 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169195/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 169181
Tests which did not succee
Despite the comment there infinite recursion was still possible, by
flip-flopping between two domains. This is because prev_dom is derived
from the DID found in the context entry, which was already updated by
the time error recovery is invoked. Simply introduce yet another mode
flag to prevent roll
First there's a printk() which actually wrongly uses pdev in the first
place: We want to log the coordinates of the (perhaps fake) device
acted upon, which may not be pdev.
Then it was quite pointless for eb19326a328d ("VT-d: prepare for per-
device quarantine page tables (part I)") to add a domid
On 4/6/22 2:05 PM, Christoph Hellwig wrote:
Secure erase is a very different operation from discard in that it is
a data integrity operation vs hint. Fully split the limits and helper
infrastructure to make the separation more clear.
Signed-off-by: Christoph Hellwig
For the bcache part,
Ack
1: avoid NULL deref on domain_context_mapping_one() error paths
2: avoid infinite recursion on domain_context_mapping_one() error path
Jan
On 05.04.22 10:57, Luca Fancellu wrote:
Create new public function to create cpupools, can take as parameter
the scheduler id or a negative value that means the default Xen
scheduler will be used.
Signed-off-by: Luca Fancellu
---
Changes in v5:
- no changes
Changes in v4:
- no changes
Changes i
On 06.04.2022 20:02, Tamas K Lengyel wrote:
> On Wed, Apr 6, 2022 at 11:14 AM Jan Beulich wrote:
>> On 06.04.2022 16:58, Tamas K Lengyel wrote:
>>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>>> @@ -4008,6 +4008,18 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>
On 4/6/22 2:05 PM, Christoph Hellwig wrote:
Just use a non-zero max_discard_sectors as an indicator for discard
support, similar to what is done for write zeroes.
The only places where needs special attention is the RAID5 driver,
which must clear discard support for security reasons by default,
On 4/6/22 2:05 PM, Christoph Hellwig wrote:
Add a helper to query the number of sectors support per each discard bio
based on the block device and use this helper to stop various places from
poking into the request_queue to see if discard is supported and if so how
much. This mirrors what is don
Hi Juergen,
I love your patch! Yet something to improve:
[auto build test ERROR on xen-tip/linux-next]
[also build test ERROR on linus/master linux/master v5.18-rc1 next-20220406]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
flight 169193 xen-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169193/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169178
test-amd64-amd64-xl-qemut-win7-a
flight 169194 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169194/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169179
test-amd64-amd64-xl-qemuu-win7-a
Christoph,
> Secure erase is a very different operation from discard in that it is
> a data integrity operation vs hint. Fully split the limits and helper
> infrastructure to make the separation more clear.
Great!
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engi
Christoph,
> Add a helper to query the number of sectors support per each discard
> bio based on the block device and use this helper to stop various
> places from poking into the request_queue to see if discard is
> supported and if so how much. This mirrors what is done e.g. for
> write zeroe
Christoph,
> Just use a non-zero max_discard_sectors as an indicator for discard
> support, similar to what is done for write zeroes.
Very happy to finally see this flag removed!
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
Christoph,
> Abstract away implementation details from file systems by providing a
> block_device based helper to retreive the discard granularity.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
Christoph,
> Move all the logic to limit the discard bio size into a common helper
> so that it is better documented.
Looks OK.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
Christoph,
> No need to inline these fairly larger helpers. Also fix the return
> value to be unsigned, just like the field in struct queue_limits.
I believe the original reason for the signed int here was to be able to
express -1 for sysfs. I am not sure why I didn't just use the misaligned
f
Christoph,
> Use the bdev based alignment helper instead of open coding it.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
Christoph,
> Just use bdev_alignment_offset in disk_discard_alignment_show instead.
> That helpers is the same except for an always false branch that
> doesn't matter in this slow path.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
Christoph,
> No need to inline these fairly larger helpers.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
Christoph,
> This does the same as the open coded variant except for an extra
> branch, and allows to remove queue_alignment_offset entirely.
Also fine.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
Christoph,
> Replace the open coded offset calculation with the proper helper.
> This is an ABI change in that the -1 for a misaligned partition is
> properly propagated, which can be considered a bug fix and maches what
> is done on the whole device.
Looks good.
Reviewed-by: Martin K. Peterse
Christoph,
> Add a helper to check the nonrot flag based on the block_device
> instead of having to poke into the block layer internal request_queue.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
Christoph,
> Use the proper bdev_discard_alignment helper that accounts for partition
> offsets.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
Christoph,
> Add a helper to check the stable writes flag based on the block_device
> instead of having to poke into the block layer internal request_queue.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
Christoph,
> Add a helper to check the FUA flag based on the block_device instead
> of having to poke into the block layer internal request_queue.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
Christoph,
> Add a helper to check the write cache flag based on the block_device
> instead of having to poke into the block layer internal request_queue.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
Christoph,
> Add a helper to check the max supported sectors for zone append based
> on the block_device instead of having to poke into the block layer
> internal request_queue.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
Christoph,
> The target code is a consumer of the block layer and should generally
> work on struct block_device.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
Christoph,
> For block devices the target code implements UNMAP as calls to
> blkdev_issue_discard, which does not guarantee zeroing just because
> Write Zeroes is supported.
>
> Note that this does not affect the file backed path which uses
> fallocate to punch holes.
Reviewed-by: Martin K. Pe
Christoph,
> For block devices the target code implements UNMAP as calls to
> blkdev_issue_discard, which does not guarantee zeroing just because
> Write Zeroes is supported.
>
> Note that this does not affect the file backed path which uses
> fallocate to punch holes.
>
> Fixes: 2237498f0b5c ("
Hi Juergen,
I love your patch! Perhaps something to improve:
[auto build test WARNING on xen-tip/linux-next]
[also build test WARNING on linus/master linux/master v5.18-rc1 next-20220406]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
From: Peng Fan
V3:
Addressed Michal's comments.
Add Henry's T-b
V2:
Per Julien's comments, fix coding style issue, drop unneeded code
Add i.MX lpuart driver and i.MX8QM platform support.
- lpuart is the uart IP used in i.MX8QM/QXP/93.
- Very basic i.MX8QM platform support.
Peng Fan (2):
From: Peng Fan
Signed-off-by: Peng Fan
---
xen/arch/arm/Kconfig.debug | 14 +++
xen/arch/arm/arm64/debug-imx-lpuart.inc | 52 +
xen/arch/arm/include/asm/imx-lpuart.h | 22 +--
3 files changed, 77 insertions(+), 11 deletions(-)
create mode 1006
From: Peng Fan
The i.MX LPUART Documentation:
https://www.nxp.com/webapp/Download?colCode=IMX8QMIEC
Chatper 13.6 Low Power Universal Asynchronous Receiver/
Transmitter (LPUART)
Tested-by: Henry Wang
Signed-off-by: Peng Fan
---
xen/arch/arm/include/asm/imx-lpuart.h | 64 ++
xen/drivers/ch
c/s 1a914256dca5 increased the AMD max leaf from 0x801c to 0x8021, but
did not adjust anything in the calculate_*_policy() chain. As a result, on
hardware supporting these leaves, we read the real hardware values into the
raw policy, then copy into host, and all the way into the PV/HVM def
On Mon, Apr 04, 2022 at 07:05:44AM +0200, Christoph Hellwig wrote:
> Hi all,
>
> this series tries to clean up the swiotlb initialization, including
> that of swiotlb-xen. To get there is also removes the x86 iommu table
> infrastructure that massively obsfucates the initialization path.
>
> Git
> diff --git a/arch/powerpc/platforms/pseries/svm.c
> b/arch/powerpc/platforms/pseries/svm.c
> index c5228f4969eb2..3b4045d508ec8 100644
> --- a/arch/powerpc/platforms/pseries/svm.c
> +++ b/arch/powerpc/platforms/pseries/svm.c
> @@ -28,7 +28,7 @@ static int __init init_svm(void)
>* need to
On Mon, Apr 04, 2022 at 07:05:51AM +0200, Christoph Hellwig wrote:
> The IOMMU table tries to separate the different IOMMUs into different
> backends, but actually requires various cross calls.
>
> Rewrite the code to do the generic swiotlb/swiotlb-xen setup directly
> in pci-dma.c and then just c
Hi Juergen,
I love your patch! Perhaps something to improve:
[auto build test WARNING on xen-tip/linux-next]
[also build test WARNING on linus/master linux/master v5.18-rc1 next-20220406]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
flight 169189 xen-unstable real [real]
flight 169204 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/169189/
http://logs.test-lab.xenproject.org/osstest/logs/169204/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On Tue, 5 Apr 2022, Luca Fancellu wrote:
> Introduce a way to create different cpupools at boot time, this is
> particularly useful on ARM big.LITTLE system where there might be the
> need to have different cpupools for each type of core, but also
> systems using NUMA can have different cpu pools f
flight 169192 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169192/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
I have contributed all the ARM tests to gitlab-ci. After checking with
Doug, I am happy to volunteer to co-maintain Continuous Integration.
Signed-off-by: Stefano Stabellini
Acked-by: Doug Goldstein
diff --git a/MAINTAINERS b/MAINTAINERS
index 6a097b43eb..cc87d5bbf1 100644
--- a/MAINTAINERS
+++
flight 169188 linux-linus real [real]
flight 169201 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/169188/
http://logs.test-lab.xenproject.org/osstest/logs/169201/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
flight 169196 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169196/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On Wed, Apr 6, 2022 at 11:06 PM Christoph Hellwig wrote:
>
> Abstract away implementation details from file systems by providing a
> block_device based helper to retreive the discard granularity.
>
> Signed-off-by: Christoph Hellwig
> ---
> block/blk-lib.c | 5 ++---
> drive
On Wed, Apr 6, 2022 at 11:14 AM Jan Beulich wrote:
>
> On 06.04.2022 16:58, Tamas K Lengyel wrote:
> > --- a/xen/arch/x86/hvm/monitor.c
> > +++ b/xen/arch/x86/hvm/monitor.c
> > @@ -328,6 +328,24 @@ bool hvm_monitor_check_p2m(unsigned long gla, gfn_t
> > gfn, uint32_t pfec,
> > return monitor
On 4/6/22 9:10 AM, Jason Andryuk wrote:
On Tue, Apr 5, 2022 at 9:31 PM Chuck Zmudzinski wrote:
Correction (sorry for the confusion):
I didn't know I needed to replace more than just a
re-built i915.ko module to enable the patch
for testing. When I updated the entire Debian kernel
package inclu
On Wed, Apr 6, 2022 at 11:05 PM Christoph Hellwig wrote:
>
> Add a helper to query the number of sectors support per each discard bio
> based on the block device and use this helper to stop various places from
> poking into the request_queue to see if discard is supported and if so how
> much. Th
On Fri, Apr 01, 2022 at 11:47:13AM +0100, Jane Malalane wrote:
> Introduce a new per-domain creation x86 specific flag to
> select whether hardware assisted virtualization should be used for
> x{2}APIC.
>
> A per-domain option is added to xl in order to select the usage of
> x{2}APIC hardware assi
On Fri, Apr 01, 2022 at 11:47:12AM +0100, Jane Malalane wrote:
> Add XEN_SYSCTL_PHYSCAP_X86_ASSISTED_XAPIC and
> XEN_SYSCTL_PHYSCAP_X86_ASSISTED_X2APIC to report accelerated xAPIC and
> x2APIC, on x86 hardware. This is so that xAPIC and x2APIC virtualization
> can subsequently be enabled on a per-d
flight 169186 xen-4.14-testing real [real]
flight 169200 xen-4.14-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/169186/
http://logs.test-lab.xenproject.org/osstest/logs/169200/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
On Wed, Apr 06, 2022 at 05:51:06PM +0200, Jan Beulich wrote:
> On 06.04.2022 17:09, Roger Pau Monné wrote:
> > On Wed, Apr 06, 2022 at 02:47:38PM +0200, Jan Beulich wrote:
> >> On 06.04.2022 12:38, Roger Pau Monné wrote:
> >>> On Wed, Apr 06, 2022 at 10:13:41AM +0200, Jan Beulich wrote:
> On 2
On 06.04.2022 17:51, Roger Pau Monné wrote:
> On Wed, Apr 06, 2022 at 05:31:22PM +0200, Jan Beulich wrote:
>> On 06.04.2022 17:16, Roger Pau Monne wrote:
>>> The values set in the shared_type field of xen_processor_performance
>>> have so far relied on Xen and Linux having the same
>>> CPUFREQ_SHAR
On Wed, Apr 06, 2022 at 05:31:22PM +0200, Jan Beulich wrote:
> On 06.04.2022 17:16, Roger Pau Monne wrote:
> > The values set in the shared_type field of xen_processor_performance
> > have so far relied on Xen and Linux having the same
> > CPUFREQ_SHARED_TYPE_ defines, as those have never been part
On 06.04.2022 17:09, Roger Pau Monné wrote:
> On Wed, Apr 06, 2022 at 02:47:38PM +0200, Jan Beulich wrote:
>> On 06.04.2022 12:38, Roger Pau Monné wrote:
>>> On Wed, Apr 06, 2022 at 10:13:41AM +0200, Jan Beulich wrote:
On 23.03.2022 09:54, Roger Pau Monné wrote:
> Hello,
>
> I was
On 06.04.2022 17:01, Roger Pau Monné wrote:
> On Wed, Apr 06, 2022 at 04:07:24PM +0200, Jan Beulich wrote:
>> On 06.04.2022 15:36, Roger Pau Monné wrote:
>>> On Wed, Apr 06, 2022 at 02:24:32PM +0200, Jan Beulich wrote:
First there's a printk() which actually wrongly uses pdev in the first
On 06.04.2022 17:16, Roger Pau Monne wrote:
> The values set in the shared_type field of xen_processor_performance
> have so far relied on Xen and Linux having the same
> CPUFREQ_SHARED_TYPE_ defines, as those have never been part of the
> public interface.
>
> Formalize by adding the defines for
On 4/6/22 9:10 AM, Jason Andryuk wrote:
On Tue, Apr 5, 2022 at 9:31 PM Chuck Zmudzinski wrote:
Correction (sorry for the confusion):
I didn't know I needed to replace more than just a
re-built i915.ko module to enable the patch
for testing. When I updated the entire Debian kernel
package inclu
Hi Jan,
On 06/04/2022 16:22, Jan Beulich wrote:
On 06.04.2022 17:15, Julien Grall wrote:
On 06/04/2022 15:44, Jan Beulich wrote:
c49ee0329ff3 ("SUPPORT.md: limit security support for hosts with very
much memory"), as a result of XSA-385, restricted security support to
8 TiB of host memory. Ext
On 06.04.2022 17:15, Julien Grall wrote:
> On 06/04/2022 15:44, Jan Beulich wrote:
>> c49ee0329ff3 ("SUPPORT.md: limit security support for hosts with very
>> much memory"), as a result of XSA-385, restricted security support to
>> 8 TiB of host memory. Extend this to 12 TiB, putting in place a gue
The values set in the shared_type field of xen_processor_performance
have so far relied on Xen and Linux having the same
CPUFREQ_SHARED_TYPE_ defines, as those have never been part of the
public interface.
Formalize by adding the defines for the allowed values in the public
header, while renaming
Hi,
On 06/04/2022 15:44, Jan Beulich wrote:
c49ee0329ff3 ("SUPPORT.md: limit security support for hosts with very
much memory"), as a result of XSA-385, restricted security support to
8 TiB of host memory. Extend this to 12 TiB, putting in place a guest
restriction to 8 TiB in exchange.
And th
On 06.04.2022 16:58, Tamas K Lengyel wrote:
> --- a/xen/arch/x86/hvm/monitor.c
> +++ b/xen/arch/x86/hvm/monitor.c
> @@ -328,6 +328,24 @@ bool hvm_monitor_check_p2m(unsigned long gla, gfn_t gfn,
> uint32_t pfec,
> return monitor_traps(curr, true, &req) >= 0;
> }
>
> +int hvm_monitor_vmexit(
On Wed, Apr 06, 2022 at 02:47:38PM +0200, Jan Beulich wrote:
> On 06.04.2022 12:38, Roger Pau Monné wrote:
> > On Wed, Apr 06, 2022 at 10:13:41AM +0200, Jan Beulich wrote:
> >> On 23.03.2022 09:54, Roger Pau Monné wrote:
> >>> Hello,
> >>>
> >>> I was looking at implementing ACPI Cx and Px state up
On Wed, Apr 06, 2022 at 04:07:24PM +0200, Jan Beulich wrote:
> On 06.04.2022 15:36, Roger Pau Monné wrote:
> > On Wed, Apr 06, 2022 at 02:24:32PM +0200, Jan Beulich wrote:
> >> First there's a printk() which actually wrongly uses pdev in the first
> >> place: We want to log the coordinates of the (
Allow specify distinct parts of the fork VM to be reset. This is useful when a
fuzzing operation involves mapping in only a handful of pages that are known
ahead of time. Throwing these pages away just to be re-copied immediately is
expensive, thus allowing to specify partial resets can speed thing
Add monitor event that hooks the vmexit handler allowing for both sync and
async monitoring of events. With async monitoring an event is placed on the
monitor ring for each exit and the rest of the vmexit handler resumes normally.
If there are additional monitor events configured those will also pl
Hi Luca,
On Tue, Apr 05, 2022 at 09:57:36AM +0100, Luca Fancellu wrote:
> diff --git a/tools/helpers/xen-init-dom0.c b/tools/helpers/xen-init-dom0.c
> index c99224a4b607..84286617790f 100644
> --- a/tools/helpers/xen-init-dom0.c
> +++ b/tools/helpers/xen-init-dom0.c
> @@ -43,7 +43,9 @@ int main(in
On 23.02.2022 16:59, Jan Beulich wrote:
> ..., moving the former into the new physmap.c. Also call the new
> functions directly from arch_iommu_hwdom_init() and
> vpci_make_msix_hole(), as the PV/HVM split is explicit there.
>
> Signed-off-by: Jan Beulich
> Reviewed-by: George Dunlap
May I ask
c49ee0329ff3 ("SUPPORT.md: limit security support for hosts with very
much memory"), as a result of XSA-385, restricted security support to
8 TiB of host memory. Extend this to 12 TiB, putting in place a guest
restriction to 8 TiB in exchange.
A 12 TiB host was certified successfully for use with
Hi Jan,
> On 31 Mar 2022, at 10:45, Jan Beulich wrote:
>
> When booting directly from EFI, obtaining this information from EFI is
> the only possible way. And even when booting with a boot loader
> interposed, it's more clean not to use legacy BIOS calls for this
> purpose. (The downside being t
On 31.03.2022 11:45, Jan Beulich wrote:
> When booting directly from EFI, obtaining this information from EFI is
> the only possible way. And even when booting with a boot loader
> interposed, it's more clean not to use legacy BIOS calls for this
> purpose. (The downside being that there are no "ca
On 05.04.2022 10:45, Roger Pau Monné wrote:
> On Thu, Mar 31, 2022 at 11:44:10AM +0200, Jan Beulich wrote:
>> GrUB2 can be told to leave the screen in the graphics mode it has been
>> using (or any other one), via "set gfxpayload=keep" (or suitable
>> variants thereof). In this case we can avoid do
On 06.04.2022 16:14, Roger Pau Monné wrote:
> On Wed, Apr 06, 2022 at 02:40:50PM +0200, Jan Beulich wrote:
>> On 06.04.2022 11:34, Roger Pau Monné wrote:
>>> On Wed, Apr 06, 2022 at 10:44:12AM +0200, Jan Beulich wrote:
On 05.04.2022 17:47, Roger Pau Monné wrote:
> On Tue, Apr 05, 2022 at 0
On Wed, Apr 06, 2022 at 02:40:50PM +0200, Jan Beulich wrote:
> On 06.04.2022 11:34, Roger Pau Monné wrote:
> > On Wed, Apr 06, 2022 at 10:44:12AM +0200, Jan Beulich wrote:
> >> On 05.04.2022 17:47, Roger Pau Monné wrote:
> >>> On Tue, Apr 05, 2022 at 04:36:53PM +0200, Jan Beulich wrote:
> On 0
On 06.04.2022 15:36, Roger Pau Monné wrote:
> On Wed, Apr 06, 2022 at 02:24:32PM +0200, Jan Beulich wrote:
>> First there's a printk() which actually wrongly uses pdev in the first
>> place: We want to log the coordinates of the (perhaps fake) device
>> acted upon, which may not be pdev.
>>
>> Then
On Wed, Apr 06, 2022 at 02:25:13PM +0200, Jan Beulich wrote:
> Despite the comment there infinite recursion was still possible, by
> flip-flopping between two domains. This is because prev_dom is derived
> from the DID found in the context entry, which was already updated by
> the time error recove
On 01.04.2022 12:47, Jane Malalane wrote:
> Introduce a new per-domain creation x86 specific flag to
> select whether hardware assisted virtualization should be used for
> x{2}APIC.
>
> A per-domain option is added to xl in order to select the usage of
> x{2}APIC hardware assisted virtualization,
On Wed, Apr 06, 2022 at 02:24:32PM +0200, Jan Beulich wrote:
> First there's a printk() which actually wrongly uses pdev in the first
> place: We want to log the coordinates of the (perhaps fake) device
> acted upon, which may not be pdev.
>
> Then it was quite pointless for eb19326a328d ("VT-d: p
Hi Jan,
On 06/04/2022 14:32, Jan Beulich wrote:
Eliminate hard tabs. While there also cast to the intended type.
Signed-off-by: Jan Beulich
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
When onlining a new memory page in a guest the Xen balloon driver is
adding it to the ballooned pages instead making it available to be
used immediately. This is meant to enable to add a new upper memory
limit to a guest via hotplugging memory, without having to assign the
new memory in one go.
In
Eliminate hard tabs. While there also cast to the intended type.
Signed-off-by: Jan Beulich
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -856,15 +856,15 @@ static void __init efi_tables(void)
static EFI_GUID __initdata smbios3_guid = SMBIOS3_TABLE_GUID;
if ( mat
On Tue, Apr 5, 2022 at 9:31 PM Chuck Zmudzinski wrote:
> Correction (sorry for the confusion):
>
> I didn't know I needed to replace more than just a
> re-built i915.ko module to enable the patch
> for testing. When I updated the entire Debian kernel
> package including all the modules and the ker
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 wrote:
> > > > On Thu, Mar 31, 2022 at
On 01.04.2022 12:47, Jane Malalane wrote:
> Add XEN_SYSCTL_PHYSCAP_X86_ASSISTED_XAPIC and
> XEN_SYSCTL_PHYSCAP_X86_ASSISTED_X2APIC to report accelerated xAPIC and
> x2APIC, on x86 hardware. This is so that xAPIC and x2APIC virtualization
> can subsequently be enabled on a per-domain basis.
> No suc
flight 169184 xen-4.12-testing real [real]
flight 169197 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/169184/
http://logs.test-lab.xenproject.org/osstest/logs/169197/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
On 06.04.2022 12:38, Roger Pau Monné wrote:
> On Wed, Apr 06, 2022 at 10:13:41AM +0200, Jan Beulich wrote:
>> On 23.03.2022 09:54, Roger Pau Monné wrote:
>>> Hello,
>>>
>>> I was looking at implementing ACPI Cx and Px state uploading from
>>> FreeBSD dom0, as my main test box is considerably slower
On 06.04.2022 11:34, Roger Pau Monné wrote:
> On Wed, Apr 06, 2022 at 10:44:12AM +0200, Jan Beulich wrote:
>> On 05.04.2022 17:47, Roger Pau Monné wrote:
>>> On Tue, Apr 05, 2022 at 04:36:53PM +0200, Jan Beulich wrote:
On 05.04.2022 12:27, Roger Pau Monné wrote:
> On Thu, Mar 31, 2022 at 1
On Wed, Apr 6, 2022 at 3:07 AM Jan Beulich wrote:
>
> On 05.04.2022 19:17, Jason Andryuk wrote:
> > On Mon, Apr 4, 2022 at 11:34 AM Daniel P. Smith
> > wrote:
> >> On 3/31/22 09:16, Jason Andryuk wrote:
> >>> For the default policy, you could start by creating the system domains
> >>> as privile
Despite the comment there infinite recursion was still possible, by
flip-flopping between two domains. This is because prev_dom is derived
from the DID found in the context entry, which was already updated by
the time error recovery is invoked. Simply introduce yet another mode
flag to detect the s
First there's a printk() which actually wrongly uses pdev in the first
place: We want to log the coordinates of the (perhaps fake) device
acted upon, which may not be pdev.
Then it was quite pointless for eb19326a328d ("VT-d: prepare for per-
device quarantine page tables (part I)") to add a domid
1: avoid NULL deref on domain_context_mapping_one() error paths
2: avoid infinite recursion on domain_context_mapping_one() error path
Jan
1 - 100 of 128 matches
Mail list logo
