Il mer 18 ago 2021, 12:31 Ashish Kalra <ashish.ka...@amd.com> ha scritto:
> Hello Paolo, > > On Mon, Aug 16, 2021 at 05:38:55PM +0200, Paolo Bonzini wrote: > > On 16/08/21 17:13, Ashish Kalra wrote: > > > > > I think that once the mirror VM starts booting and running the UEFI > > > > > code, it might be only during the PEI or DXE phase where it will > > > > > start actually running the MH code, so mirror VM probably still > need > > > > > to handles KVM_EXIT_IO when SEC phase does I/O, I can see PIC > > > > > accesses and Debug Agent initialization stuff in SEC startup code. > > > > That may be a design of the migration helper code that you were > working > > > > with, but it's not necessary. > > > > > > > Actually my comments are about a more generic MH code. > > > > I don't think that would be a good idea; designing QEMU's migration > helper > > interface to be as constrained as possible is a good thing. The > migration > > helper is extremely security sensitive code, so it should not expose > itself > > to the attack surface of the whole of QEMU. > > > > > One question i have here, is that where exactly will the MH code exist > in QEMU ? > > I assume it will be only x86 platform specific code, we probably will > never support it on other platforms ? > > So it will probably exist in hw/i386, something similar to "microvm" > support and using the same TYPE_X86_MACHINE ? > > Also if we are not going to use the existing KVM support code and > adding some duplicate KVM interface code, do we need to interface with > this added KVM code via the QEMU accelerator framework, or simply invoke > this KVM code statically ? > I would expect to be mostly separate. Once we get a second architecture we may move part of it into TYPE_ACCEL_KVM, but that can come later and probably it would still not reuse much code from the full-blown KVM code that supports interrupts, MMIO and all that. Paolo > Thanks, > Ashish > >
