[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC PATCH V3 2/2] qemu: support xen hvm direct kernel boot
>>> On 6/23/2014 at 06:14 PM, in message <alpine.DEB.2.02.1406231110050.19982@xxxxxxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> wrote: > On Sun, 22 Jun 2014, Chun Yan Liu wrote: > > >>> On 6/20/2014 at 08:08 PM, in message > > <alpine.DEB.2.02.1406201300410.6594@xxxxxxxxxxxxxxxxxxxxxxx>, Stefano > > Stabellini <stefano.stabellini@xxxxxxxxxxxxx> wrote: > > > On Fri, 20 Jun 2014, Chunyan Liu wrote: > > > > qemu side patch to support xen HVM direct kernel boot: > > > > if -kernel exists, calls xen_load_linux(), which will read > > > > kernel/initrd > > > > and add a linuxboot.bin or multiboot.bin option rom. The > > > > linuxboot.bin/multiboot.bin will load kernel/initrd and jump to execute > > > > > > > > kernel directly. It's working when xen uses seabios. > > > > > > > > Signed-off-by: Chunyan Liu <cyliu@xxxxxxxx> > > > > --- > > > > hw/i386/pc.c | 22 ++++++++++++++++++++++ > > > > hw/i386/pc_piix.c | 7 +++++++ > > > > hw/i386/xen/xen_apic.c | 1 + > > > > include/hw/i386/pc.h | 5 +++++ > > > > 4 files changed, 35 insertions(+) > > > > > > > > diff --git a/hw/i386/pc.c b/hw/i386/pc.c > > > > index 3e0ecf1..e005136 100644 > > > > --- a/hw/i386/pc.c > > > > +++ b/hw/i386/pc.c > > > > @@ -1183,6 +1183,28 @@ void pc_acpi_init(const char *default_dsdt) > > > > } > > > > } > > > > > > > > +FWCfgState *xen_load_linux(const char *kernel_filename, > > > > + const char *kernel_cmdline, > > > > + const char *initrd_filename, > > > > + ram_addr_t below_4g_mem_size, > > > > + PcGuestInfo *guest_info) > > > > +{ > > > > + int i; > > > > + FWCfgState *fw_cfg; > > > > + > > > > + assert(kernel_filename != NULL); > > > > + > > > > + fw_cfg = fw_cfg_init(BIOS_CFG_IOPORT, BIOS_CFG_IOPORT + 1, 0, 0); > > > > > > Is it actually OK to initialize just BIOS_CFG_IOPORT and avoid > > > everything else currently done in bochs_bios_init? > > > Would it make sense to simply call bochs_bios_init? > > > > > > > > > > + rom_set_fw(fw_cfg); > > > > + > > > > + load_linux(fw_cfg, kernel_filename, initrd_filename, > > > > kernel_cmdline, > > > > below_4g_mem_size); > > > > + for (i = 0; i < nb_option_roms; i++) { > > > > + rom_add_option(option_rom[i].name, option_rom[i].bootindex); > > > > + } > > > > > > Wouldn't this have the unintended consequence of possibly loading other > > > option_roms into the guest memory? > > > > For xen, no. > > > > Before this patch, indeed there is another option_rom "kvmvapic" in the > list, > > but since the option_rom list is never loaded in xen case, that won't harm. > > > But > > as expected, I think in xen case, it should not be in option_rom list at > all, since > > we won't expect to load it. In v1, I tried to check the option_rom name to > > bypass it and load multiboot.bin/linuxboot.bin only. > > > > In comments, Paolo Bonzini suggests a better way, that is to add following > line > > in xen_apic_realize(): > > + s->vapic_control = 0; > > In this way, "kvmvapic" won't be added to the option_rom list. I think that > > should be the normal way for xen. > > > > So, since V2, I updated in this way. > > http://lists.gnu.org/archive/html/qemu-devel/2014-06/msg00704.html > > I see. Paolo's suggestion is a good one. > > I would add an assert here to ensure that there is only one option > rom named "linuxboot.bin", so that we can easily spot if something in > the future breaks our assumptions. Yes, that's better. Will update. Thanks! > > > > > > > > > > > > + guest_info->fw_cfg = fw_cfg; > > > > + return fw_cfg; > > > > +} > > > > + > > > > FWCfgState *pc_memory_init(MemoryRegion *system_memory, > > > > const char *kernel_filename, > > > > const char *kernel_cmdline, > > > > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c > > > > index a48e263..b737868 100644 > > > > --- a/hw/i386/pc_piix.c > > > > +++ b/hw/i386/pc_piix.c > > > > @@ -158,6 +158,13 @@ static void pc_init1(MachineState *machine, > > > > machine->initrd_filename, > > > > below_4g_mem_size, above_4g_mem_size, > > > > rom_memory, &ram_memory, guest_info); > > > > + } else if (machine->kernel_filename != NULL) { > > > > + /* For xen HVM direct kernel boot, load linux here */ > > > > + fw_cfg = xen_load_linux(machine->kernel_filename, > > > > + machine->kernel_cmdline, > > > > + machine->initrd_filename, > > > > + below_4g_mem_size, > > > > + guest_info); > > > > } > > > > > > > > gsi_state = g_malloc0(sizeof(*gsi_state)); > > > > diff --git a/hw/i386/xen/xen_apic.c b/hw/i386/xen/xen_apic.c > > > > index 63bb7f7..f5acd6a 100644 > > > > --- a/hw/i386/xen/xen_apic.c > > > > +++ b/hw/i386/xen/xen_apic.c > > > > @@ -40,6 +40,7 @@ static void xen_apic_realize(DeviceState *dev, Error > > > > > > > **errp) > > > > { > > > > APICCommonState *s = APIC_COMMON(dev); > > > > > > > > + s->vapic_control = 0; > > > > memory_region_init_io(&s->io_memory, OBJECT(s), &xen_apic_io_ops, > > > > s, > > > > "xen-apic-msi", APIC_SPACE_SIZE); > > > > > > Why this change? It is not mentioned in the commit message. > > > > > > > > > > diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h > > > > index ca7a0bd..171a597 100644 > > > > --- a/include/hw/i386/pc.h > > > > +++ b/include/hw/i386/pc.h > > > > @@ -134,6 +134,11 @@ PcGuestInfo *pc_guest_info_init(ram_addr_t > > > below_4g_mem_size, > > > > void pc_pci_as_mapping_init(Object *owner, MemoryRegion > > > > *system_memory, > > > > MemoryRegion *pci_address_space); > > > > > > > > +FWCfgState *xen_load_linux(const char *kernel_filename, > > > > + const char *kernel_cmdline, > > > > + const char *initrd_filename, > > > > + ram_addr_t below_4g_mem_size, > > > > + PcGuestInfo *guest_info); > > > > FWCfgState *pc_memory_init(MemoryRegion *system_memory, > > > > const char *kernel_filename, > > > > const char *kernel_cmdline, > > > > -- > > > > 1.8.4.5 > > > > > > > > > > _______________________________________________ > > > Xen-devel mailing list > > > Xen-devel@xxxxxxxxxxxxx > > > http://lists.xen.org/xen-devel > > > > > > > > > > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |