qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* need help with ACPI generic port implementation for QEMU
@ 2023-03-13 21:58 Dave Jiang
  2023-03-28 12:00 ` Igor Mammedov
  0 siblings, 1 reply; 2+ messages in thread
From: Dave Jiang @ 2023-03-13 21:58 UTC (permalink / raw)
  To: qemu-devel; +Cc: Jonathan Cameron, Ira Weiny, Michael Tsirkin, Ben Widawsky

I'm attempting to implement the support of ACPI "generic port" detailed 
in the ACPI r6.5 spec in QEMU. The spec section 5.2.16.7 details the 
Generi Port Affinity Structure where it ties a Device Handle to a 
Proximity Domain. And with section 6.2.28.4 for the HMAT table, the 
latency and bandwidth information are provided by the System Locality 
Latency and Bandwidth Information Structure (SLLBIS) sub-table.

In the CXL world, a hotplugged type-3 device would not have the 
approriate end to end latency and bandwidth data provided by the HMAT. 
The QoS data needs to be computed from the CXL host bridge (HB) and the 
endpoint device. Some parts of the data are supplemented by the CDAT 
from the endpoint device and the CXL switch(es) if they exist in the 
path. The component missing is the path between the CPU and the CXL HB 
(generic port). The data provided by HMAT for generic port will fill 
that gap.

In QEMU, the SRAT is generated by code and the table entry addition is a 
somewhat straight forward implementation. The HMAT information is fed 
through user parameter inputs and will require a new object to allow the 
representation of generic port. The intention is to be able to do 
something like:
"-object genport,id=genport0"
"-numa node,genport=genport0,nodeid=5,initiator=0"
"-numa dist,src=0,dst=5,val=$dist"
"-numa 
hmat-lb,initiator=0,target=5,hierachy=memory,data-type=access-latency,latency=$lat"
"-numa 
hmat-lb,initiator=0,target=5,hierarchy=memory,data-type=access-bandwidth,bandwidth=$bw"

I put together a skeletal generic port device that seems to pass the 
numa parsing code parts. However I'm hitting an error after that that I 
can't figure out how to deal with:
qemu-system-x86_64: ../hw/core/qdev.c:316: 
qdev_assert_realized_properly_cb: Assertion `dev->realized' failed.

At what point is qdev_realize() being called for a device object? It 
seems that this never happens for this generic port device. What am I 
missing in terms of initialization or setup? Any assistance is 
appreciated. Thanks in advance. Here's my latest code that I'm playing 
with as reference:
https://github.com/davejiang/qemu/tree/genport







^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: need help with ACPI generic port implementation for QEMU
  2023-03-13 21:58 need help with ACPI generic port implementation for QEMU Dave Jiang
@ 2023-03-28 12:00 ` Igor Mammedov
  0 siblings, 0 replies; 2+ messages in thread
From: Igor Mammedov @ 2023-03-28 12:00 UTC (permalink / raw)
  To: Dave Jiang
  Cc: qemu-devel, Jonathan Cameron, Ira Weiny, Michael Tsirkin,
	Ben Widawsky

On Mon, 13 Mar 2023 14:58:42 -0700
Dave Jiang <dave.jiang@intel.com> wrote:

> I'm attempting to implement the support of ACPI "generic port" detailed 
> in the ACPI r6.5 spec in QEMU. The spec section 5.2.16.7 details the 
> Generi Port Affinity Structure where it ties a Device Handle to a 
> Proximity Domain. And with section 6.2.28.4 for the HMAT table, the 
> latency and bandwidth information are provided by the System Locality 
> Latency and Bandwidth Information Structure (SLLBIS) sub-table.
> 
> In the CXL world, a hotplugged type-3 device would not have the 
> approriate end to end latency and bandwidth data provided by the HMAT. 
> The QoS data needs to be computed from the CXL host bridge (HB) and the 
> endpoint device. Some parts of the data are supplemented by the CDAT 
> from the endpoint device and the CXL switch(es) if they exist in the 
> path. The component missing is the path between the CPU and the CXL HB 
> (generic port). The data provided by HMAT for generic port will fill 
> that gap.
> 
> In QEMU, the SRAT is generated by code and the table entry addition is a 
> somewhat straight forward implementation. The HMAT information is fed 
> through user parameter inputs and will require a new object to allow the 
> representation of generic port. The intention is to be able to do 
> something like:
> "-object genport,id=genport0"
> "-numa node,genport=genport0,nodeid=5,initiator=0"
> "-numa dist,src=0,dst=5,val=$dist"
> "-numa 
> hmat-lb,initiator=0,target=5,hierachy=memory,data-type=access-latency,latency=$lat"
> "-numa 
> hmat-lb,initiator=0,target=5,hierarchy=memory,data-type=access-bandwidth,bandwidth=$bw"
> 
> I put together a skeletal generic port device that seems to pass the 
> numa parsing code parts. However I'm hitting an error after that that I 
> can't figure out how to deal with:
> qemu-system-x86_64: ../hw/core/qdev.c:316: 
> qdev_assert_realized_properly_cb: Assertion `dev->realized' failed.
> 
> At what point is qdev_realize() being called for a device object? It 
> seems that this never happens for this generic port device. What am I 
> missing in terms of initialization or setup? Any assistance is 
> appreciated. Thanks in advance. Here's my latest code that I'm playing 
> with as reference:
> https://github.com/davejiang/qemu/tree/genport

Pls, send an RFC series to qemu-devel to start discussion



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2023-03-28 12:01 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-03-13 21:58 need help with ACPI generic port implementation for QEMU Dave Jiang
2023-03-28 12:00 ` Igor Mammedov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).