Date   

Re: "edk2-discuss" list settings change

Mayur Gudmeti
 

On Wed, May 27, 2020 at 02:16 PM, Laszlo Ersek wrote:


Laszlo
Hi laszlo,

I have newly joined this discuss@edk2.groups.io group. I posted a comment on this thread https://edk2.groups.io/g/discuss/topic/74206642#228 couple of days back. But do not see my comment here. Can you please let me know what is the issue here.

Thanks,
Mayur


Haiku's ARM efi bootloader

Alexander von Gluck IV
 

Good morning!

I'm getting a bit desperate, so posting here for any ideas :-)
I've been working on porting Haiku's x86_64 EFI bootloader over to ARM.

We're super close, but have been hung up for a while with the following.

We can successfully make a call to EFI's runtime services (printing hello for example)
However, the second call to EFI always hangs with similar errors.

In the example below i'm booting as a cd, but sd card, etc suffer the same fate.

qemu boot:
qemu-system-arm -bios /usr/share/edk2/arm/QEMU_EFI.fd -M virt -cdrom haiku-mmc.image -m 2048

[Bds]Booting UEFI Misc Device 2
BlockSize : 512
LastBlock : A5FFF
FatDiskIo: Cache Page OutBound occurred!
FSOpen: Open '\EFI\BOOT\BOOTARM.EFI' Success
[Bds] Expand PciRoot(0x0)/Pci(0x2,0x0) -> PciRoot(0x0)/Pci(0x2,0x0)/HD(1,MBR,0x00000000,0x9FF6,0x1D394)/\EFI\BOOT\BOOTARM.EFI
BdsDxe: loading Boot0002 "UEFI Misc Device 2" from PciRoot(0x0)/Pci(0x2,0x0)
[Security] 3rd party image[0] can be loaded after EndOfDxe: PciRoot(0x0)/Pci(0x2,0x0)/HD(1,MBR,0x00000000,0x9FF6,0x1D394)/\EFI\BOOT\BOOTARM.EFI.
InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B BD994928
Loading driver at 0x000BC570000 EntryPoint=0x000BC570138
Loading driver at 0x000BC570000 EntryPoint=0x000BC570138
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF BEFFD290
ProtectUefiImageCommon - 0xBD994928
- 0x00000000BC570000 - 0x000000000004A4E4
!!!!!!!! ProtectUefiImageCommon - Section Alignment(0x20) is incorrect !!!!!!!!
BdsDxe: starting Boot0002 "UEFI Misc Device 2" from PciRoot(0x0)/Pci(0x2,0x0)

Data Abort Exception PC at 0xBC570D34 CPSR 0x60000013
Data Abort Exception PC at 0xBC570D34 CPSR 0x60000013 nZCveaift_svc

R0 0xBFA58F10 R1 0x00043028 R2 0x0003C088 R3 0x00800080
R4 0xBFA58010 R5 0xBD994790 R6 0xBC5AC088 R7 0x00043030
R8 0x00000001 R9 0xBEFFD4D8 R10 0x00000000 R11 0x00000000
R12 0xBFA9ACC0 SP 0xBFA7A9F8 LR 0xBC5709A4 PC 0xBC570D34
DFSR 0x00000005 DFAR 0x008000AC IFSR 0x00000000 IFAR 0x00000000
Translation fault on Section: read from 0x008000AC

ASSERT [ArmCpuDxe] /builddir/build/BUILD/edk2-edk2-stable202002/ArmPkg/Library/DefaultExceptionHandlerLib/Arm/DefaultExceptionHandler.c(267): ((BOOLEAN)(0==1))



$ ~/Code/efi_analyzer/efianalyze ./objects/haiku/arm/release/system/boot/efi/haiku_loader.efi
Offset to PE: 0x40
Machine type: 0x01c2, ARM or Thumb ("interworking")
NumberOfSymbols should be 0.
Characteristics: 0x0306
* The file is executable.
* COFF line numbers were stripped from the file.
* The computer supports 32-bit words.
* Debugging information was removed.
Image type: PE32
Size of optional header: 0x90 != 0xe0
Subsystem: EFI application
ImageBase: 0x0
SectionAlignment: 0x20
SizeOfImage: 0x4a4e4
.reloc.address: 0x0
.reloc.size: 0x0
BaseOfCode: 0x138
AddressOfEntryPoint: 0x138
Number of sections: 2
Section[0]: .reloc
Virtual size: 0x0
Virtual address: 0x0
Size of raw data: 0x0
Pointer to raw data: 0x0
End of raw data: 0x0
Characteristics: 0x42100040
* The section contains initialized data.
* Align data on a 1-byte boundary.
* The section can be discarded as needed.
* The section can be read.
Section[1]: .text
Virtual size: 0x4a300
Virtual address: 0x138
Size of raw data: 0x4a3ac
Pointer to raw data: 0x138
End of raw data: 0x4a4e4
Characteristics: 0xe0500020
* The section contains executable code.
* Align data on a 1-byte boundary.
* Align data on a 8-byte boundary.
* The section can be executed as code.
* The section can be read.
* The section can be written to.



Relevant sources:

Linker script:
https://git.haiku-os.org/haiku/tree/src/system/ldscripts/arm/boot_loader_efi.ld
Our "fake" Pe:
https://git.haiku-os.org/haiku/tree/src/system/boot/platform/efi/arch/arm/crt0-efi-arm.S
Relocations:
https://git.haiku-os.org/haiku/tree/src/system/boot/platform/efi/arch/arm/relocation_func.cpp
Our efi_main:
https://git.haiku-os.org/haiku/tree/src/system/boot/platform/efi/start.cpp#n171



Nightly ARM build with latest compiled code (it will autoboot in qemu due to EFI/BOOT/BOOTARM.EFI)
https://s3.wasabisys.com/haiku-nightly/arm/haiku-master-hrev54358-arm-mmc.zip


Any help (no matter how minor) would be appreciated!

Thanks!

-- Alex


About edk2-platforms release

Huangming (Mark) <huangming23@...>
 

Hi Martin, Leif,

 

Right now we are using edk2-platforms open source code as a part to build our ARM platform UEFI implementations.

Due to our production development work flow, we need to upload a formal edk2-platforms open source release tar ball

to our company database as a reference.

As edk2-platforms doesn’t have release, it is hard for us to explain to company audit office where the code comes from

and why this open source doesn’t have release.

 

So is it possible to release edk2-platforms just like edk2 release every three months?

 

Thanks,

Ming


Re: [RFC/Discussion]: StandAloneMM in OP-TEE

Mayur Gudmeti
 

Hi Sahil,

This proposal interests us too. Got a question for you. I assume that OPTEE-STMM interfaces will be based on SPCI specifications, both in secure and non-secure side. Is that assumption right?


Build UEFI application

Peter Wiehe <info@...>
 

Hi, all!
I have built EDK II and then OVMF. Now I want to develop an UEFI application with EDK II. Is there any documentation about that?

Greetings
Peter


Qemu command

Peter Wiehe <info@...>
 

Hello,

can You tell me what qemu command is used to run OVMF?


Thanks in advance

Peter


Re: "edk2-discuss" list settings change

Laszlo Ersek
 

Hello Mayur,

On 06/24/20 17:21, mgudmeti@nvidia.com wrote:
On Wed, May 27, 2020 at 02:16 PM, Laszlo Ersek wrote:


Laszlo
Hi laszlo,

I have newly joined this discuss@edk2.groups.io group. I posted a comment on this thread https://edk2.groups.io/g/discuss/topic/74206642#228 couple of days back. But do not see my comment here. Can you please let me know what is the issue here.
Thanks for the heads-up.

For some reason, I still do not receive moderation notifications from
groups.io, for the edk2-discuss mailing list. I receive such
notifications for edk2-devel, and I check the pending messages there
every day. But I'm left in the dark about edk2-discuss :(

And now that I'm checking it, I'm seeing your message (I'll approve it
in a moment) -- what's more, I'm seeing 5 more stuck messages, the
oldest one dating back to Jun 17.

That's terrible :(

I'm really sorry. I don't know how we can fix this problem with
edk2-discuss.

I have now sent an email to <support@groups.io>, with subject

not receiving "Message Approval Needed" notifications for edk2-discuss

Hopefully this will improve in the near future.

Thanks
Laszlo


Re: ReadSaveStateRegister/WriteSaveStateRegister functions

Laszlo Ersek
 

On 06/24/20 10:53, mzktsn@gmail.com wrote:
Hello,

I have noticed some functions that provide access
in the CPU Saved State Registers (ReadSaveStateRegister/WriteSaveStateRegister() etc.)
Would like to ask if it is possible to use their functionality from code
inside /MdeModulePkg/Core/PiSmmCore/PiSmmCore.c file? And what modifications should be
made in order to achieve it if is viable?
Not sure *why* you'd like to access specific registers from the SMM save
state map in PiSmmCore.

But, these functions are exposed though a standard interface too; see
EFI_SMM_CPU_PROTOCOL (or rather "EFI_MM_CPU_PROTOCOL") in the PI spec,
volume 4, section "4.3 CPU Save State Access Services".

In edk2, PiSmmCpuDxeSmm provides the protocol; the member functions are
delegated to the platform's SmmCpuFeaturesLib instance, and there are
general fallback implementations too.

See for example SmmReadSaveState() in
"UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c":

Status = SmmCpuFeaturesReadSaveStateRegister (CpuIndex, Register,
Width, Buffer);
if (Status == EFI_UNSUPPORTED) {
Status = ReadSaveStateRegister (CpuIndex, Register, Width, Buffer);
}
return Status;

where SmmCpuFeaturesReadSaveStateRegister() comes from the platform's
library instance, and ReadSaveStateRegister() is the generic/fallback
code, from "UefiCpuPkg/PiSmmCpuDxeSmm/SmramSaveState.c".

Generally speaking, in a module that's different from PiSmmCpuDxeSmm,
you could introduce a depex or a protocol notify on
EFI_SMM_CPU_PROTOCOL, and use its member functions.

Whether that applies *specifically* to PiSmmCore, I can't say. (Again I
don't know *why* you need that functionality there.)

Probably best to address the PiSmmCore owners directly; run the
following command in edk2:

$ python BaseTools/Scripts/GetMaintainer.py \
-l MdeModulePkg/Core/PiSmmCore/PiSmmCore.c

MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
Jian J Wang <jian.j.wang@intel.com>
Hao A Wu <hao.a.wu@intel.com>
Eric Dong <eric.dong@intel.com>
Ray Ni <ray.ni@intel.com>
devel@edk2.groups.io

I've added those people to the CC list now.

General hint: when posting a query (to any technical mailing list,
really), always include the "why", not just the "what" / "how".

Thanks
Laszlo


Re: Question regarding different commands when triggering a SW-SMI

mzktsn@...
 

Thanks a lot.


Re: Does the Ovmf debug lib work at runtime?

Hantke, Florian <florian.hantke@...>
 

Great, thank you,I will try it out later.

Best
Florian


Re: Does the Ovmf debug lib work at runtime?

Laszlo Ersek
 

On 06/14/20 21:23, Hantke, Florian wrote:
Hello everyone,

I am trying some runtime things and I was wondering if the Ovmf debug
lib (with Qemu) works at runtime?
Yes. For example, the following patch:

diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
index 1e71fc642c76..ab77e023d63f 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
@@ -2353,6 +2353,8 @@ VariableServiceGetVariable (
VARIABLE_POINTER_TRACK Variable;
UINTN VarDataSize;

+ DEBUG ((DEBUG_INFO, "%a:%d\n", __FUNCTION__, __LINE__));
+
if (VariableName == NULL || VendorGuid == NULL || DataSize == NULL) {
return EFI_INVALID_PARAMETER;
}

generates a bunch of output lines (on the QEMU debug console) every time I run "efibootmgr" in the guest.

Thanks
Laszlo


I put some debug functions in MdePkg/Library/UefiRuntimeLib/RuntimeLib.c
and in the exit_boot_services/virtual_address_change events of my basic
runtime driver.
Looking at the debug output I can see that the last message is my debug
from virtual_address_change.
Running a Ubuntu 20.04 in the VM I would expect some output from the
runtimeLib when the system runs, for instance getVariable.
At least in this blog post [1] Ubuntu called the runtimeLib.

Could it be that I mistake something or that my approach is wrong?

Thank you for your help and all the best
Florian

[1] http://blog.frizk.net/2017/01/attacking-uefi-and-linux.html



Does the Ovmf debug lib work at runtime?

florian.hantke@...
 

Hello everyone,

I am trying some runtime things and I was wondering if the Ovmf debug lib (with Qemu) works at runtime?
I put some debug functions in MdePkg/Library/UefiRuntimeLib/RuntimeLib.c and in the exit_boot_services/virtual_address_change events of my basic runtime driver.
Looking at the debug output I can see that the last message is my debug from virtual_address_change.
Running a Ubuntu 20.04 in the VM I would expect some output from the runtimeLib when the system runs, for instance getVariable.
At least in this blog post [1] Ubuntu called the runtimeLib.

Could it be that I mistake something or that my approach is wrong?

Thank you for your help and all the best
Florian

[1] http://blog.frizk.net/2017/01/attacking-uefi-and-linux.html


Re: Question regarding different commands when triggering a SW-SMI

Laszlo Ersek
 

On 06/06/20 02:16, mzktsn@gmail.com wrote:
Hello,

I would like to ask, when building firmware with EDK2 for real HW(but my question is either for an qemu-emulation).
Is there any relation of what number we write to the 0xB2 IO-port?
For a relation to exist, it needs to be between multiple things (at
least two).

Above, you mention one thing only (a "number we write to the 0xB2 IO-port").

What is the *other* thing to which you want to relate the value written
to 0xB2?

In all the cases the call to SmiManage() with NULL
arguments is called,
Yes, root SMI handlers are processed every time.

so should anyone expect different behavior regarding the value written on the IOport(0xb2) when triggering
the System Management Interruption?
The effects of writing any particular command value to IO port 0xB2 are
entirely platform specific. On some platforms, it's not even IO port
0xB2 that triggers an SMI.

Two example commits:

* 17efae27acaf ("OvmfPkg/CpuHotplugSmm: introduce skeleton for CPU
Hotplug SMM driver", 2020-03-04)

This shows that value 4 for signaling a VCPU hotplug is a platform *choice*.

* 6e3c834ae47d ("SecurityPkg Tcg: Use SW SMI IO port PCD in Tpm.asl",
2020-04-21)

This shows that some platforms use an IO port different from 0xB2 for
triggering an SMI.

Thanks
Laszlo


Question regarding different commands when triggering a SW-SMI

mzktsn@...
 

Hello,

I would like to ask, when building firmware with EDK2 for real HW(but my question is either for an qemu-emulation).
Is there any relation of what number we write to the 0xB2 IO-port? In all the cases the call to SmiManage() with NULL
arguments is called, so should anyone expect different behavior regarding the value written on the IOport(0xb2) when triggering
the System Management Interruption?

Thanks


Re: Windows 2019 VM fails to boot from vhost-scsi with UEFI mode

annie li
 

On 6/3/2020 9:33 AM, Laszlo Ersek wrote:
On 06/03/20 00:19, annie li wrote:
On 6/2/2020 7:44 AM, Laszlo Ersek wrote:
On 05/29/20 16:47, annie li wrote:

I ran more tests, and found booting failure happens randomly when I
boot the VM right after it was previously terminated by Ctrl+C
directly from QEMU monitor, no matter the max_sectors is 2048, 16383
or 16384. The failing chance is about 7 out of 20.

So my previous statement about 0x4000 and 0x3FFF isn't accurate. It is
just that booting happened to succeed with 0x3FFF(16383 ), but not
with 0x4000(16384).

Also, when this failure happens, dmesg doesn't print out following
errors, vhost_scsi_calc_sgls: requested sgl_count: 2368 exceeds
pre-allocated max_sgls: 2048

This new failure is totally different issue from the one caused by max
sized I/O. For my debug log of OVMF, the biggest I/O size is only
about 1M. This means Windows 2019 didn't send out big sized I/O out
yet.

The interesting part is that I didn't see this new failure happen if I
boot the VM which was previously shutdown gracefully from inside
Windows guest.
Can you build the host kernel with "CONFIG_VHOST_SCSI=m", and repeat
your Ctrl-C test such that you remove and re-insert "vhost_scsi.ko"
after every Ctrl-C?
I am using targetcli to create SCSI lun that the VM boots from. The
vhost_scsi
module gets loaded right after I create target in /vhost. However, I
cannot remove
vhost_scsi module since then. It always complains " Module vhost_scsi is
in use"
(same even after I delete target in targetcli).
Maybe it is related to targetcli, but I didn't try other tools yet.
Can you check with "lsmod" if other modules use vhost_scsi?
lsmod shows vhost_scsi is used by 4 programs, I assume these 4 are related
to targetcli.
lsmod |grep vhost_scsi
vhost_scsi             36864  4
vhost                      53248  1 vhost_scsi
target_core_mod       380928  14 target_core_file,target_core_iblock,iscsi_target_mod,vhost_scsi,target_core_pscsi,target_core_user

I was thinking maybe these target_* modules are using vhost_scsi, then removed
following modules by modprobe -r,
target_core_file,target_core_iblock,vhost_scsi,target_core_pscsi,target_core_user
then lsmod shows "used by" down to 3 programs,
vhost_scsi             36864  3
vhost                  53248  1 vhost_scsi
target_core_mod       380928  6 iscsi_target_mod,vhost_scsi
However, others can not be removed. "rmmod --force" doesn't help either.
"dmesg |grep vhost_scsi" doesn't show much useful information either.

If you shut down QEMU gracefully, can you rmmod vhost_scsi in that case?
No, I cannot rmmod these modules right after I create target in targetcli, no matter
whether I start a VM or not. Deleting the target in targetcli doesn't help either.
Before I create target in targetcli, I can add and remove vhost_scsi module. The
"used by" of vhost_scsi is 0.
See following steps I did right after I reboot my host,
# modprobe vhost_scsi
# lsmod |grep vhost
vhost_scsi             36864  0
vhost                  53248  1 vhost_scsi
target_core_mod       380928  1 vhost_scsi
# modprobe -r vhost_scsi
# lsmod |grep vhost
#
Right after I setup luns in targetcli, the "used by" is always 4 no matter I stop the VM
by "CTRL-C" or graceful shutdown, no matter the VM is running or not. So targetcli
is the suspect of these 4 "used by".

Thanks
Annie

I wonder if the failure to remove the vhost_scsi module is actually
another sign of the same (as yet unknown) leaked reference.

Thanks
Laszlo

My guess is that, when you kill QEMU with Ctrl-C, "vhost_scsi.ko" might
not clean up something, and that could break the next guest boot. If you
re-insert "vhost_scsi.ko" for each QEMU launch, and that ends up masking
the symptom, then there's likely some resource leak in "vhost_scsi.ko".
Nods, it is possible.

Thanks
Annie

Just a guess.

Thanks
Laszlo




Re: Windows 2019 VM fails to boot from vhost-scsi with UEFI mode

Laszlo Ersek
 

On 06/03/20 00:19, annie li wrote:
On 6/2/2020 7:44 AM, Laszlo Ersek wrote:
On 05/29/20 16:47, annie li wrote:

I ran more tests, and found booting failure happens randomly when I
boot the VM right after it was previously terminated by Ctrl+C
directly from QEMU monitor, no matter the max_sectors is 2048, 16383
or 16384. The failing chance is about 7 out of 20.

So my previous statement about 0x4000 and 0x3FFF isn't accurate. It is
just that booting happened to succeed with 0x3FFF(16383 ), but not
with 0x4000(16384).

Also, when this failure happens, dmesg doesn't print out following
errors, vhost_scsi_calc_sgls: requested sgl_count: 2368 exceeds
pre-allocated max_sgls: 2048

This new failure is totally different issue from the one caused by max
sized I/O. For my debug log of OVMF, the biggest I/O size is only
about 1M. This means Windows 2019 didn't send out big sized I/O out
yet.

The interesting part is that I didn't see this new failure happen if I
boot the VM which was previously shutdown gracefully from inside
Windows guest.
Can you build the host kernel with "CONFIG_VHOST_SCSI=m", and repeat
your Ctrl-C test such that you remove and re-insert "vhost_scsi.ko"
after every Ctrl-C?
I am using targetcli to create SCSI lun that the VM boots from. The
vhost_scsi
module gets loaded right after I create target in /vhost. However, I
cannot remove
vhost_scsi module since then. It always complains " Module vhost_scsi is
in use"
(same even after I delete target in targetcli).
Maybe it is related to targetcli, but I didn't try other tools yet.
Can you check with "lsmod" if other modules use vhost_scsi?

If you shut down QEMU gracefully, can you rmmod vhost_scsi in that case?

I wonder if the failure to remove the vhost_scsi module is actually
another sign of the same (as yet unknown) leaked reference.

Thanks
Laszlo


My guess is that, when you kill QEMU with Ctrl-C, "vhost_scsi.ko" might
not clean up something, and that could break the next guest boot. If you
re-insert "vhost_scsi.ko" for each QEMU launch, and that ends up masking
the symptom, then there's likely some resource leak in "vhost_scsi.ko".
Nods, it is possible.

Thanks
Annie


Just a guess.

Thanks
Laszlo




Re: Windows 2019 VM fails to boot from vhost-scsi with UEFI mode

annie li
 

On 6/2/2020 7:44 AM, Laszlo Ersek wrote:
On 05/29/20 16:47, annie li wrote:

I ran more tests, and found booting failure happens randomly when I
boot the VM right after it was previously terminated by Ctrl+C
directly from QEMU monitor, no matter the max_sectors is 2048, 16383
or 16384. The failing chance is about 7 out of 20.

So my previous statement about 0x4000 and 0x3FFF isn't accurate. It is
just that booting happened to succeed with 0x3FFF(16383 ), but not
with 0x4000(16384).

Also, when this failure happens, dmesg doesn't print out following
errors, vhost_scsi_calc_sgls: requested sgl_count: 2368 exceeds
pre-allocated max_sgls: 2048

This new failure is totally different issue from the one caused by max
sized I/O. For my debug log of OVMF, the biggest I/O size is only
about 1M. This means Windows 2019 didn't send out big sized I/O out
yet.

The interesting part is that I didn't see this new failure happen if I
boot the VM which was previously shutdown gracefully from inside
Windows guest.
Can you build the host kernel with "CONFIG_VHOST_SCSI=m", and repeat
your Ctrl-C test such that you remove and re-insert "vhost_scsi.ko"
after every Ctrl-C?
I am using targetcli to create SCSI lun that the VM boots from. The vhost_scsi
module gets loaded right after I create target in /vhost. However, I cannot remove
vhost_scsi module since then. It always complains " Module vhost_scsi is in use"
(same even after I delete target in targetcli).
Maybe it is related to targetcli, but I didn't try other tools yet.

My guess is that, when you kill QEMU with Ctrl-C, "vhost_scsi.ko" might
not clean up something, and that could break the next guest boot. If you
re-insert "vhost_scsi.ko" for each QEMU launch, and that ends up masking
the symptom, then there's likely some resource leak in "vhost_scsi.ko".
Nods, it is possible.

Thanks
Annie


Just a guess.

Thanks
Laszlo



Re: Windows 2019 VM fails to boot from vhost-scsi with UEFI mode

Laszlo Ersek
 

On 05/29/20 16:47, annie li wrote:

I ran more tests, and found booting failure happens randomly when I
boot the VM right after it was previously terminated by Ctrl+C
directly from QEMU monitor, no matter the max_sectors is 2048, 16383
or 16384. The failing chance is about 7 out of 20.

So my previous statement about 0x4000 and 0x3FFF isn't accurate. It is
just that booting happened to succeed with 0x3FFF(16383 ), but not
with 0x4000(16384).

Also, when this failure happens, dmesg doesn't print out following
errors, vhost_scsi_calc_sgls: requested sgl_count: 2368 exceeds
pre-allocated max_sgls: 2048

This new failure is totally different issue from the one caused by max
sized I/O. For my debug log of OVMF, the biggest I/O size is only
about 1M. This means Windows 2019 didn't send out big sized I/O out
yet.

The interesting part is that I didn't see this new failure happen if I
boot the VM which was previously shutdown gracefully from inside
Windows guest.
Can you build the host kernel with "CONFIG_VHOST_SCSI=m", and repeat
your Ctrl-C test such that you remove and re-insert "vhost_scsi.ko"
after every Ctrl-C?

My guess is that, when you kill QEMU with Ctrl-C, "vhost_scsi.ko" might
not clean up something, and that could break the next guest boot. If you
re-insert "vhost_scsi.ko" for each QEMU launch, and that ends up masking
the symptom, then there's likely some resource leak in "vhost_scsi.ko".

Just a guess.

Thanks
Laszlo


Re: Windows 2019 VM fails to boot from vhost-scsi with UEFI mode

annie li
 

On 5/28/2020 5:51 PM, Laszlo Ersek wrote:
On 05/28/20 00:04, annie li wrote:
On 5/27/2020 2:00 PM, Laszlo Ersek wrote:
(4) Annie: can you try launching QEMU with the following flag:

    -global vhost-scsi-pci.max_sectors=2048

If that works, then I *guess* the kernel-side vhost device model
could interrogate the virtio-scsi config space for "max_sectors", and
use the value seen there in place of PREALLOC_SGLS /
PREALLOC_PROT_SGLS.
I am a little confused here,
Both VHOST_SCSI_PREALLOC_SGLS(2048) and
TCM_VHOST_PREALLOC_PROT_SGLS(512) are hard coded in vhost/scsi.c.
...
sgl_count = vhost_scsi_calc_sgls(prot_iter, prot_bytes,
TCM_VHOST_PREALLOC_PROT_SGLS);
....
sgl_count = vhost_scsi_calc_sgls(data_iter, data_bytes,
VHOST_SCSI_PREALLOC_SGLS);

In vhost_scsi_calc_sgls, error is printed out if sgl_count is more than
TCM_VHOST_PREALLOC_PROT_SGLS or VHOST_SCSI_PREALLOC_SGLS.

    sgl_count = iov_iter_npages(iter, 0xffff);
    if (sgl_count > max_sgls) {
        pr_err("%s: requested sgl_count: %d exceeds pre-allocated"
               " max_sgls: %d\n", __func__, sgl_count, max_sgls);
        return -EINVAL;

    }

Looks like vhost-scsi doesn't interrogate the virtio-scsi config space for
"max_sectors". The guest virtio-scsi driver may read this configuration
out though.
Yes.

So the following flag reduces the transfer size to 8M on QEMU side.
"-global vhost-scsi-pci.max_sectors=2048"
Due to this setting, even though max ByteCount of Read(10) command in
ScsiDiskDxe/ScsiDisk.c is is 0xFFFF*0x200 = 0x1FFFE00(32M), under
EFI_BAD_BUFFER_SIZE logic, ScsiDiskDxe/ScsiDisk.c does retries and
adjust the request size <= 8M?
Yes.

The transfer size that ultimately reaches the device is the minimum of
three quantities:

(a) the transfer size requested by the caller (i.e., the UEFI application),

(b) the limit set by the READ(10) / READ(16) decision (i.e., MaxBlock),

(c) the transfer size limit enforced / reported by
EFI_EXT_SCSI_PASS_THRU_PROTOCOL.PassThru(), with EFI_BAD_BUFFER_SIZE

Whichever is the smallest from the three, determines the transfer size
that the device ultimately sees in the request.

And then *that* transfer size must satisfy PREALLOC_SGLS and/or
PREALLOC_PROT_SGLS (2048 4K pages: 0x80_0000 bytes).

In your original use case, (a) is 0x93_F400 bytes, (b) is 0x1FF_FE00
bytes, and (c) is 0x1FF_FE00 too. Therefore the minimum is 0x93_F400, so
that is what reaches the device. And because 0x93_F400 exceeds
0x80_0000, the request fails.

When you set "-global vhost-scsi-pci.max_sectors=2048", that lowers (c)
to 0x10_0000. (a) and (b) remain unchanged. Therefore the new minimum
(which finally reaches the device) is 0x10_0000. This does not exceed
0x80_0000, so the request succeeds.
Much clear now, thank you!

... In my prior email, I think I missed a detail: while the unit for
QEMU's "vhost-scsi-pci.max_sectors" property is a "sector" (512 bytes),
the unit for PREALLOC_SGLS and PREALLOC_PROT_SGLS in the kernel device
model seems to be a *page*, rather than a sector. (I don't think I've
ever checked iov_iter_npages() before.)

Therefore the QEMU flag that I recommended previously was too strict.
Can you try this instead, please?:

-global vhost-scsi-pci.max_sectors=16384
It works but run into another failure. I put details in another email.

This should set (c) to 0x80_0000 bytes. And so the minimum of {(a), (b),
{c}) will be 0x80_0000 bytes -- exactly what PREALLOC_SGLS and
PREALLOC_PROT_SGLS require.

Although Win2019 boots from vhost-scsi with above flag, I assume we still
need to enlarge the value of VHOST_SCSI_PREALLOC_SGLS in vhost-scsi for
final fix instead of setting max_sectors through QEMU options?
There are multiple ways (alternatives) to fix the issue.

- use larger constants for PREALLOC_SGLS and PREALLOC_PROT_SGLS in the
kernel;

- or replace the PREALLOC_SGLS and PREALLOC_PROT_SGLS constants in the
kernel altogether, with such logic that dynamically calculates them from
the "max_sectors" virtio-scsi config header field;

- or change the QEMU default for "vhost-scsi-pci.max_sectors", from
0xFFFF to 16384.
I prefer to fixing it in the kernel side, details are in another email too.:-)

Thanks
Annie

Either should work.

Thanks,
Laszlo



Re: Windows 2019 VM fails to boot from vhost-scsi with UEFI mode

annie li
 

On 5/28/2020 6:08 PM, Laszlo Ersek wrote:
On 05/28/20 18:39, annie li wrote:
On 5/27/2020 2:00 PM, Laszlo Ersek wrote:
(4) Annie: can you try launching QEMU with the following flag:

    -global vhost-scsi-pci.max_sectors=2048
This limits the I/O size to 1M.
Indeed -- as I just pointed out under your other email, I previously
missed that the host kernel-side unit was not "sector" but "4K page". So
yes, the value 2048 above is too strict.

The EFI_BAD_BUFFER_SIZE logic reduces
I/O size to 512K for uni-directional requests.
To send biggest I/O(8M) allowed by current vhost-scsi setting, I adjust the
value to 0x3FFF. The EFI_BAD_BUFFER_SIZE logic reduces I/O size to 4M
for uni-directional requests.
   -global vhost-scsi-pci.max_sectors=0x3FFF
OK!

0x4000 doesn't survive here.
That's really interesting.
Yup
I'm not sure why that happens.
Then I found out it is related to operations on this VM, see following.
... Is it possible that vhost_scsi_handle_vq() -- in the host kernel --
puts stuff in the scatter-gather list *other* than the transfer buffers?
Some headers and such? Maybe those headers need an extra page.
I ran more tests, and found booting failure happens randomly when I boot the VM
right after it was previously terminated by Ctrl+C directly from QEMU monitor, no
matter the max_sectors is 2048, 16383 or 16384. The failing chance is about 7 out of 20.

So my previous statement about 0x4000 and 0x3FFF isn't accurate.
It is just that booting happened to succeed with 0x3FFF(16383 ), but not with 0x4000(16384).

Also, when this failure happens, dmesg doesn't print out following errors,
vhost_scsi_calc_sgls: requested sgl_count: 2368 exceeds pre-allocated max_sgls: 2048

This new failure is totally different issue from the one caused by max sized I/O. For my
debug log of OVMF, the biggest I/O size is only about 1M. This means Windows 2019
didn't send out big sized I/O out yet.

The interesting part is that I didn't see this new failure happen if I boot the VM which
was previously shutdown gracefully from inside Windows guest.

If that works, then I *guess* the kernel-side vhost device model
could interrogate the virtio-scsi config space for "max_sectors", and
use the value seen there in place of PREALLOC_SGLS /
PREALLOC_PROT_SGLS.
You mean the vhost device on the guest side here, right? In Windows
virtio-scsi driver, it does read out max_sectors. Even though the driver
doesn't take use of it later, it can be used to adjust the transfer length
of I/O.
With vhost, the virtio-scsi device model is split between QEMU and the
host kernel. While QEMU manages the "max_sectors" property (= accepts it
from the command line, and exposes it to the guest driver), the host
kernel (i.e., the other half of the device model) ignores the same property.

Consequently, although the guest driver obeys "max_sectors" for limiting
the transfer size, the host kernel's constants may prove *stricter* than
that. Because, the host kernel ignores "max_sectors". So one idea is to
make the host kernel honor the "max_sectors" limit that QEMU manages.
This involves both changes in kernel and QEMU. I guess maybe it is more straight
that kernel controls the transfer size based on memory consumed.

The other two ideas are: use larger constants in the kernel, or use a
smaller "max_sectors" default in QEMU.
I prefer to fixing it by using larger constants in the kernel, this also avoid splitting
big sized I/O by using smaller "max_sectors"default in QEMU.
Following is the code change I did in the kernel code vhost/scsi.c,
-#define VHOST_SCSI_PREALLOC_SGLS 2048
-#define VHOST_SCSI_PREALLOC_UPAGES 2048
+#define VHOST_SCSI_PREALLOC_SGLS 2560
+#define VHOST_SCSI_PREALLOC_UPAGES 2560

Thanks
Annie

The goal behind all three alternatives is the same: the limit that QEMU
exposes to the guest driver should satisfy the host kernel.

Thanks
Laszlo

621 - 640 of 895