Hi Steven, On 02/23/17 06:11, Shi, Steven wrote: > Hi Laszlo, > I want to see the serial debug output and hope to save it to a local > file. How could I update the ovmf.fedora.q35.template to define it?
OVMF can be built in two ways, regarding DEBUG output: (1) The default is to direct the DEBUG output to the QEMU debug port (not the serial port). This is really easy to capture in a file. The OvmfPkg/README file documents the QEMU command line switches that serve this purpose. *However*, the domain XML template files that are attached to the Wiki article already configure this. That is, the OVMF DEBUG output is already saved in a file on your filesystem: <qemu:commandline> <qemu:arg value='-global'/> <qemu:arg value='isa-debugcon.iobase=0x402'/> <qemu:arg value='-debugcon'/> <qemu:arg value='file:/tmp/ovmf.fedora.q35.log'/> </qemu:commandline> Please refer to the file "/tmp/ovmf.fedora.q35.log" after you start the virtual machine. (2) Alternatively, the DEBUG output can be directed to the serial port of the virtual machine. This is a somewhat worse choice because it intermixes DEBUG output with terminal I/O on the serial port, but if you really want it, it can be done. For this, please build OVMF with the -D DEBUG_ON_SERIAL_PORT switch. Then, for actually seeing the serial port traffic, you can use (at least) to virtualization tools, from the libvirt toolstack: (a) when you start the guest, select View | Text Console | Serial 1 in Virt-Manager. (b) or you can start the guest from a shell, with virsh start --console --paused GUEST_NAME After you get a prompt, unpause the guest from Virt-Manager. This choice, i.e., (b) is quite useful if you want to capture the serial traffic in a file, because you can run the above "virsh" command in a "screen" session, and "screen" can be configured to save all IO to a file. ... You can also connect to the serial port of an already running domain, with virsh console GUEST_NAME You can disconnect from the console with ^] (that is, Control-<Left-Bracket>). Ultimately I think that (1) should work for you (that's what I use all the time too, for checking the OVMF debug log). Again, option (1) is already configured in the templates attached to the Wiki article; please look for the /tmp/ovmf.*.log files. Thanks, Laszlo > > > Steven Shi > Intel\SSG\STO\UEFI Firmware > > Tel: +86 021-61166522 > iNet: 821-6522 > >> -----Original Message----- >> From: Laszlo Ersek [mailto:ler...@redhat.com] >> Sent: Tuesday, February 21, 2017 6:18 PM >> To: Shi, Steven <steven....@intel.com>; edk2-devel-01 <edk2- >> de...@ml01.01.org> >> Cc: Tian, Feng <feng.t...@intel.com>; Justen, Jordan L >> <jordan.l.jus...@intel.com>; Yao, Jiewen <jiewen....@intel.com>; Kinney, >> Michael D <michael.d.kin...@intel.com>; Fan, Jeff <jeff....@intel.com>; Zeng, >> Star <star.z...@intel.com> >> Subject: Re: [edk2] Testing SMM with QEMU, KVM and libvirt >> >> On 02/21/17 10:22, Shi, Steven wrote: >>> Hi Laszlo, >>> I wonder if you could offer a Ubuntu version wiki for the >>> Testing-SMM-with-QEMU,-KVM-and-libvirt? >> >> Sorry, I can't do that. >> >> To give you a retrospective on the current article (which targets >> Fedora), writing and testing that article took ~14 hours, on an >> operating system that I'm both familiar with and can readily install in >> our internal server farm (called "Beaker"). >> >> My method was to start with a wiped-clean physical machine, install a >> fresh, clean Fedora system, and build it all up from there. I wanted to >> make sure that all missing dependencies would be thrown in my face, so I >> could explicitly document them for readers. >> >> This approach paid off very well (it caught a whole lot of dependencies >> that I "thought" would be available by default, but weren't!), but it >> was also the *primary* time sink while writing the article. >> >> "Porting" the article to another Linux distribution would mean an almost >> complete rewrite. The package names are different, the package contents >> are different, the package inter-dependencies are different, the >> virtualization tools may have different versions available, the generic >> tools may be different, and so on. >> >>> I'm trying to port your >>> steps to my Ubuntu 16.04, but meet lots of troubles. The Ubuntu >>> apt-get virsh version is too old to support smm feature in your >>> ovmf.fedora.q35.template, >> >> That's *exactly* my point. >> >>> and I have to build the new version libvirt >>> by myself. I meet lots of failures when configure the new version >>> virsh, and wonder if you could help. >> >> Sorry, I don't have time for that. I don't know Ubuntu at all, have no >> contact to Ubuntu developers, and cannot even auto-install Ubuntu easily >> on a headless server in our internal server pool. >> >> Frankly, one goal of using Fedora 25 for the host operating system was >> *exactly* that the user could avoid this kind of struggle with the >> virtualization toolstack, and they could focus on rebuilding *only* what >> was unavoidable. >> >> (It is bad enough that at the moment I must have instructions in there >> for building QEMU from source -- once QEMU 2.9 is released and Fedora 25 >> picks it up, I think I will go ahead and replace that section of the >> article, with a simple package installation command. I'll also update >> references elsewhere, such as in the domain templates.) >> >> So, unfortunately, what you are asking for is a complete rewrite of the >> article, for Ubuntu, which I don't know and have no access to, in the >> isolated server environment that is necessary for writing and testing >> such an article. >> >> I'm not trying to "push" Fedora with this -- a fresh Ubuntu release >> should be entirely suitable for this I *guess*, but the devil is in the >> details, and you'll need an Ubuntu person, with a corporate(-like) >> Ubuntu environment, to write that article for you. >> >> I do confirm that I intend to support the Fedora setup with high >> priority, so if you have questions about that, I'll do my best to answer. >> >> Thanks, >> Laszlo >> >> >>> >>> >>> >>> Steven Shi >>> Intel\SSG\STO\UEFI Firmware >>> >>> Tel: +86 021-61166522 >>> iNet: 821-6522 >>> >>> >>>> -----Original Message----- >>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >>>> Laszlo Ersek >>>> Sent: Tuesday, February 7, 2017 9:07 PM >>>> To: edk2-devel-01 <edk2-de...@ml01.01.org> >>>> Cc: Tian, Feng <feng.t...@intel.com>; Justen, Jordan L >>>> <jordan.l.jus...@intel.com>; Yao, Jiewen <jiewen....@intel.com>; Kinney, >>>> Michael D <michael.d.kin...@intel.com>; Fan, Jeff <jeff....@intel.com>; >> Zeng, >>>> Star <star.z...@intel.com> >>>> Subject: [edk2] Testing SMM with QEMU, KVM and libvirt >>>> >>>> Hi, >>>> >>>> I've added the following article to the TianoCore wiki: >>>> >>>> https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with- >>>> QEMU,-KVM-and-libvirt >>>> >>>> It should help both Windows and Linux desktop users build a KVM test >>>> machine / environment that closely resembles mine. Such an environment >>>> is useful for testing and regression-testing new MP and SMM features and >>>> bugfixes. >>>> >>>> The initial setup is not short, but once you got it up and running, it's >>>> very simple to rebuild OVMF with the edk2 changes, install the firmware >>>> binary in the right place (see the article) and then click the Play >>>> button on the Fedora 25 and Windows 10 guests, to see the changes in >> action. >>>> >>>> If you have smaller updates or structural reorgs for the document, >>>> there's no need to ask me, just go ahead and do them. >>>> >>>> If some significant information is missing that you'd like me to add, I >>>> think I'd prefer new TianoCore BZs at this time (Product: Tianocore >>>> Feature Requests, Component: Web Content, Assignee: yours truly). I >>>> don't know when I'll have time again to dig into this. >>>> >>>> Sorry if I forgot someone off the CC list. >>>> >>>> Thanks! >>>> Laszlo >>>> _______________________________________________ >>>> edk2-devel mailing list >>>> edk2-devel@lists.01.org >>>> https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel