On Thu, Nov 25, 2021 at 08:43:55AM +, Wang, Wei W wrote:
> On Thursday, November 25, 2021 2:38 PM, Jason Wang wrote:
> > > We thought about virtio-mmio. There are some barriers:
> > > 1) It wasn't originally intended for x86 machines. The only machine
> > > type in QEMU that supports it (to run
On Thursday, November 25, 2021 2:38 PM, Jason Wang wrote:
> > We thought about virtio-mmio. There are some barriers:
> > 1) It wasn't originally intended for x86 machines. The only machine
> > type in QEMU that supports it (to run on x86) is microvm. But
> > "microvm" doesn’t support TDX currently,
On Thu, Nov 11, 2021 at 3:59 PM Wang, Wei W wrote:
>
> On Wednesday, November 10, 2021 6:50 PM, Michael S. Tsirkin wrote:
> > On Wed, Nov 10, 2021 at 07:12:36AM +, Wang, Wei W wrote:
> >
> > hypercalls are fundamentally hypervisor dependent though.
>
> Yes, each hypervisor needs to support it.
On Thu, Nov 11, 2021 at 07:58:29AM +, Wang, Wei W wrote:
> On Wednesday, November 10, 2021 6:50 PM, Michael S. Tsirkin wrote:
> > On Wed, Nov 10, 2021 at 07:12:36AM +, Wang, Wei W wrote:
> >
> > hypercalls are fundamentally hypervisor dependent though.
>
> Yes, each hypervisor needs to sup
On 11/11/21 09:14, Wang, Wei W wrote:
Adding Andra and Sergio, because IIRC Firecracker and libkrun
emulates virtio-vsock with virtio-mmio so the implementation
should be simple and also not directly tied to a specific VMM.
OK. This would be OK for KVM based guests. For Hyperv and VMWare
based
On Wednesday, November 10, 2021 7:17 PM, Stefano Garzarella wrote:
> Adding Andra and Sergio, because IIRC Firecracker and libkrun emulates
> virtio-vsock with virtio-mmio so the implementation should be simple and also
> not directly tied to a specific VMM.
>
OK. This would be OK for KVM based
> From: Stefan Hajnoczi
On Wednesday, November 10, 2021 5:35 PM, Stefan Hajnoczi wrote:
> AF_VSOCK is designed to allow multiple transports, so why not. There is a cost
> to developing and maintaining a vsock transport though.
Yes. The effort could be reduced via simplifying the design as much as
On Wednesday, November 10, 2021 6:50 PM, Michael S. Tsirkin wrote:
> On Wed, Nov 10, 2021 at 07:12:36AM +, Wang, Wei W wrote:
>
> hypercalls are fundamentally hypervisor dependent though.
Yes, each hypervisor needs to support it.
We could simplify the design and implementation to the minimal,
On Wed, Nov 10, 2021 at 07:12:36AM +, Wang, Wei W wrote:
Hi,
We plan to add a new vsock transport based on hypercall (e.g. vmcall on Intel
CPUs).
It transports AF_VSOCK packets between the guest and host, which is similar to
virtio-vsock, vmci-vsock and hyperv-vsock.
Compared to the above
On Wed, Nov 10, 2021 at 07:12:36AM +, Wang, Wei W wrote:
> Hi,
>
>
>
> We plan to add a new vsock transport based on hypercall (e.g. vmcall on Intel
> CPUs).
>
> It transports AF_VSOCK packets between the guest and host, which is similar to
>
> virtio-vsock, vmci-vsock and hyperv-vsock.
>
On Wed, Nov 10, 2021 at 07:12:36AM +, Wang, Wei W wrote:
> We plan to add a new vsock transport based on hypercall (e.g. vmcall on Intel
> CPUs).
> It transports AF_VSOCK packets between the guest and host, which is similar to
> virtio-vsock, vmci-vsock and hyperv-vsock.
>
> Compared to the a
11 matches
Mail list logo
