Il ven 26 ago 2022, 17:50 Marc Zyngier ha scritto:
> userspace has no choice. It cannot order on its own the reads that the
> kernel will do to *other* rings.
>
> The problem isn't on CPU0 The problem is that CPU1 does observe
> inconsistent data on arm64, and I don't think this difference in
>
On Thu, Aug 25, 2022 at 11:25:18PM +, Sean Christopherson wrote:
> Do init_ucall() automatically during VM creation to kill two (three?)
> birds with one stone.
>
> First, initializing ucall immediately after VM creations allows forcing
> aarch64's MMIO ucall address to immediately follow
On Tue, Aug 23, 2022 at 11:47:21PM +, Ricardo Koller wrote:
> The vm_create() helpers are hardcoded to place most page types (code,
> page-tables, stacks, etc) in the same memslot #0, and always backed with
> anonymous 4K. There are a couple of issues with that. First, tests willing
> to
>
On Thu, Aug 25, 2022 at 11:25:22PM +, Sean Christopherson wrote:
> From: Peter Gonda
>
> To play nice with guests whose stack memory is encrypted, e.g. AMD SEV,
> introduce a new "ucall pool" implementation that passes the ucall struct
> via dedicated memory (which can be mapped shared,
On Thu, Aug 25, 2022 at 11:25:20PM +, Sean Christopherson wrote:
> Fix a mostly-theoretical bug where ARM's ucall MMIO setup could result in
> different VMs stomping on each other by cloberring the global pointer.
>
> Fix the most obvious issue by saving the MMIO gpa into the VM.
>
> A more
On Thu, Aug 25, 2022 at 11:25:21PM +, Sean Christopherson wrote:
> Drop ucall_uninit() and ucall_arch_uninit() now that ARM doesn't modify
> the host's copy of ucall_exit_mmio_addr, i.e. now that there's no need to
> reset the pointer before potentially creating a new VM. The few calls to
>
On Tue, Aug 23, 2022 at 11:47:22PM +, Ricardo Koller wrote:
> The previous commit added support for callers of vm_create() to specify
> what memslots to use for code, page-tables, and data allocations. Change
> them accordingly:
>
> - stacks, code, and exception tables use the code
