Hi,
On Tue, 26 Apr 2011, Takeshi HASEGAWA wrote:
> Anthony and upstream-qemu testers,
>
> I tried to run upstream-qemu with v14 patch set and found Fedora 14
> not bootable on HVM domain.
> Now it's running with vmport workaround patch at bottom of this mail.
>
>
> vmport device enables guests to know some configurations of the
> virtual machine itself. Actually it is not mandatory run guests,
> so disabled it to avoid qemu crash.
>
> I am not sure whether this fix is best way or not.
> In my thought it is ideal to take one of these solutions, but I could not.
>
> 1) fix vmport so that it works on Xen.
>
> I need to read vCPU registers, however I could not figure out
> how to do that on Xen. ;-)
>
> 2) disable vmport device entirely.
I think it's better to disable vmport with Xen, because we will not sync
the vcpu registers, at least in this patch series.
So I will just add the patch below to the patch series.
diff --git a/hw/pc.c b/hw/pc.c
index ebdf3b0..8106197 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -1082,7 +1082,8 @@ static void cpu_request_exit(void *opaque, int irq, int
level)
}
void pc_basic_device_init(qemu_irq *isa_irq,
- ISADevice **rtc_state)
+ ISADevice **rtc_state,
+ bool no_vmport)
{
int i;
DriveInfo *fd[MAX_FD];
@@ -1127,8 +1128,12 @@ void pc_basic_device_init(qemu_irq *isa_irq,
a20_line = qemu_allocate_irqs(handle_a20_line_change, first_cpu, 2);
i8042 = isa_create_simple("i8042");
i8042_setup_a20_line(i8042, &a20_line[0]);
- vmport_init();
- vmmouse = isa_try_create("vmmouse");
+ if (!no_vmport) {
+ vmport_init();
+ vmmouse = isa_try_create("vmmouse");
+ } else {
+ vmmouse = NULL;
+ }
if (vmmouse) {
qdev_prop_set_ptr(&vmmouse->qdev, "ps2_mouse", i8042);
qdev_init_nofail(&vmmouse->qdev);
diff --git a/hw/pc.h b/hw/pc.h
index cc7ba58..0dcbee7 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -137,7 +137,8 @@ void pc_memory_init(const char *kernel_filename,
qemu_irq *pc_allocate_cpu_irq(void);
void pc_vga_init(PCIBus *pci_bus);
void pc_basic_device_init(qemu_irq *isa_irq,
- ISADevice **rtc_state);
+ ISADevice **rtc_state,
+ bool no_vmport);
void pc_init_ne2k_isa(NICInfo *nd);
void pc_cmos_init(ram_addr_t ram_size, ram_addr_t above_4g_mem_size,
const char *boot_device,
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 4ff4a55..9a22a8a 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -141,7 +141,7 @@ static void pc_init1(ram_addr_t ram_size,
pc_vga_init(pci_enabled? pci_bus: NULL);
/* init basic PC hardware */
- pc_basic_device_init(isa_irq, &rtc_state);
+ pc_basic_device_init(isa_irq, &rtc_state, xen_enabled());
for(i = 0; i < nb_nics; i++) {
NICInfo *nd = &nd_table[i];
> I found vmmouse expects initialization of vmport,
> therefore additional patch will be needed.
>
>
> This may be a side-effect of the change below.
>
> > > > + /* Xen require only one Qemu VCPU */
> > > > pc_new_cpu(cpu_model);
> > >
> > > This looks a bit fishy. What is the semantic of -smp 2 or more in Xen
> > > mode? If that is an invalid/unused configuration option, catch that and
> > > reject it instead of installing this workaround. If it has a valid
> > > semantic, please elaborate why you need to restrict the number of
> > > instantiated cpus. Just to optimize memory usage?
> >
> > I thought in a first place that was needed to avoid errors. But it works
> > also when we initialise other CPUs. But I prefere to keep it that way to
> > save memory and in the case where there is a thread for each cpu that
> > will also avoid to have many useless threads.
> >
> > Also, I use -smp i to initialise the xen's structures related to the
> > vcpu.
>
Thanks,
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home