SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

[RFC PATCH 0/2] Allow RedHat PCI bridges reserve more buses than necessary during init
by Aleksandr Bezzubikov 24 Jul '17

24 Jul '17

Now PCI bridges (and PCIE root port too) get a bus range number in system init, basing on currently plugged devices. That's why when one wants to hotplug another bridge, it needs his child bus, which the parent is unable to provide. The suggested workaround is to have vendor-specific capability in RedHat generic pcie-root-port that contains number of additional bus to reserve on BIOS PCI init. Aleksandr Bezzubikov (2): pci: add support for direct usage of bdf for capability lookup pci: enable RedHat pci bridges to reserve more buses src/fw/pciinit.c | 12 ++++++++++-- src/hw/pcidevice.c | 24 ++++++++++++++++++++++++ src/hw/pcidevice.h | 1 + 3 files changed, 35 insertions(+), 2 deletions(-) -- 2.7.4

6 17

Re: [SeaBIOS] >256 Virtio-net-pci hotplug Devices
by Marcel Apfelbaum 24 Jul '17

24 Jul '17

On 22/07/2017 2:57, Kinsella, Ray wrote: > > Hi Marcel > Hi Ray, > On 21/07/2017 01:33, Marcel Apfelbaum wrote: >> On 20/07/2017 3:44, Kinsella, Ray wrote: >> That's strange. Please ensure the virtio devices are working in >> virtio 1.0 mode (disable-modern=0,disable-legacy=1). >> Let us know any problems you see. >> >>> Not sure what yet, I will try scaling it with hotplugging tomorrow. >>> >> >> Updates? > > I have managed to scale it to 128 devices. > The kernel does complain about IO address space exhaustion. > > [ 83.697956] pci 0000:80:00.0: BAR 13: no space for [io size 0x1000] > [ 83.700958] pci 0000:80:00.0: BAR 13: failed to assign [io size 0x1000] > [ 83.701689] pci 0000:80:00.1: BAR 13: no space for [io size 0x1000] > [ 83.702378] pci 0000:80:00.1: BAR 13: failed to assign [io size 0x1000] > [ 83.703093] pci 0000:80:00.2: BAR 13: no space for [io size 0x1000] > > I was surprised that I am running out of IO address space, as I am > disabling legacy virtio. I assumed that this would remove the need for > SeaBIOS to allocate the PCI Express Root Port IO address space. Indeed, SeeBIOS does not reserve IO ports in this case, but Linux kernel still decides ""it knows better" and tries to allocate IO resources anyway. It does not affect the "modern" virtio-net devices because they don't need IO ports anyway. One way to work around the error message is to have the PCIe Root Port have the corresponding IO headers read-only since IO support is optional. I tried this some time ago, I'll get back to it. > In any > case - it doesn't stop the virtio-net device coming up and working as > expected. > Right. > [ 668.692081] virtio_net virtio103 enp141s0f4: renamed from eth101 > [ 668.707114] virtio_net virtio130 enp144s0f7: renamed from eth128 > [ 668.719795] virtio_net virtio129 enp144s0f6: renamed from eth127 > > I encountered some issues in vhost, due to open file exhaustion but > resolved these with 'ulimit' in the usual way - burned alot of time on > that today. > > When scaling up to 512 Virtio-net devices SeaBIOS appears to really slow > down when configuring PCI Config space - haven't manage to get this to > work yet. > Adding SeaBIOS mailing list and maintainers, maybe there is a known issue about 500+ PCI devices configuration. >> Not really. All you have to do is to add a property to the pxb-pci/pxb >> devices: pci_domain=x; then update the ACPI table to include the pxb >> domain. You also have to tweak a little the pxb-pcie/pxb devices >> to not share the bus numbers if pci_domain > 0. > > Thanks for information, will add to the list. > Is also on my todo list :) Thanks, Marcel > Ray K > \

3 2

Re: [SeaBIOS] [RFC PATCH v2 4/4] pci: enable RedHat PCI bridges to reserve additional buses on PCI init
by Alexander Bezzubikov 23 Jul '17

23 Jul '17

By the way, any ideas on how to avoid 'bus overstealing' would be greatly appreciated. Static BIOS variable isn't applicable since its value isn't saved across reboots. 2017-07-23 19:43 GMT+03:00 Alexander Bezzubikov <zuban32s(a)gmail.com>: > 2017-07-23 5:49 GMT+03:00 Michael S. Tsirkin <mst(a)redhat.com>: > >> On Sun, Jul 23, 2017 at 01:11:50AM +0300, Aleksandr Bezzubikov wrote: >> > In case of Red Hat PCI bridges reserve additional buses, which number >> is provided >> > in a vendor-specific capability. >> > >> > Signed-off-by: Aleksandr Bezzubikov <zuban32s(a)gmail.com> >> > --- >> > src/fw/pciinit.c | 14 ++++++++++++-- >> > 1 file changed, 12 insertions(+), 2 deletions(-) >> > >> > diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c >> > index 864954f..f05a8b9 100644 >> > --- a/src/fw/pciinit.c >> > +++ b/src/fw/pciinit.c >> > @@ -15,6 +15,7 @@ >> > #include "hw/pcidevice.h" // pci_probe_devices >> > #include "hw/pci_ids.h" // PCI_VENDOR_ID_INTEL >> > #include "hw/pci_regs.h" // PCI_COMMAND >> > +#include "hw/pci_cap.h" // qemu_pci_cap >> > #include "list.h" // struct hlist_node >> > #include "malloc.h" // free >> > #include "output.h" // dprintf >> > @@ -578,9 +579,18 @@ pci_bios_init_bus_rec(int bus, u8 *pci_bus) >> > pci_bios_init_bus_rec(secbus, pci_bus); >> > >> > if (subbus != *pci_bus) { >> > + u8 res_bus = 0; >> > + if (pci_config_readw(bdf, PCI_VENDOR_ID) == >> PCI_VENDOR_ID_REDHAT) { >> >> Check device ID as well. > > Not sure what ID/IDs we want to see here exactly. Now it can be > only pcie-root-port (0xC then), but > > >> >> > + u8 cap = pci_find_capability(bdf, PCI_CAP_ID_VNDR, 0); >> >> There could be multiple vendor capabilities. You want to scan them all. >> >> >> > + if (cap) { >> > + res_bus = pci_config_readb(bdf, >> > + cap + offsetof(struct >> redhat_pci_bridge_cap, >> > + bus_res)); >> >> >> You might want to add sanity checks e.g. overflow, and capability >> length. >> >> Also, if all you use is offsetof, don't bother with a struct, just >> add some defines. >> > OK, will move this to defines. > > >> >> > + } >> > + } >> > dprintf(1, "PCI: subordinate bus = 0x%x -> 0x%x\n", >> > - subbus, *pci_bus); >> > - subbus = *pci_bus; >> > + subbus, *pci_bus + res_bus); >> > + subbus = *pci_bus + res_bus; >> >> So you take all present devices and add reserved ones - is that it? >> If so it looks like this will steal extra buses each time you >> add a child bus and reboot. >> > > You're right, such problem persists. Will think on what can be done here. > > >> >> >> > } else { >> > dprintf(1, "PCI: subordinate bus = 0x%x\n", subbus); >> > } >> > -- >> > 2.7.4 >> > > > > -- > Alexander Bezzubikov > -- Alexander Bezzubikov

1 0

Re: [SeaBIOS] [RFC PATCH v2 4/6] hw/pci: introduce bridge-only vendor-specific capability to provide some hints to firmware
by Marcel Apfelbaum 23 Jul '17

23 Jul '17

On 23/07/2017 19:19, Alexander Bezzubikov wrote: > 2017-07-23 18:57 GMT+03:00 Marcel Apfelbaum <marcel(a)redhat.com > <mailto:marcel@redhat.com>>: > > On 23/07/2017 1:15, Aleksandr Bezzubikov wrote: > > On PCI init PCI bridges may need some > extra info about bus number to reserve, IO, memory and > prefetchable memory limits. QEMU can provide this > with special vendor-specific PCI capability. > > Sizes of limits match ones from > PCI Type 1 Configuration Space Header, > number of buses to reserve occupies only 1 byte > since it is the size of Subordinate Bus Number register. > > > Hi Alexandr, > > Signed-off-by: Aleksandr Bezzubikov <zuban32s(a)gmail.com > <mailto:zuban32s@gmail.com>> > --- > hw/pci/pci_bridge.c | 27 +++++++++++++++++++++++++++ > include/hw/pci/pci_bridge.h | 18 ++++++++++++++++++ > 2 files changed, 45 insertions(+) > > diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c > index 720119b..8ec6c2c 100644 > --- a/hw/pci/pci_bridge.c > +++ b/hw/pci/pci_bridge.c > @@ -408,6 +408,33 @@ void pci_bridge_map_irq(PCIBridge *br, > const char* bus_name, > br->bus_name = bus_name; > } > + > +int pci_bridge_help_cap_init(PCIDevice *dev, int cap_offset, > > > Can you please rename to something like > 'pci_bridge_qemu_cap_init' to be more specific? > > + uint8_t bus_reserve, uint32_t > io_limit, > + uint16_t mem_limit, uint64_t > pref_limit, > > > > I am not sure regarding "limit" suffix, this > is a reservation, not a limitation. > > > I'd like this fields names to match actual registers which > are going to get the values. > For this case I think is better to have io_res..., to describe the parameter rather than match the registers. > > > + Error **errp) > +{ > + size_t cap_len = sizeof(PCIBridgeQemuCap); > + PCIBridgeQemuCap cap; > + > + cap.len = cap_len; > + cap.bus_res = bus_reserve; > + cap.io_lim = io_limit & 0xFF; > + cap.io_lim_upper = io_limit >> 8 & 0xFFFF; > + cap.mem_lim = mem_limit; > + cap.pref_lim = pref_limit & 0xFFFF; > + cap.pref_lim_upper = pref_limit >> 16 & 0xFFFFFFFF; > + > + int offset = pci_add_capability(dev, PCI_CAP_ID_VNDR, > + cap_offset, cap_len, errp); > + if (offset < 0) { > + return offset; > + } > + > + memcpy(dev->config + offset + 2, (char *)&cap + 2, cap_len > - 2); > + return 0; > +} > + > static const TypeInfo pci_bridge_type_info = { > .name = TYPE_PCI_BRIDGE, > .parent = TYPE_PCI_DEVICE, > diff --git a/include/hw/pci/pci_bridge.h > b/include/hw/pci/pci_bridge.h > index ff7cbaa..c9f642c 100644 > --- a/include/hw/pci/pci_bridge.h > +++ b/include/hw/pci/pci_bridge.h > @@ -67,4 +67,22 @@ void pci_bridge_map_irq(PCIBridge *br, const > char* bus_name, > #define PCI_BRIDGE_CTL_DISCARD_STATUS 0x400 /* > Discard timer status */ > #define PCI_BRIDGE_CTL_DISCARD_SERR 0x800 /* Discard > timer SERR# enable */ > +typedef struct PCIBridgeQemuCap { > + uint8_t id; /* Standard PCI capability header field */ > + uint8_t next; /* Standard PCI capability header field */ > + uint8_t len; /* Standard PCI vendor-specific capability > header field */ > + uint8_t bus_res; > + uint32_t pref_lim_upper; > + uint16_t pref_lim; > + uint16_t mem_lim; > > > This 32bit IOMEM, right? > > + uint16_t io_lim_upper; > + uint8_t io_lim; > > > Why do we need io_lim and io_lim_upper? > > > The idea was to be able to directly move the capability fields values > to the registers when actually using it (in firmware) code. > Secondly, it saves a little space by avoding usage 32-bit types > when 24-bit ones are desired. And the same thing with prefetchable (48->64). > But if it's more convenient no to split this value, I can do that. With a clear explanation (Mimic of the <PCI config space field>) I personally don't mind keeping it like that. Thanks, Marcel > > > Thanks, > Marcel > > > + uint8_t padding; > +} PCIBridgeQemuCap; > + > +int pci_bridge_help_cap_init(PCIDevice *dev, int cap_offset, > + uint8_t bus_reserve, uint32_t > io_limit, > + uint16_t mem_limit, uint64_t > pref_limit, > + Error **errp); > + > #endif /* QEMU_PCI_BRIDGE_H */ > > > > > > -- > Alexander Bezzubikov

1 0

Re: [SeaBIOS] [PATCH] Support multiple hard disks in boot list.
by Kevin O'Connor 20 Jul '17

20 Jul '17

On Thu, Jul 13, 2017 at 05:30:43PM -0700, Gaurav Poothia wrote: > Hi Kevin, > I also tried this patch to fallback from non bootable SCSI disk to > bootable SCSI disk with Windows installed. That worked too. > So while we cannot see the Windows bootloader source it sure seems to > be honoring the DL values other than 0x80 Thanks. I tried a handful of images I had handy and found a bunch of failures (see testing patch I used below). lilo - failed freedos - failed subtly winxp - failed winvista - success fedora 13 disk - failed Unfortunately, I don't think this is a change that could be made without near universal support. As, when it does fail, it fails in a very cryptic way. I think it would be more pain for users than gain. -Kevin --- a/src/boot.c +++ b/src/boot.c @@ -731,7 +731,7 @@ do_boot(int seq_nr) break; case IPL_TYPE_HARDDISK: printf("Booting from Hard Disk...\n"); - boot_disk(0x80, 1); + boot_disk(0x81, 1); break; case IPL_TYPE_CDROM: boot_cdrom((void*)ie->vector);

1 0

[PATCH 1/2] usb: add hub portmap
by Gerd Hoffmann 20 Jul '17

20 Jul '17

Allow usb hubs to map (software) ports to physical ports via op callback. This is needed to make bootorder work in case there isn't a simple linear mapping. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- src/hw/usb.h | 1 + src/boot.c | 11 +++++++++-- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/src/hw/usb.h b/src/hw/usb.h index 94e12b20dd..2cfb572177 100644 --- a/src/hw/usb.h +++ b/src/hw/usb.h @@ -56,6 +56,7 @@ struct usbhub_s { struct usbhub_op_s { int (*detect)(struct usbhub_s *hub, u32 port); int (*reset)(struct usbhub_s *hub, u32 port); + int (*portmap)(struct usbhub_s *hub, u32 port); void (*disconnect)(struct usbhub_s *hub, u32 port); }; diff --git a/src/boot.c b/src/boot.c index 59623fb63d..8f6802c89b 100644 --- a/src/boot.c +++ b/src/boot.c @@ -207,6 +207,13 @@ int bootprio_find_named_rom(const char *name, int instance) return find_prio(desc); } +static int usb_portmap(struct usbdevice_s *usbdev) +{ + if (usbdev->hub->op->portmap) + return usbdev->hub->op->portmap(usbdev->hub, usbdev->port); + return usbdev->port + 1; +} + static char * build_usb_path(char *buf, int max, struct usbhub_s *hub) { @@ -214,7 +221,7 @@ build_usb_path(char *buf, int max, struct usbhub_s *hub) // Root hub - nothing to add. return buf; char *p = build_usb_path(buf, max, hub->usbdev->hub); - p += snprintf(p, buf+max-p, "/hub@%x", hub->usbdev->port+1); + p += snprintf(p, buf+max-p, "/hub@%x", usb_portmap(hub->usbdev)); return p; } @@ -232,7 +239,7 @@ int bootprio_find_usb(struct usbdevice_s *usbdev, int lun) if (ret >= 0) return ret; // Try usb-host/redir - for example: /pci@i0cf8/usb@1,2/usb-host@1 - snprintf(p, desc+sizeof(desc)-p, "/usb-*@%x", usbdev->port+1); + snprintf(p, desc+sizeof(desc)-p, "/usb-*@%x", usb_portmap(usbdev)); return find_prio(desc); } -- 2.9.3

3 4

Re: [SeaBIOS] [Qemu-devel] Fwd: [RFC PATCH 0/2] Allow RedHat PCI bridges reserve more buses than necessary during init
by Konrad Rzeszutek Wilk 19 Jul '17

19 Jul '17

On Wed, Jul 19, 2017 at 09:38:50PM +0300, Alexander Bezzubikov wrote: > 2017-07-19 21:18 GMT+03:00 Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>: > > > On Wed, Jul 19, 2017 at 05:14:41PM +0000, Alexander Bezzubikov wrote: > > > ср, 19 июля 2017 г. в 16:57, Konrad Rzeszutek Wilk < > > konrad.wilk(a)oracle.com>: > > > > > > > On Wed, Jul 19, 2017 at 04:20:12PM +0300, Aleksandr Bezzubikov wrote: > > > > > Now PCI bridges (and PCIE root port too) get a bus range number in > > > > system init, > > > > > basing on currently plugged devices. That's why when one wants to > > > > hotplug another bridge, > > > > > it needs his child bus, which the parent is unable to provide. > > > > > > > > Could you explain how you trigger this? > > > > > > > > > I'm trying to hot plug pcie-pci bridge into pcie root port, and Linux > > says > > > 'cannot allocate bus number for device bla-bla'. This obviously does not > > > allow me to use the bridge at all. > > > > > > > > > > > > > > > > The suggested workaround is to have vendor-specific capability in > > RedHat > > > > generic pcie-root-port > > > > > that contains number of additional bus to reserve on BIOS PCI init. > > > > > > > > But wouldn't the proper fix be for the PCI bridge to have the > > subordinate > > > > value be extended to fit more bus ranges? > > > > > > > > > What do you mean? This is what I'm trying to do. Do you suppose to get > > rid > > > of vendor-specific cap and use original register value instead of it? > > > > I would suggest a simple fix - each bridge has a a number of bus devices > > it can use. You have up to 255 - so you split the number of northbridge > > numbers by the amount of NUMA nodes (if that is used) - so for example > > if you have 4 NUMA nodes, each bridge would cover 63 bus numbers. > > > > Meaning the root bridge would cover 0->63 bus, 64->128, and so on. > > That gives you enough space to plug in your plugged in devices > > (up to 63). > > > > And if you need sub-briges then carve out a specific range. > > > > The problem is that we don't know at the init moment how many subbridges we > may need, And the explanation above does not either. It just setups at init time an range where you can plug in your new devices in. But in a more uniform way such that you can also utilize this with NUMA and _PXM topology in the future. > and how deep the whole device tree will be. The key moment - PCI bridge > hotplugging > needs either rescan all buses on each bridge device addition, or reserve > space in advance during BIOS init. can all buses on each bridge device addition, or reserve It is more complex than that - you may need to move devices that are below you. And Linux kernel (nor any other OS) can handle that. (They can during bootup) > In this series the second way was chosen. > > > > > > > > > > > > > > > > > > > > > > > Aleksandr Bezzubikov (2): > > > > > pci: add support for direct usage of bdf for capability lookup > > > > > pci: enable RedHat pci bridges to reserve more buses > > > > > > > > > > src/fw/pciinit.c | 12 ++++++++++-- > > > > > src/hw/pcidevice.c | 24 ++++++++++++++++++++++++ > > > > > src/hw/pcidevice.h | 1 + > > > > > 3 files changed, 35 insertions(+), 2 deletions(-) > > > > > > > > > > -- > > > > > 2.7.4 > > > > > > > > > > > > > > > > > -- > > > Alexander Bezzubikov > > > > > > -- > Alexander Bezzubikov

2 1

Fwd: [Qemu-devel] [RFC PATCH 0/2] Allow RedHat PCI bridges reserve more buses than necessary during init
by Alexander Bezzubikov 19 Jul '17

19 Jul '17

2017-07-19 21:18 GMT+03:00 Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>: > On Wed, Jul 19, 2017 at 05:14:41PM +0000, Alexander Bezzubikov wrote: > > ср, 19 июля 2017 г. в 16:57, Konrad Rzeszutek Wilk < > konrad.wilk(a)oracle.com>: > > > > > On Wed, Jul 19, 2017 at 04:20:12PM +0300, Aleksandr Bezzubikov wrote: > > > > Now PCI bridges (and PCIE root port too) get a bus range number in > > > system init, > > > > basing on currently plugged devices. That's why when one wants to > > > hotplug another bridge, > > > > it needs his child bus, which the parent is unable to provide. > > > > > > Could you explain how you trigger this? > > > > > > I'm trying to hot plug pcie-pci bridge into pcie root port, and Linux > says > > 'cannot allocate bus number for device bla-bla'. This obviously does not > > allow me to use the bridge at all. > > > > > > > > > > > > The suggested workaround is to have vendor-specific capability in > RedHat > > > generic pcie-root-port > > > > that contains number of additional bus to reserve on BIOS PCI init. > > > > > > But wouldn't the proper fix be for the PCI bridge to have the > subordinate > > > value be extended to fit more bus ranges? > > > > > > What do you mean? This is what I'm trying to do. Do you suppose to get > rid > > of vendor-specific cap and use original register value instead of it? > > I would suggest a simple fix - each bridge has a a number of bus devices > it can use. You have up to 255 - so you split the number of northbridge > numbers by the amount of NUMA nodes (if that is used) - so for example > if you have 4 NUMA nodes, each bridge would cover 63 bus numbers. > > Meaning the root bridge would cover 0->63 bus, 64->128, and so on. > That gives you enough space to plug in your plugged in devices > (up to 63). > > And if you need sub-briges then carve out a specific range. > The problem is that we don't know at the init moment how many subbridges we may need, and how deep the whole device tree will be. The key moment - PCI bridge hotplugging needs either rescan all buses on each bridge device addition, or reserve space in advance during BIOS init. In this series the second way was chosen. > > > > > > > > > > > > > > > Aleksandr Bezzubikov (2): > > > > pci: add support for direct usage of bdf for capability lookup > > > > pci: enable RedHat pci bridges to reserve more buses > > > > > > > > src/fw/pciinit.c | 12 ++++++++++-- > > > > src/hw/pcidevice.c | 24 ++++++++++++++++++++++++ > > > > src/hw/pcidevice.h | 1 + > > > > 3 files changed, 35 insertions(+), 2 deletions(-) > > > > > > > > -- > > > > 2.7.4 > > > > > > > > > > > > > -- > > Alexander Bezzubikov > -- Alexander Bezzubikov

1 0

Re: [SeaBIOS] [Qemu-devel] [RFC PATCH 0/2] Allow RedHat PCI bridges reserve more buses than necessary during init
by Konrad Rzeszutek Wilk 19 Jul '17

19 Jul '17

On Wed, Jul 19, 2017 at 05:14:41PM +0000, Alexander Bezzubikov wrote: > ср, 19 июля 2017 г. в 16:57, Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>: > > > On Wed, Jul 19, 2017 at 04:20:12PM +0300, Aleksandr Bezzubikov wrote: > > > Now PCI bridges (and PCIE root port too) get a bus range number in > > system init, > > > basing on currently plugged devices. That's why when one wants to > > hotplug another bridge, > > > it needs his child bus, which the parent is unable to provide. > > > > Could you explain how you trigger this? > > > I'm trying to hot plug pcie-pci bridge into pcie root port, and Linux says > 'cannot allocate bus number for device bla-bla'. This obviously does not > allow me to use the bridge at all. > > > > > > > > The suggested workaround is to have vendor-specific capability in RedHat > > generic pcie-root-port > > > that contains number of additional bus to reserve on BIOS PCI init. > > > > But wouldn't the proper fix be for the PCI bridge to have the subordinate > > value be extended to fit more bus ranges? > > > What do you mean? This is what I'm trying to do. Do you suppose to get rid > of vendor-specific cap and use original register value instead of it? I would suggest a simple fix - each bridge has a a number of bus devices it can use. You have up to 255 - so you split the number of northbridge numbers by the amount of NUMA nodes (if that is used) - so for example if you have 4 NUMA nodes, each bridge would cover 63 bus numbers. Meaning the root bridge would cover 0->63 bus, 64->128, and so on. That gives you enough space to plug in your plugged in devices (up to 63). And if you need sub-briges then carve out a specific range. > > > > > > > > > Aleksandr Bezzubikov (2): > > > pci: add support for direct usage of bdf for capability lookup > > > pci: enable RedHat pci bridges to reserve more buses > > > > > > src/fw/pciinit.c | 12 ++++++++++-- > > > src/hw/pcidevice.c | 24 ++++++++++++++++++++++++ > > > src/hw/pcidevice.h | 1 + > > > 3 files changed, 35 insertions(+), 2 deletions(-) > > > > > > -- > > > 2.7.4 > > > > > > > > > -- > Alexander Bezzubikov

1 0

Re: [SeaBIOS] [Qemu-devel] [Question] Seabios HANGs when mmio wirte in a nested vmware host wtih virito-scsi controller
by Xiao Guangrong 17 Jul '17

17 Jul '17

On 07/17/2017 03:34 PM, Xulei (Stone) wrote: > > On 07/17/2017 11:13 AM, Xulei (Stone) wrote: > > >> |--virtio_queue_empty > >> > >> Then, kmod falls in infinite loop in handle EPT_MISCONFIG. > >> As far as i know, when kvm enters guest after handling EPT_MISCONFIG, seabios should return > >> from mmio write and wait for virtio backend(qemu) to handle this mmio writing. > >> What puzzles me: > >> 1) i can not understand why kvm runs in infinite loop and seabios does not return from writew. > > >From the trace in L1 guest, it did not hang in KVM, as it went into guest mode normally. > > >> 2) kvm nested kvm is ok. But vmware nested kvm is not ok. This problem has anything related > >> with vmware? > >> > > > It is the issue in vmware, i guess the RIP register is not handled correctly. > > BTW, does kvm unit tests run well on nested vmware? > > Sadly, kvm unit tests run fail on nested vmware and make the CentOS 7.3(with kmod 4.4.11) crashed... > Well, so that should be reported to vmware. :-)

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS