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
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
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
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
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
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
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.
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.
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
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 ++
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
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.
>
>
> 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
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
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):
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
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
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 ++---
>
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
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
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.
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
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
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):
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
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
>>>
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
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
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.
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
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
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, ) >= 0;
> }
>
> +int
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
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
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
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
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
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
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
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
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
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.
>>
>>
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
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:
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.
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 (
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
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
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
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
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
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
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
1: avoid NULL deref on domain_context_mapping_one() error paths
2: avoid infinite recursion on domain_context_mapping_one() error path
Jan
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 without Xen
> > knowing about the Px states.
On 02.04.2022 01:14, Demi Marie Obenour wrote:
> The EFI System Resource Table (ESRT) is necessary for fwupd to identify
> firmware updates to install. According to the UEFI specification §23.4,
> the table shall be stored in memory of type EfiBootServicesData.
> Therefore, Xen must avoid reusing
On Wed, Apr 6, 2022 at 8:07 AM 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.
Looks good,
Reviewed-by: Johannes Thumshirn
flight 169187 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169187/
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 06, 2022 at 11:16:10AM +0200, Jan Beulich wrote:
> On 06.04.2022 11:09, Roger Pau Monné wrote:
> > On Wed, Apr 06, 2022 at 10:48:23AM +0200, Jan Beulich wrote:
> >> On 06.04.2022 10:46, Roger Pau Monné wrote:
> >>> On Wed, Apr 06, 2022 at 09:06:59AM +0200, Jan Beulich wrote:
> On
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 11:45:36AM +0200, Jan Beulich wrote:
> ---
flight 169181 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169181/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169166
test-amd64-amd64-qemuu-nested-amd
On 4/6/22 15:05, Christoph Hellwig wrote:
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.
Signed-off-by: Christoph Hellwig
---
drivers/nvme/target/zns.c | 3 +--
On 06.04.2022 11:09, Roger Pau Monné wrote:
> On Wed, Apr 06, 2022 at 10:48:23AM +0200, Jan Beulich wrote:
>> On 06.04.2022 10:46, Roger Pau Monné wrote:
>>> On Wed, Apr 06, 2022 at 09:06:59AM +0200, Jan Beulich wrote:
On 05.04.2022 19:17, Jason Andryuk wrote:
> On Mon, Apr 4, 2022 at
On Wed, Apr 06, 2022 at 10:48:23AM +0200, Jan Beulich wrote:
> On 06.04.2022 10:46, Roger Pau Monné wrote:
> > On Wed, Apr 06, 2022 at 09:06:59AM +0200, 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
Hello,
The QEMU Documentation suggests to use memory-backend-memfd to share the
memory with external processes, so I add the following patch to
libxl__build_device_model_args_new() @ tools/libs/light/libxl_dm.c
*+ flexarray_append_pair(dm_args, "-object",
1 - 100 of 145 matches
Mail list logo
