2018-06-13 16:55:44 +03:00
// SPDX-License-Identifier: GPL-2.0
/*
* Copyright © 2019 Oracle and / or its affiliates . All rights reserved .
* Copyright © 2020 Amazon . com , Inc . or its affiliates . All Rights Reserved .
*
* KVM Xen emulation
*/
# ifndef __ARCH_X86_KVM_XEN_H__
# define __ARCH_X86_KVM_XEN_H__
2023-01-06 13:36:00 +03:00
# include <asm/xen/hypervisor.h>
2021-02-26 12:54:45 +03:00
# ifdef CONFIG_KVM_XEN
2021-02-02 18:48:05 +03:00
# include <linux/jump_label_ratelimit.h>
extern struct static_key_false_deferred kvm_xen_enabled ;
2020-12-09 23:08:30 +03:00
int __kvm_xen_has_interrupt ( struct kvm_vcpu * vcpu ) ;
2022-03-03 18:41:15 +03:00
void kvm_xen_inject_pending_events ( struct kvm_vcpu * vcpu ) ;
2021-02-02 19:53:25 +03:00
int kvm_xen_vcpu_set_attr ( struct kvm_vcpu * vcpu , struct kvm_xen_vcpu_attr * data ) ;
int kvm_xen_vcpu_get_attr ( struct kvm_vcpu * vcpu , struct kvm_xen_vcpu_attr * data ) ;
2020-12-03 18:52:25 +03:00
int kvm_xen_hvm_set_attr ( struct kvm * kvm , struct kvm_xen_hvm_attr * data ) ;
int kvm_xen_hvm_get_attr ( struct kvm * kvm , struct kvm_xen_hvm_attr * data ) ;
2022-03-03 18:41:18 +03:00
int kvm_xen_hvm_evtchn_send ( struct kvm * kvm , struct kvm_irq_routing_xen_evtchn * evt ) ;
2018-06-13 16:55:44 +03:00
int kvm_xen_write_hypercall_page ( struct kvm_vcpu * vcpu , u64 data ) ;
2021-02-02 16:19:35 +03:00
int kvm_xen_hvm_config ( struct kvm * kvm , struct kvm_xen_hvm_config * xhc ) ;
2021-08-04 19:48:41 +03:00
void kvm_xen_init_vm ( struct kvm * kvm ) ;
2021-02-02 18:48:05 +03:00
void kvm_xen_destroy_vm ( struct kvm * kvm ) ;
2022-03-03 18:41:21 +03:00
void kvm_xen_init_vcpu ( struct kvm_vcpu * vcpu ) ;
2022-03-03 18:41:13 +03:00
void kvm_xen_destroy_vcpu ( struct kvm_vcpu * vcpu ) ;
2022-03-03 18:41:17 +03:00
int kvm_xen_set_evtchn_fast ( struct kvm_xen_evtchn * xe ,
2021-12-10 19:36:23 +03:00
struct kvm * kvm ) ;
int kvm_xen_setup_evtchn ( struct kvm * kvm ,
struct kvm_kernel_irq_routing_entry * e ,
const struct kvm_irq_routing_entry * ue ) ;
2023-01-06 13:36:00 +03:00
void kvm_xen_update_tsc_info ( struct kvm_vcpu * vcpu ) ;
2021-12-10 19:36:23 +03:00
2021-03-01 15:53:09 +03:00
static inline bool kvm_xen_msr_enabled ( struct kvm * kvm )
{
return static_branch_unlikely ( & kvm_xen_enabled . key ) & &
kvm - > arch . xen_hvm_config . msr ;
}
2018-06-13 16:55:44 +03:00
static inline bool kvm_xen_hypercall_enabled ( struct kvm * kvm )
{
2021-02-02 18:48:05 +03:00
return static_branch_unlikely ( & kvm_xen_enabled . key ) & &
( kvm - > arch . xen_hvm_config . flags &
KVM_XEN_HVM_CONFIG_INTERCEPT_HCALL ) ;
2018-06-13 16:55:44 +03:00
}
2020-12-09 23:08:30 +03:00
static inline int kvm_xen_has_interrupt ( struct kvm_vcpu * vcpu )
{
if ( static_branch_unlikely ( & kvm_xen_enabled . key ) & &
2022-03-03 18:41:15 +03:00
vcpu - > arch . xen . vcpu_info_cache . active & &
vcpu - > kvm - > arch . xen . upcall_vector )
2020-12-09 23:08:30 +03:00
return __kvm_xen_has_interrupt ( vcpu ) ;
return 0 ;
}
2022-03-03 18:41:15 +03:00
static inline bool kvm_xen_has_pending_events ( struct kvm_vcpu * vcpu )
{
return static_branch_unlikely ( & kvm_xen_enabled . key ) & &
vcpu - > arch . xen . evtchn_pending_sel ;
}
2022-03-03 18:41:22 +03:00
static inline bool kvm_xen_timer_enabled ( struct kvm_vcpu * vcpu )
{
return ! ! vcpu - > arch . xen . timer_virq ;
}
static inline int kvm_xen_has_pending_timer ( struct kvm_vcpu * vcpu )
{
if ( kvm_xen_hypercall_enabled ( vcpu - > kvm ) & & kvm_xen_timer_enabled ( vcpu ) )
return atomic_read ( & vcpu - > arch . xen . timer_pending ) ;
return 0 ;
}
void kvm_xen_inject_timer_irqs ( struct kvm_vcpu * vcpu ) ;
2021-02-26 12:54:45 +03:00
# else
static inline int kvm_xen_write_hypercall_page ( struct kvm_vcpu * vcpu , u64 data )
{
return 1 ;
}
2021-08-04 19:48:41 +03:00
static inline void kvm_xen_init_vm ( struct kvm * kvm )
{
}
2021-02-26 12:54:45 +03:00
static inline void kvm_xen_destroy_vm ( struct kvm * kvm )
{
}
2022-03-03 18:41:21 +03:00
static inline void kvm_xen_init_vcpu ( struct kvm_vcpu * vcpu )
{
}
2022-03-03 18:41:13 +03:00
static inline void kvm_xen_destroy_vcpu ( struct kvm_vcpu * vcpu )
{
}
2021-03-01 15:53:09 +03:00
static inline bool kvm_xen_msr_enabled ( struct kvm * kvm )
{
return false ;
}
2021-02-26 12:54:45 +03:00
static inline bool kvm_xen_hypercall_enabled ( struct kvm * kvm )
{
return false ;
}
static inline int kvm_xen_has_interrupt ( struct kvm_vcpu * vcpu )
{
return 0 ;
}
2022-03-03 18:41:15 +03:00
static inline void kvm_xen_inject_pending_events ( struct kvm_vcpu * vcpu )
{
}
static inline bool kvm_xen_has_pending_events ( struct kvm_vcpu * vcpu )
{
return false ;
}
2022-03-03 18:41:22 +03:00
static inline int kvm_xen_has_pending_timer ( struct kvm_vcpu * vcpu )
{
return 0 ;
}
static inline void kvm_xen_inject_timer_irqs ( struct kvm_vcpu * vcpu )
{
}
static inline bool kvm_xen_timer_enabled ( struct kvm_vcpu * vcpu )
{
return false ;
}
2023-01-06 13:36:00 +03:00
static inline void kvm_xen_update_tsc_info ( struct kvm_vcpu * vcpu )
{
}
2021-02-26 12:54:45 +03:00
# endif
int kvm_xen_hypercall ( struct kvm_vcpu * vcpu ) ;
2020-12-03 21:45:22 +03:00
# include <asm/pvclock-abi.h>
# include <asm/xen/interface.h>
2021-03-01 15:53:09 +03:00
# include <xen/interface/vcpu.h>
2020-12-03 21:45:22 +03:00
KVM: x86/xen: Compatibility fixes for shared runstate area
The guest runstate area can be arbitrarily byte-aligned. In fact, even
when a sane 32-bit guest aligns the overall structure nicely, the 64-bit
fields in the structure end up being unaligned due to the fact that the
32-bit ABI only aligns them to 32 bits.
So setting the ->state_entry_time field to something|XEN_RUNSTATE_UPDATE
is buggy, because if it's unaligned then we can't update the whole field
atomically; the low bytes might be observable before the _UPDATE bit is.
Xen actually updates the *byte* containing that top bit, on its own. KVM
should do the same.
In addition, we cannot assume that the runstate area fits within a single
page. One option might be to make the gfn_to_pfn cache cope with regions
that cross a page — but getting a contiguous virtual kernel mapping of a
discontiguous set of IOMEM pages is a distinctly non-trivial exercise,
and it seems this is the *only* current use case for the GPC which would
benefit from it.
An earlier version of the runstate code did use a gfn_to_hva cache for
this purpose, but it still had the single-page restriction because it
used the uhva directly — because it needs to be able to do so atomically
when the vCPU is being scheduled out, so it used pagefault_disable()
around the accesses and didn't just use kvm_write_guest_cached() which
has a fallback path.
So... use a pair of GPCs for the first and potential second page covering
the runstate area. We can get away with locking both at once because
nothing else takes more than one GPC lock at a time so we can invent
a trivial ordering rule.
The common case where it's all in the same page is kept as a fast path,
but in both cases, the actual guest structure (compat or not) is built
up from the fields in @vx, following preset pointers to the state and
times fields. The only difference is whether those pointers point to
the kernel stack (in the split case) or to guest memory directly via
the GPC. The fast path is also fixed to use a byte access for the
XEN_RUNSTATE_UPDATE bit, then the only real difference is the dual
memcpy.
Finally, Xen also does write the runstate area immediately when it's
configured. Flip the kvm_xen_update_runstate() and …_guest() functions
and call the latter directly when the runstate area is set. This means
that other ioctls which modify the runstate also write it immediately
to the guest when they do so, which is also intended.
Update the xen_shinfo_test to exercise the pathological case where the
XEN_RUNSTATE_UPDATE flag in the top byte of the state_entry_time is
actually in a different page to the rest of the 64-bit word.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-11-18 17:32:38 +03:00
void kvm_xen_update_runstate ( struct kvm_vcpu * vcpu , int state ) ;
2021-03-01 15:53:09 +03:00
static inline void kvm_xen_runstate_set_running ( struct kvm_vcpu * vcpu )
{
KVM: x86/xen: Compatibility fixes for shared runstate area
The guest runstate area can be arbitrarily byte-aligned. In fact, even
when a sane 32-bit guest aligns the overall structure nicely, the 64-bit
fields in the structure end up being unaligned due to the fact that the
32-bit ABI only aligns them to 32 bits.
So setting the ->state_entry_time field to something|XEN_RUNSTATE_UPDATE
is buggy, because if it's unaligned then we can't update the whole field
atomically; the low bytes might be observable before the _UPDATE bit is.
Xen actually updates the *byte* containing that top bit, on its own. KVM
should do the same.
In addition, we cannot assume that the runstate area fits within a single
page. One option might be to make the gfn_to_pfn cache cope with regions
that cross a page — but getting a contiguous virtual kernel mapping of a
discontiguous set of IOMEM pages is a distinctly non-trivial exercise,
and it seems this is the *only* current use case for the GPC which would
benefit from it.
An earlier version of the runstate code did use a gfn_to_hva cache for
this purpose, but it still had the single-page restriction because it
used the uhva directly — because it needs to be able to do so atomically
when the vCPU is being scheduled out, so it used pagefault_disable()
around the accesses and didn't just use kvm_write_guest_cached() which
has a fallback path.
So... use a pair of GPCs for the first and potential second page covering
the runstate area. We can get away with locking both at once because
nothing else takes more than one GPC lock at a time so we can invent
a trivial ordering rule.
The common case where it's all in the same page is kept as a fast path,
but in both cases, the actual guest structure (compat or not) is built
up from the fields in @vx, following preset pointers to the state and
times fields. The only difference is whether those pointers point to
the kernel stack (in the split case) or to guest memory directly via
the GPC. The fast path is also fixed to use a byte access for the
XEN_RUNSTATE_UPDATE bit, then the only real difference is the dual
memcpy.
Finally, Xen also does write the runstate area immediately when it's
configured. Flip the kvm_xen_update_runstate() and …_guest() functions
and call the latter directly when the runstate area is set. This means
that other ioctls which modify the runstate also write it immediately
to the guest when they do so, which is also intended.
Update the xen_shinfo_test to exercise the pathological case where the
XEN_RUNSTATE_UPDATE flag in the top byte of the state_entry_time is
actually in a different page to the rest of the 64-bit word.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-11-18 17:32:38 +03:00
kvm_xen_update_runstate ( vcpu , RUNSTATE_running ) ;
2021-03-01 15:53:09 +03:00
}
static inline void kvm_xen_runstate_set_preempted ( struct kvm_vcpu * vcpu )
{
/*
* If the vCPU wasn ' t preempted but took a normal exit for
* some reason ( hypercalls , I / O , etc . ) , that is accounted as
* still RUNSTATE_running , as the VMM is still operating on
* behalf of the vCPU . Only if the VMM does actually block
* does it need to enter RUNSTATE_blocked .
*/
2022-06-07 17:07:11 +03:00
if ( WARN_ON_ONCE ( ! vcpu - > preempted ) )
return ;
KVM: x86/xen: Compatibility fixes for shared runstate area
The guest runstate area can be arbitrarily byte-aligned. In fact, even
when a sane 32-bit guest aligns the overall structure nicely, the 64-bit
fields in the structure end up being unaligned due to the fact that the
32-bit ABI only aligns them to 32 bits.
So setting the ->state_entry_time field to something|XEN_RUNSTATE_UPDATE
is buggy, because if it's unaligned then we can't update the whole field
atomically; the low bytes might be observable before the _UPDATE bit is.
Xen actually updates the *byte* containing that top bit, on its own. KVM
should do the same.
In addition, we cannot assume that the runstate area fits within a single
page. One option might be to make the gfn_to_pfn cache cope with regions
that cross a page — but getting a contiguous virtual kernel mapping of a
discontiguous set of IOMEM pages is a distinctly non-trivial exercise,
and it seems this is the *only* current use case for the GPC which would
benefit from it.
An earlier version of the runstate code did use a gfn_to_hva cache for
this purpose, but it still had the single-page restriction because it
used the uhva directly — because it needs to be able to do so atomically
when the vCPU is being scheduled out, so it used pagefault_disable()
around the accesses and didn't just use kvm_write_guest_cached() which
has a fallback path.
So... use a pair of GPCs for the first and potential second page covering
the runstate area. We can get away with locking both at once because
nothing else takes more than one GPC lock at a time so we can invent
a trivial ordering rule.
The common case where it's all in the same page is kept as a fast path,
but in both cases, the actual guest structure (compat or not) is built
up from the fields in @vx, following preset pointers to the state and
times fields. The only difference is whether those pointers point to
the kernel stack (in the split case) or to guest memory directly via
the GPC. The fast path is also fixed to use a byte access for the
XEN_RUNSTATE_UPDATE bit, then the only real difference is the dual
memcpy.
Finally, Xen also does write the runstate area immediately when it's
configured. Flip the kvm_xen_update_runstate() and …_guest() functions
and call the latter directly when the runstate area is set. This means
that other ioctls which modify the runstate also write it immediately
to the guest when they do so, which is also intended.
Update the xen_shinfo_test to exercise the pathological case where the
XEN_RUNSTATE_UPDATE flag in the top byte of the state_entry_time is
actually in a different page to the rest of the 64-bit word.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-11-18 17:32:38 +03:00
kvm_xen_update_runstate ( vcpu , RUNSTATE_runnable ) ;
2021-03-01 15:53:09 +03:00
}
/* 32-bit compatibility definitions, also used natively in 32-bit build */
2020-12-03 21:45:22 +03:00
struct compat_arch_vcpu_info {
unsigned int cr2 ;
unsigned int pad [ 5 ] ;
} ;
struct compat_vcpu_info {
2021-02-10 21:26:09 +03:00
uint8_t evtchn_upcall_pending ;
uint8_t evtchn_upcall_mask ;
uint16_t pad ;
uint32_t evtchn_pending_sel ;
struct compat_arch_vcpu_info arch ;
struct pvclock_vcpu_time_info time ;
2020-12-03 21:45:22 +03:00
} ; /* 64 bytes (x86) */
struct compat_arch_shared_info {
unsigned int max_pfn ;
unsigned int pfn_to_mfn_frame_list_list ;
unsigned int nmi_reason ;
unsigned int p2m_cr3 ;
unsigned int p2m_vaddr ;
unsigned int p2m_generation ;
uint32_t wc_sec_hi ;
} ;
struct compat_shared_info {
struct compat_vcpu_info vcpu_info [ MAX_VIRT_CPUS ] ;
uint32_t evtchn_pending [ 32 ] ;
uint32_t evtchn_mask [ 32 ] ;
struct pvclock_wall_clock wc ;
struct compat_arch_shared_info arch ;
} ;
2021-12-10 19:36:23 +03:00
# define COMPAT_EVTCHN_2L_NR_CHANNELS (8 * \
sizeof_field ( struct compat_shared_info , \
evtchn_pending ) )
2021-03-01 15:53:09 +03:00
struct compat_vcpu_runstate_info {
int state ;
uint64_t state_entry_time ;
uint64_t time [ 4 ] ;
} __attribute__ ( ( packed ) ) ;
2022-03-21 14:05:32 +03:00
struct compat_sched_poll {
/* This is actually a guest virtual address which points to ports. */
uint32_t ports ;
unsigned int nr_ports ;
uint64_t timeout ;
} ;
2018-06-13 16:55:44 +03:00
# endif /* __ARCH_X86_KVM_XEN_H__ */