On Tue, Sep 24, 2013 at 11:24:46PM +0200, Sander Eikelenboom wrote: > > > Can you send out the all the logs when using qemu-dm-traditional as well as > > the guest configuration file used by xl ? > > Sure, here is the complete set for qemu-dm-traditional. > I have added some extra printk's (see xen.diff and qemu.diff). > > From what i see when combining the info from all logs, both ioports and iomem > for the device (host 07:00.0 and 07:00.1, guest 00:05.0 and 00:06.0) get > mapped, but the expansion rom is not (not by hvmloader and not by qemu) as > one can see in > xl dmesg output. > So qemu seems to create the Memoryregion for the rom, but it doesn't seem to > be backed up by any mapping (at least not one that passes through > XEN_DOMCTL_memory_mapping hypercall). > ( how it exactly ends up pointing to the bios from the emulated cirrus i > don't know ) > > from the qemu log i see a lot of my extra printk's hit for the expansion rom > like: > pt_bar_mapping_one: [00:05:0] pt_bar_mapping_one: [Region:6] need unmapping > in case I/O Space or Memory Space disable > pt_bar_mapping_one: [00:05:0] pt_bar_mapping_one: [Region:6] update bar > mapping NOT needed [Address:ffffffffh] [Size:00020000h] [Type:00000008h] > > I also don't know if it would be desirable to do a direct mapping, or that > the guest should just get a copy at the right address of the memoryregion > that is created by hvmloader/qemu ? >
Wu: Did you have time to take a look at this? Anything suspicious? -- Pasi > -- > Sander > > P.S.: > The complete qemu log is a bit long for the mailinglist, so attached is > only the first part. > The complete log is downloadable from: > http://www.eikelenboom.it/qemu-dm-guest.log >
