On 18.08.2022 18:34, Anthony PERARD wrote:
> On Thu, Aug 18, 2022 at 04:05:37PM +0200, Jan Beulich wrote:
>> @@ -242,13 +238,11 @@ static void dump_stats(void)
>> smt++;
>> }
>>
>> -printf("processed %d total records in %d seconds (%ld per second)\n",
>> - rec_count,
On 18.08.2022 19:42, Julien Grall wrote:
> On 16/08/2022 17:29, Jan Beulich wrote:
>> On 16.08.2022 17:43, Anthony PERARD wrote:
>>> On Tue, Aug 16, 2022 at 03:02:10PM +0200, Jan Beulich wrote:
On 16.08.2022 12:30, Anthony PERARD wrote:
> We can't have a source file with the same name
On 19.08.22 00:02, Stefano Stabellini wrote:
Hi all,
This small series introduces SPDX tags to Xen:
1) add a mention to SPDX in CODING_STYLE
2) add a LICENSES directory with licenses and SPDX tags
3) adds the SPDX single-line comment to arch/arm/*.c
Note that arch/arm/*.c is just a start.
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wolfram Sang
flight 172635 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172635/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 172626 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172626/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172123
flight 172623 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172623/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-libvirt-raw 17 guest-start/debian.repeatfail like 172548
flight 172633 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172633/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Subject: Re: [PATCH v3 0/5] x86/mwait-idle: (remaining) SPR + (new) ADL
> support
>
> Henry,
>
> On 18.08.2022 15:02, Jan Beulich wrote:
> > New changes have appeared in the meantime, in particular one partly
> undoing
> > what we
flight 172622 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172622/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172128
build-amd64-libvirt
flight 172631 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172631/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
Add SPDX license information to all the *.c files under arch/arm.
Signed-off-by: Stefano Stabellini
---
Changes in v2:
- use /* */
- actually check use the right license
- remove stale copyright info from top of the file header
---
xen/arch/arm/alternative.c| 13 +
Signed-off-by: Stefano Stabellini
---
CODING_STYLE | 10 ++
1 file changed, 10 insertions(+)
diff --git a/CODING_STYLE b/CODING_STYLE
index 3386ee1d90..5faf274b3a 100644
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -14,6 +14,16 @@ explicitly (e.g. tools/libxl/CODING_STYLE) but often
Hi all,
This small series introduces SPDX tags to Xen:
1) add a mention to SPDX in CODING_STYLE
2) add a LICENSES directory with licenses and SPDX tags
3) adds the SPDX single-line comment to arch/arm/*.c
Note that arch/arm/*.c is just a start. Also, to make the changes as
mechanical as
flight 172619 xen-unstable real [real]
flight 172630 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/172619/
http://logs.test-lab.xenproject.org/osstest/logs/172630/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
flight 172629 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172629/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
On 09.08.22 08:34, Viresh Kumar wrote:
Hello Viresh
This patch allocates Virtio MMIO params (IRQ and memory region) and pass
them to the backend, also update Guest device-tree based on Virtio GPIO
DT bindings [1].
[1]
On 09.08.22 08:34, Viresh Kumar wrote:
Hello Viresh
This patch allocates Virtio MMIO params (IRQ and memory region) and pass
them to the backend, also update Guest device-tree based on Virtio I2C
DT bindings [1].
Nit: Patch does more than it claims in the description, I am speaking
about
On 09.08.22 08:34, Viresh Kumar wrote:
Hello Viresh
make_virtio_mmio_node() creates the DT node for simple MMIO devices
currently, i.e. the ones that don't require any additional properties.
In order to allow using it for other complex device types, split the
functionality into two, one
flight 172627 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172627/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
build-amd64-libvirt 6
On 09.08.22 08:34, Viresh Kumar wrote:
Hello Viresh
> Create a separate routine to allocate base and irq for a device as the
> same code will be required for each device type.
>
> Suggested-by: Oleksandr Tyshchenko
> Signed-off-by: Viresh Kumar
> ---
> tools/libs/light/libxl_arm.c | 41
flight 172617 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172617/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-armhf-libvirt
On 8/16/22 1:28 PM, Chuck Zmudzinski wrote:
> On 8/16/2022 12:53 PM, Thorsten Leemhuis wrote:
>
> >
> > regzbot will notice when the patch hit's Linux next,
>
> IIUC, regzbot might not notice because the patch lacks a Link: tag
> to the original regression report. The Link tag is to Jan's patch
>
Hi Jan,
On 16/08/2022 17:29, Jan Beulich wrote:
On 16.08.2022 17:43, Anthony PERARD wrote:
On Tue, Aug 16, 2022 at 03:02:10PM +0200, Jan Beulich wrote:
On 16.08.2022 12:30, Anthony PERARD wrote:
We can't have a source file with the same name that exist in both the
common code and in the arch
Hi Bertrand,
On 18/08/2022 16:55, Bertrand Marquis wrote:
On 18 Aug 2022, at 15:31, Julien Grall wrote:
+/*
+ * void arm_smccc_1_2_smc(const struct arm_smccc_1_2_regs *args,
+ *struct arm_smccc_1_2_regs *res)
+ */
+ENTRY(arm_smccc_1_2_smc)
+/* Save `res` and free a
flight 172624 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172624/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 172610 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172610/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172133
On Thu, Aug 18, 2022 at 04:06:20PM +0200, Jan Beulich wrote:
> "int" is not a suitable type to hold time()'s return value.
>
> Coverity ID: 1509376
> Signed-off-by: Jan Beulich
Acked-by: Anthony PERARD
Thanks,
--
Anthony PERARD
On Thu, Aug 18, 2022 at 04:05:37PM +0200, Jan Beulich wrote:
> "int" is not a suitable type to convert time()'s return value to. Avoid
> casts and other extra fiddling by using difftime(), on the assumption
> that the overhead of using "double" doesn't matter here.
dump_stats() seems to be only
On Thu, 18 Aug 2022 at 17:49, Leo Yan wrote:
>
> On Thu, Aug 18, 2022 at 11:04:48AM +0100, Julien Grall wrote:
>
> [...]
>
> > > > Seems it's broken for kdump/kexec if kernel boots with using DT?
> > > >
> > >
> > > EFI supports both DT and ACPI boot, but only ACPI *requires* EFI.
> > >
> > > So
On Thu, Aug 18, 2022 at 04:07:16PM +0200, Jan Beulich wrote:
> "int" is not a suitable type to hold / receive "time_t" values.
>
> The parameter is presently unused, so no functional change.
>
> Coverity ID: 1509377
> Signed-off-by: Jan Beulich
Acked-by: Anthony PERARD
> ---
> An obvious
Hi Julien,
> On 18 Aug 2022, at 15:31, Julien Grall wrote:
>
> Hi Bertrand,
>
> On 18/08/2022 14:44, Bertrand Marquis wrote:
>>> On 18 Aug 2022, at 11:55, Jens Wiklander wrote:
>>>
>>> SMCCC v1.2 [1] AArch64 allows x0-x17 to be used as both parameter
>>> registers and result registers for
Hi Jan,
> On 18 Aug 2022, at 15:30, Jan Beulich wrote:
>
> On 12.07.2022 16:41, Bertrand Marquis wrote:
>> ...because there are some scripts in automation corresponding to the
>> entry (build-test.sh and build-each-commit.sh)
>>
>> Signed-off-by: Bertrand Marquis
>
> While it seems odd to
On Thu, Aug 18, 2022 at 11:04:48AM +0100, Julien Grall wrote:
[...]
> > > Seems it's broken for kdump/kexec if kernel boots with using DT?
> > >
> >
> > EFI supports both DT and ACPI boot, but only ACPI *requires* EFI.
> >
> > So DT boot on hardware with affected GICv3 implementations works
flight 172620 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172620/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl broken
Hello Jan,
> On 17 Aug 2022, at 4:18 pm, Jan Beulich wrote:
>
> On 17.08.2022 16:45, Rahul Singh wrote:
>> @@ -363,6 +373,42 @@ int __init pci_host_bridge_mappings(struct domain *d)
>> return 0;
>> }
>>
>> +static int is_bar_valid(const struct dt_device_node *dev,
>> +
On 18.08.2022 16:20, Juergen Gross wrote:
> On 18.08.22 16:07, Jan Beulich wrote:
>> "int" is not a suitable type to hold / receive "time_t" values.
>>
>> The parameter is presently unused, so no functional change.
>>
>> Coverity ID: 1509377
>> Signed-off-by: Jan Beulich
>
> Reviewed-by: Juergen
Hi Bertrand,
On 18/08/2022 14:44, Bertrand Marquis wrote:
On 18 Aug 2022, at 11:55, Jens Wiklander wrote:
SMCCC v1.2 [1] AArch64 allows x0-x17 to be used as both parameter
registers and result registers for the SMC and HVC instructions.
Arm Firmware Framework for Armv8-A specification makes
On 12.07.2022 16:41, Bertrand Marquis wrote:
> ...because there are some scripts in automation corresponding to the
> entry (build-test.sh and build-each-commit.sh)
>
> Signed-off-by: Bertrand Marquis
While it seems odd to have this simple a patch sit un-acked for this long,
it looks like I'm
flight 172612 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172612/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172123
On Thu, Aug 18, 2022 at 04:12:10PM +0200, Jan Beulich wrote:
> On 18.08.2022 16:04, Demi Marie Obenour wrote:
> > On Thu, Aug 18, 2022 at 09:02:11AM +0200, Jan Beulich wrote:
> >> On 17.08.2022 22:46, Demi Marie Obenour wrote:
> >>> --- a/tools/hotplug/Linux/block
> >>> +++
On 18.08.22 16:07, Jan Beulich wrote:
"int" is not a suitable type to hold / receive "time_t" values.
The parameter is presently unused, so no functional change.
Coverity ID: 1509377
Signed-off-by: Jan Beulich
Reviewed-by: Juergen Gross
The severity of this issue is rather low IMO. A
On 18.08.2022 16:04, Demi Marie Obenour wrote:
> On Thu, Aug 18, 2022 at 09:02:11AM +0200, Jan Beulich wrote:
>> On 17.08.2022 22:46, Demi Marie Obenour wrote:
>>> --- a/tools/hotplug/Linux/block
>>> +++ b/tools/hotplug/Linux/block
>>> @@ -330,7 +330,7 @@ mount it read-write in a guest domain."
Hi,
> On 17 Aug 2022, at 10:14, Julien Grall wrote:
>
> Hi Jan,
>
> On 17/08/2022 09:37, Jan Beulich wrote:
>> On 16.08.2022 20:59, Julien Grall wrote:
>>> --- a/xen/arch/arm/setup.c
>>> +++ b/xen/arch/arm/setup.c
>>> @@ -75,10 +75,24 @@ domid_t __read_mostly max_init_domid;
>>>static
"int" is not a suitable type to hold / receive "time_t" values.
The parameter is presently unused, so no functional change.
Coverity ID: 1509377
Signed-off-by: Jan Beulich
---
An obvious alternative would be to drop the parameter for being unused,
but I assume there were plans to use it in some
Hi Julien,
> On 16 Aug 2022, at 19:59, Julien Grall wrote:
>
> From: Julien Grall
>
> __ro_after_init was introduced recently to prevent modifying
> some variables after init.
>
> At the moment, on Arm, the variables will still be accessible
> because the region permission is not updated.
>
"int" is not a suitable type to hold time()'s return value.
Coverity ID: 1509376
Signed-off-by: Jan Beulich
---
I was on the edge of switching to using difftime() at this occasion as
well. This would then also allow switching "seconds" to unsigned int (or
any other suitable unsigned type).
---
"int" is not a suitable type to convert time()'s return value to. Avoid
casts and other extra fiddling by using difftime(), on the assumption
that the overhead of using "double" doesn't matter here.
Coverity ID: 1509374
Signed-off-by: Jan Beulich
--- unstable.orig/tools/xenmon/xenbaked.c
On Thu, Aug 18, 2022 at 09:02:11AM +0200, Jan Beulich wrote:
> On 17.08.2022 22:46, Demi Marie Obenour wrote:
> > This is a huge performance improvement for two reasons:
> >
> > 1. It uses the filesystem’s asynchronous I/O support, rather than using
> >synchronous I/O.
> > 2. It bypasses the
Three of the four reported issues a pretty clear how to take care
of, which is done in this series. The 4th, CID 1509375, isn't as
obvious, mainly because I don't know enough about Coverity to be
able to tell whether adding a cast there might help; the issue
reported for xenbaked suggests it
Hi Jens,
> On 18 Aug 2022, at 11:55, Jens Wiklander wrote:
>
> SMCCC v1.2 [1] AArch64 allows x0-x17 to be used as both parameter
> registers and result registers for the SMC and HVC instructions.
>
> Arm Firmware Framework for Armv8-A specification makes use of x0-x7 as
> parameter and result
Hi Julien,
> On 18 Aug 2022, at 08:57, Julien Grall wrote:
>
> Hi Leo,
>
> On 18/08/2022 08:34, Leo Yan wrote:
>> On Wed, Aug 17, 2022 at 03:17:53PM +0200, Jan Beulich wrote:
>>> Furthermore - what if Linux decided to change their structure? Or
>>> is there a guarantee that they won't?
From: Artem Bityutskiy
This patch partially reverts the changes made by the following commit:
da0e58c038e6 intel_idle: add 'preferred_cstates' module argument
As that commit describes, on early Sapphire Rapids Xeon platforms the C1 and
C1E states were mutually exclusive, so that users could
Henry,
On 18.08.2022 15:02, Jan Beulich wrote:
> New changes have appeared in the meantime, in particular one partly undoing
> what we still haven't merged (patch 1 here).
>
> 1: add 'preferred_cstates' module argument
> 2: add core C6 optimization for SPR
> 3: add AlderLake support
> 4: disable
From: Peter Zijlstra
Having IBRS enabled while the SMT sibling is idle unnecessarily slows
down the running sibling. OTOH, disabling IBRS around idle takes two
MSR writes, which will increase the idle latency.
Therefore, only disable IBRS around deeper idle states. Shallow idle
states are
From: Zhang Rui
Similar to SPR, the C1 and C1E states on ADL are mutually exclusive.
Only one of them can be enabled at a time.
But contrast to SPR, which usually has a strong latency requirement
as a Xeon processor, C1E is preferred on ADL for better energy
efficiency.
Add custom C-state
From: Artem Bityutskiy
Add a Sapphire Rapids Xeon C6 optimization, similar to what we have for Sky Lake
Xeon: if package C6 is disabled, adjust C6 exit latency and target residency to
match core C6 values, instead of using the default package C6 values.
Signed-off-by: Artem Bityutskiy
From: Artem Bityutskiy
On Sapphire Rapids Xeon (SPR) the C1 and C1E states are basically mutually
exclusive - only one of them can be enabled. By default, 'intel_idle' driver
enables C1 and disables C1E. However, some users prefer to use C1E instead of
C1, because it saves more energy.
This
New changes have appeared in the meantime, in particular one partly undoing
what we still haven't merged (patch 1 here).
1: add 'preferred_cstates' module argument
2: add core C6 optimization for SPR
3: add AlderLake support
4: disable IBRS during long idle
5: make SPR C1 and C1E be independent
flight 172621 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172621/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
Adds support for a guest to share memory with an SP using FFA_MEM_SHARE,
FFA_MEM_RECLAIM and FFA_MEM_FRAG_TX. Small memory regions can be shared
using FFA_MEM_SHARE, but larger memory regions may need to be
transmitted in fragments with FFA_MEM_FRAG_TX. A memory region that
doesn't need to be
Adds support in the mediator to map and unmap the RX and TX buffers
provided by the guest using the two FF-A functions FFA_RXTX_MAP and
FFA_RXTX_UNMAP.
These buffer are later used to to transmit data that cannot be passed in
registers only.
Signed-off-by: Jens Wiklander
---
xen/arch/arm/ffa.c
Adds support in the mediator to handle FFA_PARTITION_INFO_GET requests
from a guest. The requests are forwarded to the SPMC and the response is
translated according to the FF-A version in use by the guest.
Using FFA_PARTITION_INFO_GET changes the owner of the RX buffer to the
caller (the guest in
Adds support for sending a FF-A direct request.
[1] https://developer.arm.com/documentation/den0077/latest
Signed-off-by: Jens Wiklander
---
xen/arch/arm/ffa.c | 119 +
1 file changed, 119 insertions(+)
diff --git a/xen/arch/arm/ffa.c
Adds a FF-A version 1.1 [1] mediator to communicate with a Secure
Partition in secure world.
This commit brings in only the parts needed to negotiate FF-A version
number with guest and SPMC.
A guest configuration variable "ffa_enabled" is used to indicate if a guest
is trusted to use FF-A.
This
When initializing the FF-A mediator map the RX and TX buffers shared with
the SPMC.
These buffer are later used to to transmit data that cannot be passed in
registers only.
Signed-off-by: Jens Wiklander
---
xen/arch/arm/ffa.c | 57 +-
1 file changed,
SMCCC v1.2 [1] AArch64 allows x0-x17 to be used as both parameter
registers and result registers for the SMC and HVC instructions.
Arm Firmware Framework for Armv8-A specification makes use of x0-x7 as
parameter and result registers.
Let us add new interface to support this extended set of
Moves the two helper functions regpair_to_uint64() and
uint64_to_regpair() from xen/arch/arm/tee/optee.c to the common arm
specific regs.h.
Signed-off-by: Jens Wiklander
---
xen/arch/arm/include/asm/regs.h | 12
xen/arch/arm/tee/optee.c| 11 ---
2 files changed, 12
Hi,
This patch sets add a FF-A [1] mediator modeled after the TEE mediator
already present in Xen. The FF-A mediator implements the subset of the FF-A
1.1 specification needed to communicate with OP-TEE using FF-A as transport
mechanism instead of SMC/HVC as with the TEE mediator. It allows a
The FF-A specification defines framework messages sent as direct
requests when certain events occurs. For instance when a VM (guest) is
created or destroyed. Only SPs which have subscribed to these events
will receive them. An SP can subscribe to these messages in its
partition properties.
The
flight 172608 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172608/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172128
build-amd64-libvirt
Hi Ard,
On 18/08/2022 10:33, Ard Biesheuvel wrote:
On Thu, 18 Aug 2022 at 11:15, Leo Yan wrote:
Hi Ard,
On Wed, Aug 17, 2022 at 03:49:32PM +0200, Ard Biesheuvel wrote:
[...]
This header holds ACPI spec defined data structures. This one looks
to be a Linux one, and hence shouldn't be
On Thu, 18 Aug 2022 10:15:30 +0100,
Leo Yan wrote:
>
> Hi Ard,
>
> On Wed, Aug 17, 2022 at 03:49:32PM +0200, Ard Biesheuvel wrote:
>
> [...]
>
> > > This header holds ACPI spec defined data structures. This one looks
> > > to be a Linux one, and hence shouldn't be defined here. You use it
> >
On Thu, 18 Aug 2022 at 11:15, Leo Yan wrote:
>
> Hi Ard,
>
> On Wed, Aug 17, 2022 at 03:49:32PM +0200, Ard Biesheuvel wrote:
>
> [...]
>
> > > This header holds ACPI spec defined data structures. This one looks
> > > to be a Linux one, and hence shouldn't be defined here. You use it
> > > in a
Hi Juergen,
Attached the qemu-dm-VM3.log .
No errors are reported here.
With 64GB drive in DomU, both "lsusb" and "lsblk" commands lists the USB
drive but dmesg shows I/O error.
Thanks
Sudheer
On Thu, Aug 18, 2022 at 12:02 PM Juergen Gross wrote:
> [removing xen-users to avoid
Hi Ard,
On Wed, Aug 17, 2022 at 03:49:32PM +0200, Ard Biesheuvel wrote:
[...]
> > This header holds ACPI spec defined data structures. This one looks
> > to be a Linux one, and hence shouldn't be defined here. You use it
> > in a single CU only, so I see no reason to define it there.
> >
> >
flight 172618 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172618/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
On 18.08.2022 10:46, Leo Yan wrote:
> On Thu, Aug 18, 2022 at 09:47:46AM +0200, Jan Beulich wrote:
>> On 18.08.2022 09:34, Leo Yan wrote:
>>> On Wed, Aug 17, 2022 at 03:17:53PM +0200, Jan Beulich wrote:
Furthermore - what if Linux decided to change their structure? Or
is there a
Hi Jan,
On Thu, Aug 18, 2022 at 09:47:46AM +0200, Jan Beulich wrote:
> On 18.08.2022 09:34, Leo Yan wrote:
> > On Wed, Aug 17, 2022 at 03:17:53PM +0200, Jan Beulich wrote:
> >> Furthermore - what if Linux decided to change their structure? Or
> >> is there a guarantee that they won't? Generally
Hi Julien,
On Thu, Aug 18, 2022 at 08:57:20AM +0100, Julien Grall wrote:
> Hi Leo,
>
> On 18/08/2022 08:34, Leo Yan wrote:
> > On Wed, Aug 17, 2022 at 03:17:53PM +0200, Jan Beulich wrote:
> > > Furthermore - what if Linux decided to change their structure? Or
> > > is there a guarantee that they
Hi Leo,
On 18/08/2022 08:34, Leo Yan wrote:
On Wed, Aug 17, 2022 at 03:17:53PM +0200, Jan Beulich wrote:
Furthermore - what if Linux decided to change their structure? Or
is there a guarantee that they won't? Generally such structures
belong in the public interface, guaranteeing forward
On 18.08.2022 09:34, Leo Yan wrote:
> On Wed, Aug 17, 2022 at 03:17:53PM +0200, Jan Beulich wrote:
>> Furthermore - what if Linux decided to change their structure? Or
>> is there a guarantee that they won't? Generally such structures
>> belong in the public interface, guaranteeing forward
On Wed, Aug 17, 2022 at 03:17:53PM +0200, Jan Beulich wrote:
[...]
> Please make sure you Cc all maintainers of all files that you touch.
> Albeit, see below, you could indeed have avoided Cc-ing me if you
> hadn't misplaced stuff in two of the headers that you fiddle with.
Sorry for this.
On 17.08.2022 22:46, Demi Marie Obenour wrote:
> This is a huge performance improvement for two reasons:
>
> 1. It uses the filesystem’s asynchronous I/O support, rather than using
>synchronous I/O.
> 2. It bypasses the page cache, removing a redundant layer of caching and
>associated
flight 172604 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172604/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
test-amd64-i386-libvirt-raw 1
[removing xen-users to avoid crossposting]
On 18.08.22 08:18, A Sudheer wrote:
Hi All
On XEN-4.16 with Ubuntu 22.04 Dom0 and HVM-DomU, I tried to do a USB mass
storage device passthrough to DomU.
I followed the PVUSB method mentioned in
https://wiki.xenproject.org/wiki/Xen_USB_Passthrough
Hi All
On XEN-4.16 with Ubuntu 22.04 Dom0 and HVM-DomU, I tried to do a USB mass
storage device passthrough to DomU.
I followed the PVUSB method mentioned in
https://wiki.xenproject.org/wiki/Xen_USB_Passthrough.
With 8GB sandisk pen drive, i am able to do USB passthrough to DomU.
But with 64GB
87 matches
Mail list logo
