Re: [Xen-devel] [SeaBIOS] Seabios build failure with gcc 6.2.0 in Debian Sid
On Fri, Nov 04, 2016 at 07:06:07PM +0100, Dario Faggioli wrote:
> Hi,
>
> I'm reporting a build issue that I'm seeing when building Xen's
> userspace tools, when the build process clones and build Seabios, on
> Debian Sid, with gcc '6.2.0 20161019 (Debian 6.2.0-9)'.
>
> The error looks like this (http://pastebin.com/99cubDZ3):
>
> make -C seabios-dir all
> make[6]: Entering directory
> '/home/SOURCES/xen/xen.git/tools/firmware/seabios-dir-remote'
> Compile checking out/src/stacks.o
> src/stacks.c: Assembler messages:
> src/stacks.c:567: Error: found `(', expected: `)'
> src/stacks.c:567: Error: junk `(%ebp))' after expression
> src/stacks.c:568: Warning: indirect call without `*'
> Makefile:133: recipe for target 'out/src/stacks.o' failed
> make[6]: *** [out/src/stacks.o] Error 1
> make[6]: Leaving directory
> '/home/SOURCES/xen/xen.git/tools/firmware/seabios-dir-remote'
> /home/SOURCES/xen/xen.git/tools/firmware/../../tools/Rules.mk:218: recipe for
> target 'subdir-all-seabios-dir' failed
>
> Seabios folks may be aware of this already, as it looks very similar to
> this:
> https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1463516.html
>
> And even more to this:
> https://lists.debian.org/debian-gcc/2016/10/msg00147.html
>
> A colleague of mine (Cc-ed) said in chat that gcc 6.2.1 (don't know on
> what distro) seems to build all fine.
The SeaBIOS build was updated to work around this with commit
99e3316d59. What version of SeaBIOS are you attempting to build?
-Kevin
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [SeaBIOS] [PATCH] Make CONFIG_ATA_DMA and CONFIG_ATA_PIO32 default on
On Mon, May 11, 2015 at 01:47:57PM +0100, Paul Durrant wrote: > Currently running make defconfig will leave the above turned off which, > at least for the Xen/QEMU use-case, means VMs will boot very slowly. > There seems to have been some concern over non-QEMU use of ATA_DMA about > five years ago, but I can find no particular concern over ATA_PIO32. > Given the increased use of QEMU and Xen in that period it would seem > like a good idea to default both of these on now. This patch does that. The DMA support is known to be not correct for real hardware - correct code would negotiate the DMA rate with the drive (and also do things like detecting a 66Mhz PATA cable). The code is only really useful on emulators and when one knows that the drive is really a SATA drive connected to a controller that is doing PATA emulation. The 32bit PIO mode has a minimal speed improvement and it is known to not work on some real hardware controllers. If one is concerned about VM boot speed, why not just use AHCI or virtio? -Kevin ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v10 3/6] Support for BIOS interrupt handler
On Thu, Apr 30, 2015 at 11:34:20AM -0400, Stefan Berger wrote: > On 04/30/2015 09:21 AM, Xu, Quan wrote: > > > >Stefan, > > Sorry to reply so late to you. I try to make it compatible with Xen > > vTPM by below patch > >Against your serious of > >patch(https://github.com/KevinOConnor/seabios/tree/tcg-testing ). > >Also I have tested this patch, which is working. [...] > > Kevin, I think this should be good to add after 3/6 ? Thanks - I applied the first three tpm patches along with this patch. -Kevin ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Qemu-devel] [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks
On Tue, Feb 02, 2016 at 09:56:20AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > I'd have qemu copy the data on 0xfc write then, so things continue to
> > > work without updating seabios. So, the firmware has to allocate space,
> > > reserve it etc., and programming the 0xfc register. Qemu has to make
> > > sure the opregion appears at the address written by the firmware, by
> > > whatever method it prefers.
> >
> > Yup. It's Qemu's responsibility to expose opregion content.
> >
> > btw, prefer to do copying here. It's pointless to allow write from guest
> > side. One write example is SWSCI mailbox, thru which gfx driver can
> > trigger some SCI event to communicate with BIOS (specifically ACPI
> > methods here), mostly for some monitor operations. However it's
> > not a right thing for guest to trigger host SCI and thus kick host
> > ACPI methods.
>
> Thanks.
>
> So, question again how we do that best. Option one being the mmap way,
> i.e. basically what the patches posted by alex are doing. Option two
> being the fw_cfg way, i.e. place a opregion copy in fw_cfg and have
> seabios not only set 0xfc, but also store the opregion there by copying
> from fw_cfg.
What about option 2a - SeaBIOS copies from fw_cfg to memory and then
programs 0xfc. QEMU can detect the write to 0xfc and choose to map
that ram (thus completely ignoring the contents that were just copied
in) or it can choose not to map that ram (thus guest uses the contents
just copied in).
The advantage of this approach is that it is a bit simpler in the
firmware (no size probing is needed as the size comes from fw_cfg) and
it allows for future flexibility as the choice of mapping can be
deferred.
Totally untested seabios code below as example.
As an aside, if this type of "program a pci register" with a memory
address becomes common, we could enhance the acpi-style "linker
script" system to automate this..
-Kevin
static void intel_igd_opregion_setup(struct pci_device *dev, void *arg)
{
struct romfile_s *file = romfile_find("etc/igd-opregion");
if (!file)
return;
void *data = memalign_high(PAGE_SIZE, file->size);
if (!data) {
warn_noalloc();
return;
}
int ret = file->copy(file, data, file->size);
if (ret < 0) {
free(data);
return;
}
pci_config_writel(dev->bdf, 0xFC, (u32)data);
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] SeaBios/vTPM: Enable Xen stubdom vTPM for HVM virtual machine
On Tue, Mar 10, 2015 at 08:16:03AM -0400, Quan Xu wrote: > This patch series are only the SeaBios part to enable stubdom vTPM for HVM > virtual machine. It will work with Qemu patch series and Xen patch series. > > > *INTRODUCTION* > > The goal of virtual Trusted Platform Module (vTPM) is to provide a TPM > functionality > to virtual machines (Fedora, Ubuntu, Redhat, Windows .etc). This allows > programs > to interact with a TPM in a virtual machine the same way they interact with a > TPM > on the physical system. Each virtual machine gets its own unique, emulated, > software > TPM. Each major component of vTPM is implemented as a stubdom, providing > secure > separation guaranteed by the hypervisor. > > The vTPM stubdom is a Xen mini-OS domain that emulates a TPM for the virtual > machine > to use. It is a small wrapper around the Berlios TPM emulator. TPM commands > are passed > from mini-os TPM backend driver. Thanks. Does this seabios patch require additional seabios patches before it is useful? Does it depend on upstream patches in Xen/QEMU that are not yet committed? -Kevin ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu
On Fri, Oct 16, 2015 at 01:10:54AM +0200, Laszlo Ersek wrote: > On 10/14/15 13:27, Ian Campbell wrote: > > On Wed, 2015-10-14 at 12:06 +0100, Stefano Stabellini wrote: > >>> Can't you just teach SeaBIOS how to deal with your PV disks and then > >>> only add that to your VM and forget about IDE/AHCI? I mean, that's how > >>> it's done for virtio-blk, and it doesn't involve any insanities like > >>> ripping out non-hotpluggable devices. > >> > >> Teaching SeaBIOS to deal with PV disks can be done, in fact we already > >> support PV disks in OVMF. It is possible to boot Windows with OVMF > >> without any IDE disks (patch pending for libxl to create a VM without > >> emulated IDE disks). > > > > One stumbling block in the past has been how to know when the PV drivers in > > the BIOS are no longer required, such that the ring can be torn down and/or > > the connection etc handed over to the OS driver. [...] > > AFAIK the BIOS interfaces do not have anything as reliable as that. > > > > How does virtio deal with this in the BIOS case? > > It doesn't, as far as I can tell. > > I don't think it has to, though! On a BIOS box, you can always boot DOS, > or another operating system that continues to use the BIOS interfaces > forever. (Same as if you never call ExitBootServices() in UEFI.) > > Given that no starter pistol gets fired between the firmware and the OS > on such a platform, they must always respect each other. I guess this > could occur through the E820 map, or some such. One can use the "ACPI enable" SMI event to detect this if they really wanted to. In SeaBIOS one could do this from src/fw/smm.c:handle_smi() - however, no other drivers need this notification today and it would be a bit ugly to have to handle it from an SMI. (Assuming Xen were to support SMIs.) > No clue in what kind of E820 memory SeaBIOS allocates the virtio rings, > but I guess the Linux kernel stays away from those areas until it's past > device probing and binding. In SeaBIOS, the virtio memory is allocated from reserved memory. (See the memalign_high() call in src/hw/virtio-pci.c - the "high" memory zone is taken from reserved memory: http://seabios.org/Memory_Model#Memory_available_during_initialization ) What's the reason for the "stumbling block" that requires the BIOS to tear down the Xen ring prior to the OS being able to replace it? The BIOS disk calls are all synchronous, so the ring wont be active when the OS brings up its own ring. Is there some low-level interaction that prevents the OS from just resetting the ring prior to enabling it? -Kevin ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu
On Fri, Oct 16, 2015 at 10:06:48AM +0100, Stefano Stabellini wrote: > On Thu, 15 Oct 2015, Kevin O'Connor wrote: > > What's the reason for the "stumbling block" that requires the BIOS to > > tear down the Xen ring prior to the OS being able to replace it? The > > BIOS disk calls are all synchronous, so the ring wont be active when > > the OS brings up its own ring. Is there some low-level interaction > > that prevents the OS from just resetting the ring prior to enabling > > it? > > Xen only exports one PV disk interface for each disk to the guest, and > each PV interface only supports one frontend -- only SeaBIOS or the OS > can be connected to one PV disk, not both. In the case of OVMF, we > handle that by disconnecting the PV frontend in OVMF when > ExitBootServices is called, so that the OS driver can reconnect later. Well, there isn't a requirement for both SeaBIOS and the OS to be connected at the same time - it's fine for the OS to replace SeaBIOS. With the hardware I'm familiar with (eg, usb, ahci, virtio) the OS just ends up replacing SeaBIOS' DMA rings when it configures its own. I guess something in the low-level interface of Xen makes that not work. Is plugging/unplugging very high overhead? Since the SeaBIOS disk interface is fully synchronous, in theory one could have it plug/unplug on every read request. -Kevin ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v10 3/6] Support for BIOS interrupt handler
On Mon, Mar 30, 2015 at 05:09:47AM +, Xu, Quan wrote: > > From: Stefan Berger [mailto:stef...@linux.vnet.ibm.com] > > On 03/27/2015 03:58 AM, Xu, Quan wrote: > > >> From: Xu, Quan > > >>> From: Stefan Berger [mailto:stef...@linux.vnet.ibm.com] > > >>> On 03/26/2015 07:01 AM, Xu, Quan wrote: > > >>>>> From: Stefan Berger [mailto:stef...@linux.vnet.ibm.com] > > >>>>> On 03/25/2015 06:42 PM, Kevin O'Connor wrote: > > >>>>>> On Tue, Mar 24, 2015 at 11:10:03AM -0400, Stefan Berger wrote: > > >>>>>>> On 03/23/2015 08:13 PM, Kevin O'Connor wrote: > > >>>>>>>> Because of the mixed 16bit/32bit code in SeaBIOS, all assembler > > >>>>>>>> must use size suffixes - so the above should be "roll" instead of > > >>>>>>>> "rol". > > >>>>>>> Ok, fixed. > > >>>>>>> > > >>>>>>>> As before - both issues are minor and can be addressed after > > >>>>>>>> merge (as long as there is agreement that the sha1.c file can > > >>>>>>>> be licensed as LGPLv3). > > >>>>>>> It can have that license. I can post v11 or you can modify it, > > >>>>>>> either way is fine. > > >>>>>> Thanks. I pushed the first three patches into a test branch at: > > >>>>>> > > >>>>>> https://github.com/KevinOConnor/seabios/tree/tcg-testing > > >>>>>> > > >>>>>> I'd like to get confirmation that this works for the Xen > > >>>>>> requirements before merging. > > >>>>> I don't use Xen. I hope that Quan will provide feedback. > > >>>>> > > >>>>> Stefan > > >>>> Sure, I am glad to help you test it :):) Try to > > >>>> https://github.com/KevinOConnor/seabios/tree/tcg-testing ?? > > >>> Yes. [...] > I will go through all of these seabios patch, and try to make it compatible > for Xen vTPM. > What's the status of this? Is it safe to push forward parts of Stefan's patches, or does that represent a regression for Xen? -Kevin ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
