On 17.01.2022 18:23, Andrew Cooper wrote:
> On 17/01/2022 11:51, Jan Beulich wrote:
>> On 13.01.2022 17:38, Andrew Cooper wrote:
>>> @@ -119,12 +125,11 @@ UNLIKELY_END(realmode)
>>> SAVE_ALL
>>>
>>> /*
>>> - * PV variant needed here as no guest code has executed (so
>>>
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2022年1月18日 0:22
> To: Wei Chen
> Cc: Bertrand Marquis ; xen-
> de...@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org
> Subject: Re: [PATCH 19/37] xen/x86: promote VIRTUAL_BUG_ON to ASSERT in
>
> On 23.09.2021 14:02,
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2022年1月18日 0:11
> To: Wei Chen
> Cc: Bertrand Marquis ; xen-
> de...@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org
> Subject: Re: [PATCH 04/37] xen: introduce an arch helper for default dma
> zone status
>
> I
Pass the block_device and operation that we plan to use this bio for to
bio_alloc_bioset to optimize the assigment. NULL/0 can be passed, both
for the passthrough case on a raw request_queue and to temporarily avoid
refactoring some nasty code.
Also move the gfp_mask argument after the nr_vecs
Pass the block_device and operation that we plan to use this bio for to
bio_alloc_kiocb to optimize the assigment.
Signed-off-by: Christoph Hellwig
---
block/bio.c | 12
block/fops.c| 17 -
include/linux/bio.h | 4 ++--
3 files changed, 18
Pass the block_device that we plan to use this bio for and the
operation to bio_reset to optimize the assigment. A NULL block_device
can be passed, both for the passthrough case on a raw request_queue and
to temporarily avoid refactoring some nasty code.
Signed-off-by: Christoph Hellwig
---
Pass the block_device that we plan to use this bio for and the
operation to bio_init to optimize the assigment. A NULL block_device
can be passed, both for the passthrough case on a raw request_queue and
to temporarily avoid refactoring some nasty code.
Signed-off-by: Christoph Hellwig
---
Remove handling of NULL returns from sleeping bio_alloc calls given that
those can't fail.
Signed-off-by: Christoph Hellwig
---
drivers/block/xen-blkback/blkback.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/block/xen-blkback/blkback.c
All callers need to set the block_device and operation, so lift that into
the common code.
Signed-off-by: Christoph Hellwig
---
block/bio.c | 6 +-
block/blk-lib.c | 19 +--
block/blk-zoned.c | 9 +++--
block/blk.h | 2 --
Pass the block_device and operation that we plan to use this bio for to
bio_alloc to optimize the assigment. NULL/0 can be passed, both for the
passthrough case on a raw request_queue and to temporarily avoid
refactoring some nasty code.
Also move the gfp_mask argument after the nr_vecs argument
Keep blk_next_bio next to the core bio infrastructure.
Signed-off-by: Christoph Hellwig
---
block/bio.c | 13 +
block/blk-lib.c | 13 -
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/block/bio.c b/block/bio.c
index 0d400ba2dbd18..43fb28ac6b44e
The memory mapped in process_rdma is contiguous, so there is no need
to loop over bio_add_page. Remove rnbd_bio_map_kern and just open code
the bio allocation and mapping in the caller.
Signed-off-by: Christoph Hellwig
---
drivers/block/rnbd/rnbd-srv-dev.c | 57 ---
Only the priv field of rnbd_dev_blk_io is used, so store the value of
that in bio->bi_private directly and remove the entire bio_set overhead.
Signed-off-by: Christoph Hellwig
---
drivers/block/rnbd/rnbd-srv-dev.c | 4 +---
drivers/block/rnbd/rnbd-srv-dev.h | 13 ++---
Use blkdev_issue_flush, which uses an on-stack bio instead of an
opencoded version with a bio embedded into struct pool.
Signed-off-by: Christoph Hellwig
---
drivers/md/dm-thin.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/md/dm-thin.c
Remove handling of NULL returns from sleeping bio_alloc calls given that
those can't fail.
Signed-off-by: Christoph Hellwig
---
drivers/block/drbd/drbd_receiver.c | 21 -
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/drivers/block/drbd/drbd_receiver.c
Use blkdev_issue_flush, which uses an on-stack bio instead of an
opencoded version with a bio embedded into struct dm_snapshot.
Signed-off-by: Christoph Hellwig
---
drivers/md/dm-snap.c | 21 +
1 file changed, 1 insertion(+), 20 deletions(-)
diff --git
Just open code it next to the bio allocations, which saves a few lines
of code, prepares for future changes and allows to remove the duplicate
bi_opf assignment for the bio_clone_fast case in kcryptd_io_read.
Signed-off-by: Christoph Hellwig
---
drivers/md/dm-crypt.c | 21 -
bio_alloc will never fail if it is allowed to sleep, so there is no
need for this loop. Also remove the __GFP_HIGH specifier as it doesn't
make sense here given that we'll always fall back to the mempool anyway.
Signed-off-by: Christoph Hellwig
---
fs/ntfs3/fsntfs.c | 23
Remove handling of NULL returns from sleeping bio_alloc calls given that
those can't fail.
Signed-off-by: Christoph Hellwig
---
drivers/md/dm-crypt.c | 5 +
drivers/md/dm-log-writes.c | 18 --
drivers/md/dm-thin.c | 25 +
bio_alloc will never fail when it can sleep. Remove the now simple
nilfs_alloc_seg_bio helper and open code it in the only caller.
Signed-off-by: Christoph Hellwig
---
fs/nilfs2/segbuf.c | 31 ---
1 file changed, 4 insertions(+), 27 deletions(-)
diff --git
Hi Jens,
this series is posted early because it has wide-ranging changes and could use
some
early ACKs before -rc1.
It changes the interface to the bio allocators to always pass a block_device and
the operation, which is information needed for every bio submitted through
bio_submit. This means
open code mpage_alloc in it's two callers and simplify the results
because of the context:
- __mpage_writepage always passes GFP_NOFS and can thus always sleep and
will never get a NULL return from bio_alloc at all.
- do_mpage_readpage can only get a non-sleeping context for readahead
bio_alloc will never fail when it can sleep. Remove the now simple
bl_alloc_init_bio helper and open code it in the only caller.
Signed-off-by: Christoph Hellwig
---
fs/nfs/blocklayout/blocklayout.c | 26 +-
1 file changed, 5 insertions(+), 21 deletions(-)
diff --git
flight 167726 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167726/
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
flight 167730 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167730/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
-- Forwarded message -
From: George Dunlap
Date: Mon, Jan 17, 2022, 6:32 AM
Subject: Re: Reboot hangs on blank screen
To: The Person
Cc: community.mana...@xenproject.org
> On Nov 29, 2021, at 6:51 PM, The Person wrote:
>
> I am using Qubes 4.1rc1 and i have a dell 7520
flight 167729 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167729/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5801910013757bd626f67ed77eea6c16a176eebf
baseline version:
ovmf
flight 167725 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167725/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
flight 167727 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167727/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 59c48c9314111e41550cac7875c5e9235809c3ef
baseline version:
ovmf
flight 167722 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167722/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu broken
test-armhf-armhf-libvirt
hvm_{get,set}_guest_bndcfgs() are thin wrappers around accessing MSR_BNDCFGS.
MPX was implemented on Skylake uarch CPUs and dropped in subsequent CPUs, and
is disabled by default in Xen VMs.
It would be nice to move all the logic into vmx_msr_{read,write}_intercept(),
but the common HVM
In order to fix a VT-x bug, and support MSR_SPEC_CTRL on AMD, move
MSR_SPEC_CTRL handling into the new {get,set}_reg() infrastructure.
Duplicate the msrs->spec_ctrl.raw accesses in the PV and VT-x paths for now.
The SVM path is currently unreachable because of the CPUID policy.
No functional
The logic was based on a mistaken understanding of how NMI blocking on vmexit
works. NMIs are only blocked for EXIT_REASON_NMI, and not for general exits.
Therefore, an NMI can in general hit early in the vmx_asm_vmexit_handler path,
and the guest's value will be clobbered before it is saved.
v1 had an irritating breakage with VM migration, caused by the accessor logic
moving out of guest_{rd,wr}msr(). v2 takes an approach I'd previously put off
to one side, but which appears to be the least invasive way forward.
Andrew Cooper (4):
x86/guest: Introduce {get,set}_reg()
Various registers have per-guest-type or per-vendor locations or access
requirements. To support their use from common code, provide accessors which
allow for per-guest-type behaviour.
For now, just infrastructure handling default cases and expectations.
Subsequent patches will start handling
These were written before Spectre/Meltdown went public, and there was large
uncertainty in how the protections would evolve. As it turns out, they're
very specific to Intel hardware, and not very suitable for AMD.
Drop the macros, opencoding the relevant subset of functionality, and leaving
On 17/01/2022 11:51, Jan Beulich wrote:
> On 13.01.2022 17:38, Andrew Cooper wrote:
>> @@ -119,12 +125,11 @@ UNLIKELY_END(realmode)
>> SAVE_ALL
>>
>> /*
>> - * PV variant needed here as no guest code has executed (so
>> - * MSR_SPEC_CTRL can't have changed
flight 167724 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167724/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf 4
On 23.09.2021 14:02, Wei Chen wrote:
> VIRTUAL_BUG_ON that is using in phys_to_nid is an empty macro. This
> results in two lines of error-checking code in phys_to_nid are not
> actually working. It also covers up two compilation errors:
> 1. error: ‘MAX_NUMNODES’ undeclared (first use in this
I realize this series has been pending for a long time, but I don't
recall any indication that it would have been dropped. Hence as a
first try, a few comments on this relatively simple change. I'm
sorry it to have taken so long to get to it.
On 23.09.2021 14:02, Wei Chen wrote:
> In current
On Fri, Jan 14, 2022 at 11:22:00PM +, Dario Faggioli wrote:
> On Thu, 2022-01-13 at 12:05 +, Anthony PERARD wrote:
> > On Wed, Jan 12, 2022 at 05:41:36PM +0100, Dario Faggioli wrote:
> >
> > > 2) there should be nothing to free anyway
> >
> > The issue here is that it doesn't appear to
On 2022-01-17 12:32, Sergiy Kibrik wrote:
In IOMMU-capable system hypervisor usually takes over IOMMU control.
Generally guest domains don't need to care about IOMMU management and take any
extra actions. Yet in some cases a knowledge about which device is protected
may be useful for privileged
As of SDM revision 076 there is a CPUID bit for this functionality. Use
it to amend the existing model-based logic.
Signed-off-by: Jan Beulich
---
In xen-cpuid.c I wasn't sure whether it's better to put the 7b1 table
next to the 7a1 one, or whether tables should continue to be placed by
feature
Hi,
On 17/01/2022 10:40, Dongjiu Geng wrote:
It turns out that QEMU has been supporting GICv2 virtualization since
v3.1.0. So remove the dependencies on GICv3.
Technically, the current form of CONFIG_QEMU allows the same binary to
boot on QEMU with GICv2 or GICv3.
If we want to use
flight 167723 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167723/
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
Hi,
On 17/01/2022 15:13, Juergen Gross wrote:
On 17.01.22 12:05, George Dunlap wrote:
On Jan 14, 2022, at 9:01 PM, Stefano Stabellini
wrote:
On Fri, 14 Jan 2022, Dario Faggioli wrote:
On Thu, 2022-01-06 at 17:52 -0800, Stefano Stabellini wrote:
On Thu, 6 Jan 2022, Julien Grall wrote:
On Mon, Jan 17, 2022 at 11:34:20AM +0100, Jan Beulich wrote:
> It should have been that way right from its introduction by 02e0de011555
> ("x86: APIC timer calibration when running as a guest").
>
> Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
>
> --- a/xen/arch/x86/apic.c
> +++
On 17.01.2022 10:48, Roger Pau Monne wrote:
> Introduce an interface that returns a specific MSR entry from a cpu
> policy in xen_msr_entry_t format.
>
> This is useful to callers can peek data from the opaque
> xc_cpu_policy_t type.
>
> No caller of the interface introduced on this patch.
>
>
On 17.01.2022 10:48, Roger Pau Monne wrote:
> Introduce an interface that returns a specific leaf/subleaf from a cpu
> policy in xen_cpuid_leaf_t format.
>
> This is useful to callers can peek data from the opaque
> xc_cpu_policy_t type.
>
> No caller of the interface introduced on this patch.
>
On 14.01.2022 09:52, Anton Belousov wrote:
> SMBIOS tables like 7,8,9,26,27,28 are neccessary to prevent sandbox detection
> by malware
> using WMI-queries.
This is a statement without any proof. It may seem obvious to you, but
could you please make us properly see the value of your addition as
flight 167719 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167719/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw broken
Tests which are
On 17.01.2022 12:41, Andrew Cooper wrote:
> On 17/01/2022 11:22, Jan Beulich wrote:
>> On 13.01.2022 17:38, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/hvm/svm/entry.S
>>> +++ b/xen/arch/x86/hvm/svm/entry.S
>>> @@ -59,7 +59,7 @@ __UNLIKELY_END(nsvm_hap)
>>> mov
On 17.01.2022 12:24, Andrew Cooper wrote:
> On 17/01/2022 11:07, Jan Beulich wrote:
>> On 13.01.2022 17:38, Andrew Cooper wrote:
>>> In order to fix a VT-x bug, and support MSR_SPEC_CTRL on AMD, there will
>>> need
>>> to be three different access methods for where the guest's value lives.
>>>
On 13.01.2022 17:38, Andrew Cooper wrote:
> Second, update vmx_msr_{read,write}_intercept() to use the load/save lists
> rather than vcpu_msrs, and update the comment to describe the new state
> location.
Nit: Assuming "the comment" refers to something in the named function,
I'm afraid I can't
Bertrand Marquis 于2022年1月17日周一 19:38写道：
>
> Hi,
>
> > On 17 Jan 2022, at 11:12, Dongjiu Geng wrote:
> >
> > Bertrand Marquis 于2022年1月17日周一 17:00写道：
> >>
> >> Hi,
> >>
> >>> On 17 Jan 2022, at 06:40, Dongjiu Geng wrote:
> >>>
> >>> It turns out that QEMU has been supporting GICv2 virtualization
On 17/01/2022 09:21, Jan Beulich wrote:
> On 14.01.2022 15:41, Andrew Cooper wrote:
>> On 14/01/2022 14:14, Andrew Cooper wrote:
>>> On 13/01/2022 16:38, Andrew Cooper wrote:
The logic was based on a mistaken understanding of how NMI blocking on
vmexit
works. NMIs are only blocked
On 17/01/2022 11:22, Jan Beulich wrote:
> On 13.01.2022 17:38, Andrew Cooper wrote:
>> --- a/xen/arch/x86/hvm/svm/entry.S
>> +++ b/xen/arch/x86/hvm/svm/entry.S
>> @@ -59,7 +59,7 @@ __UNLIKELY_END(nsvm_hap)
>> mov VCPUMSR_spec_ctrl_raw(%rax), %eax
>>
>> /* WARNING! `ret`, `call
Hi,
> On 17 Jan 2022, at 11:12, Dongjiu Geng wrote:
>
> Bertrand Marquis 于2022年1月17日周一 17:00写道：
>>
>> Hi,
>>
>>> On 17 Jan 2022, at 06:40, Dongjiu Geng wrote:
>>>
>>> It turns out that QEMU has been supporting GICv2 virtualization since
>>> v3.1.0. So remove the dependencies on GICv3. If
On 17/01/2022 11:07, Jan Beulich wrote:
> On 13.01.2022 17:38, Andrew Cooper wrote:
>> In order to fix a VT-x bug, and support MSR_SPEC_CTRL on AMD, there will need
>> to be three different access methods for where the guest's value lives.
>> However, it would be better not to duplicate the #GP
On 13.01.2022 17:38, Andrew Cooper wrote:
> --- a/xen/arch/x86/hvm/svm/entry.S
> +++ b/xen/arch/x86/hvm/svm/entry.S
> @@ -59,7 +59,7 @@ __UNLIKELY_END(nsvm_hap)
> mov VCPUMSR_spec_ctrl_raw(%rax), %eax
>
> /* WARNING! `ret`, `call *`, `jmp *` not safe beyond this point. */
> -
On 17.01.22 12:05, George Dunlap wrote:
On Jan 14, 2022, at 9:01 PM, Stefano Stabellini wrote:
On Fri, 14 Jan 2022, Dario Faggioli wrote:
On Thu, 2022-01-06 at 17:52 -0800, Stefano Stabellini wrote:
On Thu, 6 Jan 2022, Julien Grall wrote:
This issue and solution were discussed numerous
Bertrand Marquis 于2022年1月17日周一 17:00写道：
>
> Hi,
>
> > On 17 Jan 2022, at 06:40, Dongjiu Geng wrote:
> >
> > It turns out that QEMU has been supporting GICv2 virtualization since
> > v3.1.0. So remove the dependencies on GICv3. If we want to use GICv3,
> > we can select the QEMU_LEGACY
On 13.01.2022 17:38, Andrew Cooper wrote:
> In order to fix a VT-x bug, and support MSR_SPEC_CTRL on AMD, there will need
> to be three different access methods for where the guest's value lives.
> However, it would be better not to duplicate the #GP checking logic.
>
> guest_{rd,wr}msr() are
> On Jan 14, 2022, at 9:01 PM, Stefano Stabellini
> wrote:
>
> On Fri, 14 Jan 2022, Dario Faggioli wrote:
>> On Thu, 2022-01-06 at 17:52 -0800, Stefano Stabellini wrote:
>>> On Thu, 6 Jan 2022, Julien Grall wrote:
This issue and solution were discussed numerous time on the ML. In
For one, "using_pit" shouldn't be set ahead of the function's last
(for now: only) error path. Otherwise "clocksource=pit" on the command
line can lead to misbehavior when actually taking that error path.
And then make an implicit assumption explicit: CALIBRATE_FRAC cannot,
for example, simply be
It should have been that way right from its introduction by 02e0de011555
("x86: APIC timer calibration when running as a guest").
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -1190,7 +1190,7 @@ static void __init check_deadline_errata
"please
Mercury and Neptune were Pentium chipsets - no need to work around their
errata, even more so that the workaround looks fragile.
Also ditch a Pentium-related and stale part of a comment.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -1042,11 +1042,6 @@
The only global effect of calibrate_APIC_clock() is the setting of
"bus_scale"; the final __setup_APIC_LVTT(0) is (at best) redundant with
the immediately following setup_APIC_timer() invocation. Yet "bus_scale"
isn't used when using TDT. Avoid wasting 100ms for calibration in this
case.
Hi,
> On 14 Jan 2022, at 17:07, Nick Rosbrook wrote:
>
> I am no longer an employee at AIS. Use my personal email address
> instead.
>
> Signed-off-by: Nick Rosbrook
Reviewed-by: Bertrand Marquis
Cheers
Bertrand
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> On Jan 14, 2022, at 5:07 PM, Nick Rosbrook wrote:
>
> I am no longer an employee at AIS. Use my personal email address
> instead.
>
> Signed-off-by: Nick Rosbrook
Reviewed-by: George Dunlap
Pull out the code from xc_cpuid_apply_policy that applies a featureset
to a cpu policy and place it on it's own standalone function that's
part of the public interface.
No functional change intended.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
tools/include/xenguest.h|
From: Jan Beulich
Zapping leaf data for out of range leaves is just one half of it: To
avoid guests (bogusly or worse) inferring information from mere leaf
presence, also shrink maximum indicators such that the respective
trailing entry is not all blank (unless of course it's the initial
subleaf
With the addition of the xc_cpu_policy_* now libxl can have better
control over the cpu policy, this allows removing the
xc_cpuid_apply_policy function and instead coding the required bits by
libxl in libxl__cpuid_legacy directly.
Remove xc_cpuid_apply_policy.
Signed-off-by: Roger Pau Monné
Move the logic from xc_cpu_policy_apply_cpuid into libxl, now that the
xc_cpu_policy_* helpers allow modifying a cpu policy. By moving such
parsing into libxl directly we can get rid of xc_xend_cpuid, as libxl
will now implement it's own private type for storing CPUID
information, which currently
Rename xc_cpuid_xend_policy to xc_cpu_policy_apply_cpuid and make it
public. Modify the function internally to use the new xc_cpu_policy_*
set of functions. Also don't apply the passed policy to a domain
directly, and instead modify the provided xc_cpu_policy_t. The caller
will be responsible of
This logic is pulled out from xc_cpuid_apply_policy and placed into a
separate helper. Note the legacy part of the introduced function, as
long term Xen will require a proper topology setter function capable
of expressing a more diverse set of topologies.
No functional change intended.
Older Xen versions used to expose some CPUID bits which are no longer
exposed by default. In order to keep a compatible behavior with
guests migrated from versions of Xen that don't encode the CPUID data
on the migration stream introduce a function that sets the same bits
as older Xen versions.
Introduce an interface that returns a specific MSR entry from a cpu
policy in xen_msr_entry_t format.
This is useful to callers can peek data from the opaque
xc_cpu_policy_t type.
No caller of the interface introduced on this patch.
Signed-off-by: Roger Pau Monné
---
Changes since v3:
- Use
Use such helper in order to replace the code in
x86_msr_copy_from_buffer. Note the introduced helper should not be
directly called and instead x86_msr_get_entry should be used that will
properly deal with const and non-const inputs.
Note this requires making the raw fields uint64_t so that it can
Introduce an interface that returns a specific leaf/subleaf from a cpu
policy in xen_cpuid_leaf_t format.
This is useful to callers can peek data from the opaque
xc_cpu_policy_t type.
No caller of the interface introduced on this patch.
Signed-off-by: Roger Pau Monné
---
Changes since v5:
-
Introduce a helper based on the current Xen guest_cpuid code in order
to fetch a cpuid leaf from a policy. The newly introduced function in
cpuid.c should not be directly called and instead the provided
x86_cpuid_get_leaf macro should be used that will properly deal with
const and non-const
Do this before adding any more stuff to xg_cpuid_x86.c.
The placement in xenctrl.h is wrong, as they are implemented by the
xenguest library. Note that xg_cpuid_x86.c needs to include
xg_private.h, and in turn also fix xg_private.h to include
xc_bitops.h. The bitops definition of BITS_PER_LONG
Hello,
The following series introduces a new CPUID/MSR interface for the
xenguest library. Such interface handles both CPUID and MSRs using the
same opaque object, and provides some helpers for the user to peek or
modify such data without exposing the backing type. This is useful for
future
On 14.01.2022 15:41, Andrew Cooper wrote:
> On 14/01/2022 14:14, Andrew Cooper wrote:
>> On 13/01/2022 16:38, Andrew Cooper wrote:
>>> The logic was based on a mistaken understanding of how NMI blocking on
>>> vmexit
>>> works. NMIs are only blocked for EXIT_REASON_NMI, and not for general
>>>
On 16.01.2022 13:56, Wei Liu wrote:
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
(In case such is needed at all for things like this.)
Thanks, Jan
Hi,
> On 17 Jan 2022, at 06:40, Dongjiu Geng wrote:
>
> It turns out that QEMU has been supporting GICv2 virtualization since
> v3.1.0. So remove the dependencies on GICv3. If we want to use GICv3,
> we can select the QEMU_LEGACY configuration.
I am bit puzzled by this change introducing a
flight 167721 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167721/
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-i386-libvirt
On 12.01.2022 12:32, Jan Beulich wrote:
> On 12.01.2022 11:53, Roger Pau Monné wrote:
>> On Wed, Jan 12, 2022 at 09:56:12AM +0100, Jan Beulich wrote:
>>> I'm afraid I don't see a way to deal with the same issue in init_pit().
>>> In particular the (multiple) specs I have to hand don't make clear
88 matches
Mail list logo
