similar to: [PATCH 0/2] Fix booting tcm_vhost + seabios

This is on top of Paolo and Nick's work. Current status: Works now (guest boots fine, no hang any more) with seabios's virtio-scsi disabled. Rebased to latest qemu.org/master Change details are in commit log. TODO: Make seabios happy. Paolo Bonzini (2): virtio-scsi: create VirtIOSCSICommon vhost-scsi: new device supporting the tcm_vhost Linux kernel module hw/Makefile.objs

This is on top of Paolo and Nick's work. Current status: Works now (guest boots fine, no hang any more) with seabios's virtio-scsi disabled. Rebased to latest qemu.org/master Change details are in commit log. TODO: Make seabios happy. Paolo Bonzini (2): virtio-scsi: create VirtIOSCSICommon vhost-scsi: new device supporting the tcm_vhost Linux kernel module hw/Makefile.objs

Hi Paolo & Co, So I've been running into another bug with SeaBIOS w/ virtio-scsi + vhost-scsi-pci code.. During the last weeks debugging on the QEMU vhost memory re-mapping bug, my seabios builds have been using a smaller target ID (16) for scanning than the default hard coded value of 256 in init_virtio_scsi(). After bumping this value back to 256 recently, a bogus out_num value from

Hi Paolo & Co, So I've been running into another bug with SeaBIOS w/ virtio-scsi + vhost-scsi-pci code.. During the last weeks debugging on the QEMU vhost memory re-mapping bug, my seabios builds have been using a smaller target ID (16) for scanning than the default hard coded value of 256 in init_virtio_scsi(). After bumping this value back to 256 recently, a bogus out_num value from

On Thu, 2013-02-14 at 16:46 +0000, Ian Campbell wrote: > Right, we really need to find someone with hours to finish properly > integrating OVMF. Hm, that ''someone'' may end up being me¹. So... from the Xen point of view, what needs doing? There are some things on my TODO list which apply to Qemu/KVM too — most importantly, fixing bootorder handling, which basically

Cross posting from seabios@ [snip] > > Now I'd like to ask you guys if you could print the amount > > of RAM available -- like most other BIOSes out there already > > do - it would be extremely helpful to aid troubleshooting. > > SeaBIOS boots too fast for anything useful to be seen on the screen. > That said, one can add "-chardev stdio,id=seabios -device

@Ian Campbell: you do not receive my email? I have sent some mails to you and pkg-xen-devel at lists.alioth.debian.org reporting this problem since long time ago to some days ago. As Michael Tokarev above wrote also the build-dep should be changed to seabios >= 1.7.4-2~ I saw in git that is missed in your commit:

Control: reassign -1 src:xen On Sb, 23 aug 14, 18:18:51, Thomas Jepp wrote: > After doing a xen upgrade this morning to 4.4 I hit this same issue. > > I?ve compiled a set of test packages from this commit: http://anonscm.debian.org/cgit/pkg-xen/xen.git/commit/?h=feature/seabios&id=44daa679dc80f2df734e5471476df159bc0ad38d > > My HVM domUs now start as expected so this seems to

Hi: Anyone knows how to configure seabios with libvirt? Or Can I configure seabios in XML file? I know that could configre seabios with "qemu-system-x86_64 -fw_cfg",but how to with libvirt? thanks! dw

CentOS Errata and Bugfix Advisory 2014:1092 Upstream details at : https://rhn.redhat.com/errata/RHBA-2014-1092.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 66eb91e24851a9226f723b40815b23e736083eccb421f04f6c0feffee261a715 seabios-1.7.2.2-12.el7_0.1.x86_64.rpm

CentOS Errata and Bugfix Advisory 2017:0079 Upstream details at : https://rhn.redhat.com/errata/RHBA-2017-0079.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 87f4cfbd40fc58bb4ce37ed4059adf71ebf6f3f13f93f5a2efaad22dd489b1a4 seabios-1.9.1-5.el7_3.1.x86_64.rpm

CentOS Errata and Bugfix Advisory 2017:0398 Upstream details at : https://rhn.redhat.com/errata/RHBA-2017-0398.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 46169d67ac9ebf0fc0017e9eb542e6eab998177725361eacd40f0358d7ceffef seabios-1.9.1-5.el7_3.2.x86_64.rpm

CentOS Errata and Bugfix Advisory 2017:1319 Upstream details at : https://rhn.redhat.com/errata/RHBA-2017-1319.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: f156d2cc5250bee3757af676d4c1a60409842ddd4bb7abd613719f7a93354939 seabios-1.9.1-5.el7_3.3.x86_64.rpm

# HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1327508914 0 # Node ID 98b01cd24140a0899205c210b847aa1ec4a76efd # Parent 074d485f1d3d925b0b306602c694b4faea8b0b18 seabios: update to 1.6.3.1 release This is the latest seabios stable release. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff --git a/Config.mk b/Config.mk --- a/Config.mk +++

I've uploaded seabios 1.7.4-2 to debian archive which now ships 2 versions of the bios binary -- small 128Kb one and bios-256k.bin (with size = 256Kb, obviously). For now, both are built with Xen support. So for now, it is enough to just rebuild xen with seabios >= 1.7.4-2~ to get this fixed without patching. However, please apply the mentioned patch (or update to xen-4.3.1 version)

On Fri, Aug 01, 2014 at 03:14:17PM -0700, Zetan Drableg wrote: > Setup debuginfo repo > /etc/yum.repos.d/debuginfo. > repo > [ol6_debuginfo] > name=Oracle Linux 6 debuginfo > baseurl=http://oss.oracle.com/ol6/debuginfo > gpgkey=https://oss.oracle.com/ol6/RPM-GPG-KEY-oracle > gpgcheck=1 > enabled=1 > > yum update > yum install kernel-debuginfo > > (gdb)

The SeaBIOS ROM image may validly exceed 128k in size, it''s only our interface code that so far assumed that it wouldn''t. Remove that restriction by setting the base address depending on image size. Add a check to HVM loader so that too big images won''t result in silent guest failure anymore. Uncomment the intended build-time size check for rombios, moving it into a

Hi Richard thanks for the info. I took the strace approach and ran into this looping over and over again. Is it failing to get time? timer_gettime(0x8, {it_interval={0, 0}, it_value={0, 0}}) = 0 timer_settime(0x8, 0, {it_interval={0, 0}, it_value={0, 250000}}, NULL) = 0 timer_gettime(0x8, {it_interval={0, 0}, it_value={0, 204443}}) = 0 select(16, [0 6 9 13 15], [], [], {1, 0}) = 2 (in [6 13],

On Thu, Jul 31, 2014 at 03:32:18PM -0700, Zetan Drableg wrote: > Ok - > By the way, I looked into updating out KVM versions. Since we already > have so many KVM servers of this version in production, I can't easily > forklift update everything without much testing. > > exec /usr/libexec/qemu-kvm -s -S "$@" > > export LIBGUESTFS_HV=/root/work/qemu-wrapper

Package: xen-utils-4.3 Version: 4.3.0-3 Severity: important Tags: upstream patch When using Xen compiled with seabios-1.7.4-1 (now in unstable/testing), HVMs fail immediately upon starting with a VCPU triple fault: (XEN) HVM1: Loading SeaBIOS ... (XEN) hvm.c:1253:d1 Triple fault on VCPU0 - invoking HVM shutdown action 1. This is because SeaBIOS can now be greater than 128k, which breaks an