Hey Marc,
> I'd be happy with the (maybe temporary) magic approach. It helps reasoning
> about things, and makes the transition smoother. Yes, bugs could crop up
> there, but given the static nature of obtaining a symbol's address, I'm
> fairly confident we'll get it right. The same cannot be
Hi David,
On 2020-06-22 11:20, David Brazdil wrote:
Hi Marc,
> - void *dst = lm_alias(__bp_harden_hyp_vecs + slot * SZ_2K);
> + char *vec = has_vhe() ? __bp_harden_hyp_vecs
> +: kvm_nvhe_sym(__bp_harden_hyp_vecs);
If we get this construct often, then something that
Hi Marc,
> > - void *dst = lm_alias(__bp_harden_hyp_vecs + slot * SZ_2K);
> > + char *vec = has_vhe() ? __bp_harden_hyp_vecs
> > + : kvm_nvhe_sym(__bp_harden_hyp_vecs);
>
> If we get this construct often, then something that abstracts
> the uggliness of the symbol
Hi David,
On 2020-06-18 13:25, David Brazdil wrote:
This patch is part of a series which builds KVM's non-VHE hyp code
separately
from VHE and the rest of the kernel.
The above comment doesn't really belong here, and us only fit for the
cover letter.
hyp-entry.S contains implementation
This patch is part of a series which builds KVM's non-VHE hyp code separately
from VHE and the rest of the kernel.
hyp-entry.S contains implementation of KVM hyp vectors. This code is mostly
shared between VHE/nVHE, therefore compile it under both VHE and nVHE build
rules. nVHE-specific host HVC
5 matches
Mail list logo
