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
