On 21.02.2024 10:34, Julien Grall wrote:
> Hi,
>
> On 20/02/2024 12:25, Jan Beulich wrote:
>> On 20.02.2024 12:52, Julien Grall wrote:
>>> Hi Jan,
>>>
>>> On 20/02/2024 08:26, Jan Beulich wrote:
On 19.02.2024 23:22, Julien Grall wrote:
> Title: I would add 'gnttab:' to clarify which
On 21.02.2024 09:48, George Dunlap wrote:
> On Mon, Feb 19, 2024 at 11:22 PM Jan Beulich wrote:
>>
>> On 06.02.2024 02:20, George Dunlap wrote:
>>> For now, just disable the functionality entirely until we can
>>> implement it properly:
>>>
>>> - Don't set TSCRATEMSR in the host CPUID policy
>>
On 20.02.2024 21:30, Oleksii wrote:
> On Mon, 2024-02-19 at 13:18 +0100, Jan Beulich wrote:
>> On 19.02.2024 12:59, Oleksii wrote:
>>> Hi Julien,
>>>
>>> On Sun, 2024-02-18 at 18:30 +, Julien Grall wrote:
Hi Oleksii,
Title: Typo s/introdure/introduce/
On 05/02/2024
flight 184716 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184716/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184712
When re-working library call wrapping the sed invocation didn't account
for all sources living in the parent directory when building the 32-bit
harness binary.
Fixes: 6fba45ca3be1 ("x86emul: rework wrapping of libc functions in test and
fuzzing harnesses")
Signed-off-by: Jan Beulich
---
EVEX.R' is not ignored in 64-bit code when encoding a GPR or mask
register. While for mask registers suitable checks are in place (there
also covering EVEX.R), they were missing for the few cases where in
EVEX-encoded instructions ModR/M.reg encodes a GPR. While for VPEXTRW
the bit is replaced
On Wed, Feb 21, 2024 at 3:17 PM Jan Beulich wrote:
> > #1 by itself is probably enough to counterindicate this kind of
> > behavior. Add them together, and I'm inclined to say that we should
> > write a policy against such optimizations, without specific
> > justifications.
>
> It's not like I
Hi,
On 20/02/2024 12:25, Jan Beulich wrote:
On 20.02.2024 12:52, Julien Grall wrote:
Hi Jan,
On 20/02/2024 08:26, Jan Beulich wrote:
On 19.02.2024 23:22, Julien Grall wrote:
Title: I would add 'gnttab:' to clarify which subsystem you are modifying.
That's how I actually have it here; it's
On 21/02/2024 10:27 am, Jan Beulich wrote:
> When re-working library call wrapping the sed invocation didn't account
> for all sources living in the parent directory when building the 32-bit
> harness binary.
>
> Fixes: 6fba45ca3be1 ("x86emul: rework wrapping of libc functions in test and
>
On Mon, Feb 19, 2024 at 11:22 PM Jan Beulich wrote:
>
> On 06.02.2024 02:20, George Dunlap wrote:
> > For now, just disable the functionality entirely until we can
> > implement it properly:
> >
> > - Don't set TSCRATEMSR in the host CPUID policy
>
> This goes too far: This way you would (in
On 21/02/2024 13:20, Julien Grall wrote:
>
>
> On 21/02/2024 11:33, Ayan Kumar Halder wrote:
>> Hi Jan,
>>
>> On 21/02/2024 07:09, Jan Beulich wrote:
>>> On 20.02.2024 16:22, Ayan Kumar Halder wrote:
On 20/02/2024 12:33, Jan Beulich wrote:
> On 20.02.2024 13:17, Ayan Kumar Halder
On Wed, 2024-02-21 at 12:00 +0100, Jan Beulich wrote:
> On 20.02.2024 21:30, Oleksii wrote:
> > On Mon, 2024-02-19 at 13:18 +0100, Jan Beulich wrote:
> > > On 19.02.2024 12:59, Oleksii wrote:
> > > > Hi Julien,
> > > >
> > > > On Sun, 2024-02-18 at 18:30 +, Julien Grall wrote:
> > > > > Hi
flight 184719 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184719/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 184714
test-amd64-amd64-xl-qemuu-win7-amd64
On Mon, Feb 19, 2024 at 02:56:58PM +0100, Juergen Gross wrote:
> In xen-9pfsd fill_data() va_end() needs to be called before returning.
>
> Coverity Id CID 1592145
>
> Fixes: bcec59cf7ff4 ("tools/xen-9pfsd: add 9pfs version request support")
> Signed-off-by: Juergen Gross
Reviewed-by: Anthony
On 2024-02-20 09:14, Nicola Vetrini wrote:
On 2024-02-20 08:45, Jan Beulich wrote:
On 19.02.2024 16:14, Nicola Vetrini wrote:
The cache clearing and invalidation helpers in x86 and Arm didn't
comply with MISRA C Rule 17.7: "The value returned by a function
having non-void return type shall be
Hi Oleksii,
On 21/02/2024 12:47, Oleksii wrote:
On Wed, 2024-02-21 at 12:00 +0100, Jan Beulich wrote:
On 20.02.2024 21:30, Oleksii wrote:
On Mon, 2024-02-19 at 13:18 +0100, Jan Beulich wrote:
On 19.02.2024 12:59, Oleksii wrote:
Hi Julien,
On Sun, 2024-02-18 at 18:30 +, Julien Grall
Hi Jan,
On 21/02/2024 07:09, Jan Beulich wrote:
On 20.02.2024 16:22, Ayan Kumar Halder wrote:
On 20/02/2024 12:33, Jan Beulich wrote:
On 20.02.2024 13:17, Ayan Kumar Halder wrote:
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -101,6 +101,18 @@ Extension to the GICv3 interrupt controller to support
On 21/02/2024 11:33, Ayan Kumar Halder wrote:
Hi Jan,
On 21/02/2024 07:09, Jan Beulich wrote:
On 20.02.2024 16:22, Ayan Kumar Halder wrote:
On 20/02/2024 12:33, Jan Beulich wrote:
On 20.02.2024 13:17, Ayan Kumar Halder wrote:
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -101,6 +101,18 @@
On 21.02.2024 13:47, Oleksii wrote:
> As I understand it, evaluate_nospec()/block_speculation() were
> introduced for x86 to address the L1TF vulnerability specific to x86
> CPUs.
Well, if you look at one of the later commits altering x86'es variant,
you'll find that this wasn't really correct.
Currently xen-blkfront set the max discard limit to the capacity of
the device, which is suboptimal when the capacity changes. Just set
it to UINT_MAX, which has the same effect and is simpler.
Signed-off-by: Christoph Hellwig
Acked-by: Roger Pau Monné
---
drivers/block/xen-blkfront.c | 6
blkif_set_queue_limits already sets the max_sements limits, so don't do
it a second time. Also remove a comment about a long fixe bug in
blk_mq_update_nr_hw_queues.
Signed-off-by: Christoph Hellwig
Acked-by: Roger Pau Monné
---
drivers/block/xen-blkfront.c | 8 +++-
1 file changed, 3
The block layer now sets the discard granularity to the physical
block size default. Take advantage of that in xen-blkfront and only
set the discard granularity if explicitly specified.
Signed-off-by: Christoph Hellwig
Acked-by: Roger Pau Monné
---
drivers/block/xen-blkfront.c | 4 ++--
1
Hi all,
this series converts xen-blkfront to the new atomic queue limits update
API in the block tree. I don't have a Xen setup so this is compile
tested only.
Changes since v1:
- constify the info argument to blkif_set_queue_limits
- remove a spurious word from a commit message
Diffstat:
Pass the initial queue limits to blk_mq_alloc_disk and use the
blkif_set_queue_limits API to update the limits on reconnect.
Signed-off-by: Christoph Hellwig
Acked-by: Roger Pau Monné
---
drivers/block/xen-blkfront.c | 41
1 file changed, 23 insertions(+),
On Fri, Jan 12, 2024 at 02:13:17PM +0800, Jiqian Chen wrote:
> diff --git a/tools/libs/ctrl/xc_domain.c b/tools/libs/ctrl/xc_domain.c
> index f2d9d14b4d9f..448ba2c59ae1 100644
> --- a/tools/libs/ctrl/xc_domain.c
> +++ b/tools/libs/ctrl/xc_domain.c
> @@ -1394,6 +1394,21 @@ int
On Tue, Feb 20, 2024 at 01:20:16PM +0100, Jan Beulich wrote:
> On 20.02.2024 12:18, Anthony PERARD wrote:
> > On Tue, Feb 20, 2024 at 09:43:56AM +0100, Jan Beulich wrote:
> >> Because of using "-include", failure to (re)build auto.conf (with
> >> auto.conf.cmd produced as a secondary target) won't
Hi Jiqian,
On Fri, Jan 12, 2024 at 02:13:16PM +0800, Jiqian Chen wrote:
> In PVH dom0, it uses the linux local interrupt mechanism,
> when it allocs irq for a gsi, it is dynamic, and follow
> the principle of applying first, distributing first. And
> the irq number is alloced from small to large,
On 2024-02-21 13:08, Nicola Vetrini wrote:
On 2024-02-20 09:14, Nicola Vetrini wrote:
On 2024-02-20 08:45, Jan Beulich wrote:
On 19.02.2024 16:14, Nicola Vetrini wrote:
The cache clearing and invalidation helpers in x86 and Arm didn't
comply with MISRA C Rule 17.7: "The value returned by a
flight 184720 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184720/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail pass in
184716
Tests which did not
On Tue, Jan 09, 2024 at 12:16:31PM -0500, Jason Andryuk wrote:
> xl/libxl only applies vkb=[] to PV & PVH guests. HVM gets only a single
> vkb by default, but that can be disabled by the vkb_device boolean.
> Notably the HVM vkb cannot be configured, so feature-abs-pointer or the
> backend-type
On 21.02.2024 16:22, Anthony PERARD wrote:
> On Tue, Feb 20, 2024 at 01:20:16PM +0100, Jan Beulich wrote:
>> On 20.02.2024 12:18, Anthony PERARD wrote:
>>> On Tue, Feb 20, 2024 at 09:43:56AM +0100, Jan Beulich wrote:
Because of using "-include", failure to (re)build auto.conf (with
On 21/02/2024 10:27 am, Jan Beulich wrote:
> EVEX.R' is not ignored in 64-bit code when encoding a GPR or mask
> register. While for mask registers suitable checks are in place (there
> also covering EVEX.R), they were missing for the few cases where in
> EVEX-encoded instructions ModR/M.reg
On Wed, Dec 27, 2023 at 07:18:12PM -0500, Jason Andryuk wrote:
> On Tue, Dec 26, 2023 at 11:49 PM Marek Marczykowski-Górecki
> wrote:
> >
> > According to comments (and experiments) qemu-xen cannot handle memory
> > reolcation done by hvmloader. The code was already disabled when running
> >
The current code for alternative calls uses the caller parameter types as the
types for the register variables that serve as function parameters:
uint8_t foo;
[...]
alternative_call(myfunc, foo);
Would expand roughly into:
register unint8_t a1_ asm("rdi") = foo;
register unsigned long a2_
Hi George,
On 21/02/2024 02:55, George Dunlap wrote:
On Mon, Feb 19, 2024 at 6:38 PM Jan Beulich wrote:
On 19.02.2024 11:31, Roger Pau Monné wrote:
On Mon, Feb 19, 2024 at 06:01:54PM +0800, George Dunlap wrote:
One of the questions we had with respect to changing our release
practice (for
Hi Jan,
On 20/02/2024 08:55, Jan Beulich wrote:
They're simply not needed anymore.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Acked-by: Julien Grall
Cheers,
--
Julien Grall
flight 184721 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184721/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail REGR. vs. 184719
Tests which did
Hi Jan,
On 20/02/2024 08:52, Jan Beulich wrote:
In preparation of dropping the register parameters from
serial_[rt]x_interrupt() and in turn from IRQ handler functions,
register state needs making available another way for the few key
handlers which need it. Fake IRQ-like state.
Signed-off-by:
flight 184724 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184724/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8ccd63d14da5678a4b95df0aa954a2378355af9b
baseline version:
ovmf
Hi Anthony,
On 2024/2/21 21:38, Anthony PERARD wrote:
> Hi Jiqian,
>
> On Fri, Jan 12, 2024 at 02:13:16PM +0800, Jiqian Chen wrote:
>> In PVH dom0, it uses the linux local interrupt mechanism,
>> when it allocs irq for a gsi, it is dynamic, and follow
>> the principle of applying first,
Hi Stewart,
On 2024/2/10 02:02, Stewart Hildebrand wrote:
> On 1/12/24 01:13, Jiqian Chen wrote:
>> When a device has been reset on dom0 side, the vpci on Xen
>> side won't get notification, so the cached state in vpci is
>> all out of date compare with the real device state.
>> To solve that
Hi Anthony,
On 2024/2/21 23:03, Anthony PERARD wrote:
> On Fri, Jan 12, 2024 at 02:13:17PM +0800, Jiqian Chen wrote:
>> diff --git a/tools/libs/ctrl/xc_domain.c b/tools/libs/ctrl/xc_domain.c
>> index f2d9d14b4d9f..448ba2c59ae1 100644
>> --- a/tools/libs/ctrl/xc_domain.c
>> +++
42 matches
Mail list logo
