flight 166105 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166105/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f826b20811ba6b0a9dbe44ff703b85c2def267df
baseline version:
ovmf aab6bb3d32e207c893645
Before, user would change turbo status but this had no effect: boolean
was set but policy wasn't reevaluated. Policy must be reevaluated so
that CPU frequency is chosen according to the turbo status and the
current governor.
Therefore, add __cpufreq_governor() in cpufreq_update_turbo().
Reported
flight 166107 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166107/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 9d9cd0c6f5b16652f61e7f21233ec8dfd6cf7df2
baseline version:
xen 9bc9
On Mon, Nov 08, 2021 at 02:36:42PM +0300, Dmitry Osipenko wrote:
> 08.11.2021 14:22, Jonathan Neuschäfer пишет:
> > On Sun, Nov 07, 2021 at 08:42:33PM +0300, Dmitry Osipenko wrote:
> > [...]
> >> EC drivers tend to use higher priority in general. Jonathan, could you
> >> please confirm that NTXEC d
On Mon, Nov 08, 2021 at 11:28:46AM +0100, Thomas Zimmermann wrote:
> The hook gem_prime_mmap in struct drm_driver is deprecated. Document
> the new requirements.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> Documentation/gpu/todo.rst | 11 ---
> include/drm/
On 11/4/21 15:18, Sean Christopherson wrote:
If I'm interpeting Paolo's suggestion
correctly, he's pointing out that oustanding stores to the function pointers in
@cbs need to complete before assigning a non-NULL pointer to perf_guest_cbs,
otherwise a perf event handler may see a valid pointer wi
Julien Grall writes ("Re: [PATCH for-4.16] xen/arm: allocate_bank_memory: don't
create memory banks of size zero"):
> Instead, it looks like the issue is some part of Xen may fall over if
> one of the bank is zero-sized. But from the earlier discussion [2], this
> is just latent. So I think this
Jane Malalane writes ("[PATCH] xen/cpufreq: Reset policy after
enabling/disabling turbo status"):
> Before, user would change turbo status but this had no effect: boolean
> was set but policy wasn't reevaluated. Policy must be reevaluated so
> that CPU frequency is chosen according to the turbo s
From: Lai Jiangshan
While in the native case, PER_CPU_VAR(cpu_tss_rw + TSS_sp0) is the
trampoline stack. But XEN pv doesn't use trampoline stack, so
PER_CPU_VAR(cpu_tss_rw + TSS_sp0) is also the kernel stack. Hence source
and destination stacks are identical in that case, which means reusing
sw
On Wed, Nov 10, 2021 at 09:19:35AM +, Jane Malalane wrote:
> Before, user would change turbo status but this had no effect: boolean
> was set but policy wasn't reevaluated. Policy must be reevaluated so
> that CPU frequency is chosen according to the turbo status and the
> current governor.
>
Hi
Am 10.11.21 um 11:46 schrieb Daniel Vetter:
On Mon, Nov 08, 2021 at 11:28:46AM +0100, Thomas Zimmermann wrote:
The hook gem_prime_mmap in struct drm_driver is deprecated. Document
the new requirements.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Thanks a lot!
With the
> On 9 Nov 2021, at 21:52, Stefano Stabellini wrote:
>
> On Tue, 9 Nov 2021, Jan Beulich wrote:
>> On 09.11.2021 03:11, Stefano Stabellini wrote:
>>> On Mon, 8 Nov 2021, Jan Beulich wrote:
On 05.11.2021 16:33, Stefano Stabellini wrote:
> My main concern is performance and resource uti
On 11/9/21 15:53, Thomas Gleixner wrote:
> On Thu, Nov 04 2021 at 00:27, Thomas Gleixner wrote:
>>
>> -if (!entry->msi_attrib.is_virtual) {
>> +if (!entry->msi_attrib.can_mask) {
> Groan. I'm a moron. This obviously needs to be
>
> if (entry->msi_attrib.can_m
Hi Luca,
On 10/11/2021 13:05, Luca Fancellu wrote:
I thought having the EFI_FILE_HANDLE global in efi-boot.h was a “no go”, but if
it’s not then instead of
calling get_parent_handle in efi_check_dt_boot (that is the main issue with
EDK2+Grub2), we can do
something like this:
fs_dir_handle is
10.11.2021 13:43, Jonathan Neuschäfer пишет:
> On Mon, Nov 08, 2021 at 02:36:42PM +0300, Dmitry Osipenko wrote:
>> 08.11.2021 14:22, Jonathan Neuschäfer пишет:
>>> On Sun, Nov 07, 2021 at 08:42:33PM +0300, Dmitry Osipenko wrote:
>>> [...]
EC drivers tend to use higher priority in general. Jona
Hi Stefano,
On 09/11/2021 23:18, Stefano Stabellini wrote:
From: Stefano Stabellini
DomUs static-mem ranges are added to the reserved_mem array for
accounting, but they shouldn't be assigned to dom0 as the other regular
reserved-memory ranges in device tree.
In make_memory_nodes, fix the erro
> On 10 Nov 2021, at 13:36, Julien Grall wrote:
>
> Hi Luca,
>
> On 10/11/2021 13:05, Luca Fancellu wrote:
>> I thought having the EFI_FILE_HANDLE global in efi-boot.h was a “no go”, but
>> if it’s not then instead of
>> calling get_parent_handle in efi_check_dt_boot (that is the main issue
flight 166103 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166103/
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-arm64-libvirt
flight 166108 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166108/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8c8867c5da8e059ab98a6108f8182700f298c6f5
baseline version:
ovmf f826b20811ba6b0a9dbe4
flight 166100 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166100/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel 14 guest-start fail REGR. vs. 165976
test-amd64-amd64-xl
flight 166101 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166101/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail like 166098
test-amd64-amd64-xl-qemuu-win7-amd6
On 11/10/21 14:31, Josef Johansson wrote:
> On 11/9/21 15:53, Thomas Gleixner wrote:
>> On Thu, Nov 04 2021 at 00:27, Thomas Gleixner wrote:
>>>
>>> - if (!entry->msi_attrib.is_virtual) {
>>> + if (!entry->msi_attrib.can_mask) {
>> Groan. I'm a moron. This obviously needs to b
CPUID policies from guest being migrated shouldn't have the maximum
leaves shrink, as that would be a guest visible change. The hypervisor
has no knowledge on whether a guest has been migrated or is build from
scratch, and hence it must not blindly shrink the CPUID policy in
recalculate_cpuid_polic
On 10/11/2021 17:40, Roger Pau Monne wrote:
> diff --git a/tools/libs/guest/xg_cpuid_x86.c b/tools/libs/guest/xg_cpuid_x86.c
> index 198892ebdf..3ffd5f683b 100644
> --- a/tools/libs/guest/xg_cpuid_x86.c
> +++ b/tools/libs/guest/xg_cpuid_x86.c
> @@ -638,6 +638,13 @@ int xc_cpuid_apply_policy(xc_inte
Roger Pau Monne writes ("[PATCH for-4.16] x86/cpuid: prevent shrinking migrated
policies max leaves"):
> CPUID policies from guest being migrated shouldn't have the maximum
> leaves shrink, as that would be a guest visible change. The hypervisor
> has no knowledge on whether a guest has been migra
The pull request you sent on Tue, 9 Nov 2021 15:28:19 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-5.16b-rc1-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/bf98ecbbae3edf3bb3ec254c3e318aa3f75fd15e
Thank you!
--
Deet-doot-dot,
From: Stefano Stabellini
DomUs static-mem ranges are added to the reserved_mem array for
accounting, but they shouldn't be assigned to dom0 as the other regular
reserved-memory ranges in device tree.
In make_memory_nodes, fix the error by skipping banks with xen_domain
set to true in the reserve
On 28.10.21 04:40, Stefano Stabellini wrote:
Hi Stefano
I am sorry for the late response.
On Tue, 26 Oct 2021, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch implements arch_xen_unpopulated_init() on Arm where
the extended regions (if any) are gathered from DT and inser
On 11/4/21 00:45, Thomas Gleixner wrote:
> On Wed, Oct 27 2021 at 17:29, Josef Johansson wrote:
>
> CC+: EFIFB and scheduler folks
>
>> On 10/27/21 14:01, Josef Johansson wrote:
>>
>> printk: Suspending console(s) (use no_console_suspend to debug)
>> [drm] free PSP TMR buffer
>> PM: suspend devices
flight 166106 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166106/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-libvirt-vhd 16 guest-saverestore fail in 166099 pass in 166106
test-amd64-amd64-examine4 m
From: Stefano Stabellini
allocate_bank_memory can be called with a tot_size of zero, as an
example see the implementation of allocate_memory which can call
allocate_bank_memory with a tot_size of zero for the second memory bank.
If tot_size == 0, don't create an empty memory bank, just return
im
On Mon, 8 Nov 2021, Julien Grall wrote:
> Hi Roman,
>
> On 04/10/2021 10:54, Roman Skakun wrote:
> > From: Roman Skakun
> >
> > Xen is not exposing any IOMMU properties to Dom0.
> > So Dom0 assumes that all it's devices are not protected by IOMMU.
> >
> > To make Dom0 aware of IOMMU-protected d
On 10.11.21 22:55, Stefano Stabellini wrote:
Hi Stefano
From: Stefano Stabellini
allocate_bank_memory can be called with a tot_size of zero, as an
example see the implementation of allocate_memory which can call
allocate_bank_memory with a tot_size of zero for the second memory bank.
If to
On 11/3/21 00:36, Boris Ostrovsky wrote:
> Commit 66558b730f25 ("sched: Add cluster scheduler level for x86")
> introduced cpu_l2c_shared_map mask which is expected to be initialized
> by smp_op.smp_prepare_cpus(). That commit only updated
> native_smp_prepare_cpus() version but not xen_pv_smp_prep
On 28.10.21 04:28, Stefano Stabellini wrote:
Hi Stefano
I am sorry for the late response.
On Tue, 26 Oct 2021, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Read the start address of the grant table space from DT
(region 0).
This patch mostly restores behaviour before commit 3cf
On 11/10/21 21:30, Josef Johansson wrote:
> On 11/4/21 00:45, Thomas Gleixner wrote:
>> On Wed, Oct 27 2021 at 17:29, Josef Johansson wrote:
>>
>> CC+: EFIFB and scheduler folks
>>
>>> On 10/27/21 14:01, Josef Johansson wrote:
>>>
>>> printk: Suspending console(s) (use no_console_suspend to debug)
On Wed, Nov 10, 2021, Paolo Bonzini wrote:
> On 11/4/21 15:18, Sean Christopherson wrote:
> > If I'm interpeting Paolo's suggestion
> > correctly, he's pointing out that oustanding stores to the function
> > pointers in
> > @cbs need to complete before assigning a non-NULL pointer to perf_guest_cb
This is a combination of ~2 series to fix bugs in the perf+KVM callbacks,
optimize the callbacks by employing static_call, and do a variety of
cleanup in both perf and KVM.
For the non-perf patches, I think everything except patch 13 (Paolo) and
patches 15 and 16 (Marc) has the appropriate acks.
Override the Processor Trace (PT) interrupt handler for guest mode if and
only if PT is configured for host+guest mode, i.e. is being used
independently by both host and guest. If PT is configured for system
mode, the host fully controls PT and must handle all events.
Fixes: 8479e04e7d6b ("KVM: x
Drop the 'int' return value from the perf (un)register callbacks helpers
and stop pretending perf can support multiple callbacks. The 'int'
returns are not future proofing anything as none of the callers take
action on an error. It's also not obvious that there will ever be
co-tenant hypervisors,
Protect perf_guest_cbs with RCU to fix multiple possible errors. Luckily,
all paths that read perf_guest_cbs already require RCU protection, e.g. to
protect the callback chains, so only the direct perf_guest_cbs touchpoints
need to be modified.
Bug #1 is a simple lack of WRITE_ONCE/READ_ONCE beha
Wait to register perf callbacks until after doing vendor hardaware setup.
VMX's hardware_setup() configures Intel Processor Trace (PT) mode, and a
future fix to register the Intel PT guest interrupt hook if and only if
Intel PT is exposed to the guest will consume the configured PT mode.
Delaying
Drop "support" for guest callbacks from architectures that don't implement
the guest callbacks. Future patches will convert the callbacks to
static_call; rather than churn a bunch of arch code (that was presumably
copy+pasted from x86), remove it wholesale as it's useless and at best
wasting cycle
From: Like Xu
To prepare for using static_calls to optimize perf's guest callbacks,
replace ->is_in_guest and ->is_user_mode with a new multiplexed hook
->state, tweak ->handle_intel_pt_intr to play nice with being called when
there is no active guest, and drop "guest" from ->get_guest_ip.
Retur
Add helpers for the guest callbacks to prepare for burying the callbacks
behind a Kconfig (it's a lot easier to provide a few stubs than to #ifdef
piles of code), and also to prepare for converting the callbacks to
static_call(). perf_instruction_pointer() in particular will have subtle
semantics
Introduce GUEST_PERF_EVENTS and require architectures to select it to
allow registering and using guest callbacks in perf. This will hopefully
make it more difficult for new architectures to add useless "support" for
guest callbacks, e.g. via copy+paste.
Stubbing out the helpers has the happy bon
Differentiate between IRQ and NMI for KVM's PMC overflow callback, which
was originally invoked in response to an NMI that arrived while the guest
was running, but was inadvertantly changed to fire on IRQs as well when
support for perf without PMU/NMI was added to KVM. In practice, this
should be
Move x86's perf guest callbacks into common KVM, as they are semantically
identical to arm64's callbacks (the only other such KVM callbacks).
arm64 will convert to the common versions in a future patch.
Implement the necessary arm64 arch hooks now to avoid having to provide
stubs or a temporary #d
Use the generic kvm_running_vcpu plus a new 'handling_intr_from_guest'
variable in kvm_arch_vcpu instead of the semi-redundant current_vcpu.
kvm_before/after_interrupt() must be called while the vCPU is loaded,
(which protects against preemption), thus kvm_running_vcpu is guaranteed
to be non-NULL
Use static_call to optimize perf's guest callbacks on arm64 and x86,
which are now the only architectures that define the callbacks. Use
DEFINE_STATIC_CALL_RET0 as the default/NULL for all guest callbacks, as
the callback semantics are that a return value '0' means "not in guest".
static_call obv
Drop arm64's version of the callbacks in favor of the callbacks provided
by generic KVM, which are semantically identical.
Reviewed-by: Marc Zyngier
Signed-off-by: Sean Christopherson
---
arch/arm64/kvm/perf.c | 34 ++
1 file changed, 2 insertions(+), 32 deletion
Drop perf's stubs for (un)registering guest callbacks now that KVM
registration of callbacks is hidden behind GUEST_PERF_EVENTS=y. The only
other user is x86 XEN_PV, and x86 unconditionally selects PERF_EVENTS.
No functional change intended.
Reviewed-by: Paolo Bonzini
Signed-off-by: Sean Christ
Move the definition of kvm_arm_pmu_available to pmu-emul.c and, out of
"necessity", hide it behind CONFIG_HW_PERF_EVENTS. Provide a stub for
the key's wrapper, kvm_arm_support_pmu_v3(). Moving the key's definition
out of perf.c will allow a future commit to delete perf.c entirely.
Signed-off-by:
Now that all state needed for VMX's PT interrupt handler is exposed to
vmx.c (specifically the currently running vCPU), move the handler into
vmx.c where it belongs.
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/kvm_host.h | 2 +-
arch/x86/kvm/vmx/vmx.c | 22 +
Call KVM's (un)register perf callbacks helpers directly from arm.c and
delete perf.c
No functional change intended.
Signed-off-by: Sean Christopherson
---
arch/arm64/include/asm/kvm_host.h | 3 ---
arch/arm64/kvm/Makefile | 2 +-
arch/arm64/kvm/arm.c | 5 +++--
arch/ar
flight 166110 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166110/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail like 166101
test-amd64-amd64-xl-qemuu-win7-amd6
flight 166109 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166109/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel 14 guest-start fail REGR. vs. 165976
test-amd64-amd64-xl
On 11/11/21 03:07, Sean Christopherson wrote:
Protect perf_guest_cbs with RCU to fix multiple possible errors. Luckily,
all paths that read perf_guest_cbs already require RCU protection, e.g. to
protect the callback chains, so only the direct perf_guest_cbs touchpoints
need to be modified.
Bug
58 matches
Mail list logo
