bodzhang

Does the work related to https://github.com/lsds/sgx-lkl/pull/403 address this issue?

Should this issue be added to "Clean up layering" project and bumped to P1?

Enhancing test coverage with the samples will help to discover bugs and stability issues. I think this issue should stay as P1.

#802 to re-enable ethreads=1 tests recommended as p2, shouldn't this issue also be P2?

`virto_dev`->`virtq`->`virtq_desc` contains the address/length of the buffer chain (ring buffers). ```C struct virtio_dev { uint32_t device_id; uint32_t vendor_id; uint64_t device_features; uint32_t device_features_sel; uint64_t driver_features; uint32_t driver_features_sel; uint32_t queue_sel; struct virtq*...

@davidchisnall, does the host need to modify the address of the allocated buffer chains specified in `virtq_desc` after the virtio device is initialized? If host only needs to modify `virtq`->`avail`...

OK, so the enclave code sets up the descriptors. Does the enclave code need to modify the descriptors after the descriptors are initialized? If not, the solution can be copying...

@davidchisnall, assuming the enclave code initializes the descriptor table and doesn't need to change it at run time, here is the design I'm thinking about: - The enclave code initializes...

Is [add_dev_buf_from_vring_desc(...)](https://github.com/lsds/lkl/blob/385f721b339fe48b188b4924c2663e1ea2cdeb13/tools/lkl/lib/virtio.c#L213) called inside enclave and reading buffer address/length from the share memory?

@prp , can you point me to the virtio code inside enclave?