Re: [PATCH v3 24/32] arm64: KVM: 32bit GP register access

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11 May 2013 01:36, Christoffer Dall <cdall@xxxxxxxxxxxxxxx> wrote:
> That all being said, we can remove the check.  I don't think, however,
> that it being an unlikely thing is a good argument: if we remove the
> check we need to make sure that the VM does whatever the architecture
> dictates, which I assume is to not skip the MMIO instruction and support
> setting the PC to the value returned from an I/O emulation device in
> QEMU.
>
> I think the scenario sounds crazy and is more than anything a sign of a
> bug somewhere, and whether it should be a PABT or a DABT is a judgement
> call, but I chose a PABT because the thing that's weird is jumping to an
> I/O address, it's not that the memory address for the load is
> problematic.

I'm confused -- in your first paragraph you talk about loading
PC from an MMIO region but in the second you talk about jumping
to an MMIO region. This check is catching the former, right?

Loading PC from a device isn't totally unheard of: the VIC (common
on ARM7) has a register which returns "address of the next interrupt
to take", with the intention that the IRQ vector can just have a
single instruction directly loading PC from the VIC register:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0273a/I1006455.html

Handling "executing code out of an MMIO region" is (a) rather
harder and (b) not necessary IMHO. QEMU's TCG emulation doesn't
support it and we haven't had huge "can't run this guest"
issues as a result.

thanks
-- PMM
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux