From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.120]) by mx.groups.io with SMTP id smtpd.web12.7572.1585657640087117892 for ; Tue, 31 Mar 2020 05:27:20 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=EI2qj/ws; spf=pass (domain: redhat.com, ip: 207.211.31.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1585657639; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jQ1+1OLSxobJCzyGlL7tbAtFP+9U9tfWR4uVwVMXT3Q=; b=EI2qj/wsui22ZDywgB4qY0GkDPcyVbW1PRcRntwf14r6qreocaJ4u6XtrTgC/a1dnJSm3Y 31Rlc+dc6pfaP5CaWag7tplIrhxlGF/lFvgdAbaLJNT6TRWTLSGDES+CoEVSusqWo2G5Pn ziUXnYYYCl1RFjzfjP1OXqt0kqAaKkw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-137-cHNIhoSiM7CLGs11VRWgEQ-1; Tue, 31 Mar 2020 08:27:12 -0400 X-MC-Unique: cHNIhoSiM7CLGs11VRWgEQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8FE1B8017CC; Tue, 31 Mar 2020 12:27:11 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-115-131.ams2.redhat.com [10.36.115.131]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4FEC396B85; Tue, 31 Mar 2020 12:27:10 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH] .azurepipelines: Enable CI for OvmfPkg and EmulatorPkg To: "Kinney, Michael D" , "devel@edk2.groups.io" , "ard.biesheuvel@linaro.org" , Sean Brogan References: <27599.1585523801390660294@groups.io> <39cb76cf-4c89-24dd-b03c-b2dcdf1d7af4@redhat.com> From: "Laszlo Ersek" Message-ID: <7a9d3c18-da4e-a2d5-5fdb-4e494614e8b5@redhat.com> Date: Tue, 31 Mar 2020 14:27:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 03/30/20 23:29, Kinney, Michael D wrote: > Hi Laszlo, > > I think using the QEMU feature to map a path from the host as > a FAT formatted driver has value to provision QEMU with a set > of target tests to run. I agree there is no persistent storage > of writes to this type of drive. I believe writes are supported > if file state is needed during the single boot of QEMU. > > In order to get test results out of QEMU back to the host, > I was considering the use of consoles mapped as named pipes > and send all test results out the console device and the > host can parse the logs. Yes, this should be viable. > I have not had good experiences trying to build virtual > disks, provision them, map them into QEMU, and remount > from host to collect test results. Slow operations and > cumbersome to mount/unmount from the host (at least from > Windows environments). I must agree. It is slow and somewhat cumbersome with "guestfish" too, on Linux. Guestfish, on the plus side, does not mount the disk with the host kernel, and so it doesn't need root rights. Guestfish launches a separate QEMU instance on top of the virtual disk, booting a dedicated kernel and agent (the "libguestfs appliance") in the guest. The guest appliance communicates with the "guestfish" host side command shell over virtio-serial. So the host kernel never trusts (or even sees) the filesystem structures of the guest disk image; files are exchanged between the "libguestfs appliance" (= guest kernel + agent) and the host-side command shell using a dedicated wire protocol. But, I agree it is somewhat cumbersome and slow, and I have no idea whether it works on Windows hosts. Thanks, Laszlo > > Mike > >> -----Original Message----- >> From: devel@edk2.groups.io On >> Behalf Of Laszlo Ersek >> Sent: Monday, March 30, 2020 2:11 PM >> To: devel@edk2.groups.io; ard.biesheuvel@linaro.org; Sean >> Brogan >> Subject: Re: [edk2-devel] [PATCH] .azurepipelines: Enable >> CI for OvmfPkg and EmulatorPkg >> >> On 03/30/20 08:07, Ard Biesheuvel wrote: >>> On Mon, 30 Mar 2020 at 01:16, Sean via Groups.Io >>> wrote: >>>> >>>> Ard/Laszlo or anyone familiar with QEMU. >>>> >>>> I read up on the ovmf readme and the qemu wiki but >> still have a few issues i am hoping for quick/easy >> answers. >>>> >>>> 1. How do i programmatically exit the emulator. >> Seems like uefi shell > reset just reboots. Other ideas? >>> >>> 'reset' is supposed to do that. Use 'reset -s' to kill >> the VM >>> >>>> 2. Is there an easy way to map a local file system so >> that i can setup a startup.nsh? >>>> >>> >>> As Andrew points out, use '-hda fat:' and it will >> be exposed to >>> the VM as a FAT formatted block device. >> >> Note that it will not offer (functional, or any) write >> support. >> >> I prefer "mtools" or "guestfish" for formatting and >> populating a virtual >> disk image. >> >> None of those are easy ways, admittedly -- I'm not >> offering some >> examples right now exactly because I have to sit down and >> think about >> them every time I need them. :) If there's interest in >> such commands, I >> could hack up something, but then please give me some >> specs, and I'll >> have to work on these things in the morning (while my >> brain is still not >> mush). >> >> Thanks >> Laszlo >> >> >> >