Samuel Ortiz

That's very nice, thanks a lot @stevenhorsman !

> * Samuel Ortiz: did not attend the meeting I agree with the proposal, thanks for bringing that up @fidencio

> In the short term you would embed the measurement(s) inside the `DMTFSpecMeasurementValue` field. The measurement manifest would then specify that the measurement block(s) is EAT, etc. How would that...

> It's cleaner to allocate a bit in MeasurementSpecification for EAT in SPDM 1.4 than trying to using DMTF format to hold EAT. > > Is the need of supporting...

@steven-bellock I believe 64 KiB would be plenty for a large majority of EATs. Having to split EATs across multiple measurement blocks would be an exception.

cc @jodh-intel @grahamwhaley @mcastelino @sboeuf @egernst

@mcastelino > If the ksm daemon were to rely on the source just for kicks (completely agnostic of the reason for the kick) So the kick is the `CREATED` event...

@grahamwhaley > I suspect for phase1 we can just use the info in the sys ksm files Let me try to understand: For phase 1 you're suggesting we don't even...

I'm also researching how we could trace (perf events) `madvise`...

_From @laijs on December 4, 2016 23:46_ the virtio-serial is not package based transport, it seams hard to find the message header when cc-proxy re-connect to hyperstart.