search for: kata

...ect: Re: [PATCH] vhost: vsock: don't send pkt when vq is not started > > > > Hi Jia, > > thanks for the patch, some comments below: > > > > On Thu, Apr 30, 2020 at 10:13:14AM +0800, Jia He wrote: > > > Ning Bo reported an abnormal 2-second gap when booting Kata container > > [1]. > > > The unconditional timeout is caused by > > VSOCK_DEFAULT_CONNECT_TIMEOUT of > > > connect at client side. The vhost vsock client tries to connect an > > > initlizing virtio vsock server. > > > > > > The abnormal flow...

...ect: Re: [PATCH] vhost: vsock: don't send pkt when vq is not started > > > > Hi Jia, > > thanks for the patch, some comments below: > > > > On Thu, Apr 30, 2020 at 10:13:14AM +0800, Jia He wrote: > > > Ning Bo reported an abnormal 2-second gap when booting Kata container > > [1]. > > > The unconditional timeout is caused by > > VSOCK_DEFAULT_CONNECT_TIMEOUT of > > > connect at client side. The vhost vsock client tries to connect an > > > initlizing virtio vsock server. > > > > > > The abnormal flow...

On Fri, May 01, 2020 at 12:38:40PM +0800, Jia He wrote: > Ning Bo reported an abnormal 2-second gap when booting Kata container [1]. > The unconditional timeout was caused by VSOCK_DEFAULT_CONNECT_TIMEOUT of > connecting from the client side. The vhost vsock client tries to connect > an initializing virtio vsock server. > > The abnormal flow looks like: > host-userspace vhost vsock...

Hi Jia, thanks for the patch, some comments below: On Thu, Apr 30, 2020 at 10:13:14AM +0800, Jia He wrote: > Ning Bo reported an abnormal 2-second gap when booting Kata container [1]. > The unconditional timeout is caused by VSOCK_DEFAULT_CONNECT_TIMEOUT of > connect at client side. The vhost vsock client tries to connect an > initlizing virtio vsock server. > > The abnormal flow looks like: > host-userspace vhost vsock...

...ngs much faster. If you emulate one of the other IOMMUs (VT-d or AMD-Vi) the code has to shadow the full page-table at once when device passthrough is used. VirtIO-IOMMU doesn't need that, and that makes it much faster and efficient. > Making ACPI meet the goals of embedded projects such as kata containers > would be a gigantic task with huge stability implications. By > comparison this 400-line parser is well contained and does the job. I > didn't yet see compelling reasons not to merge this, but I'll be > interested to see some more specific concerns. An ACPI table...

...ngs much faster. If you emulate one of the other IOMMUs (VT-d or AMD-Vi) the code has to shadow the full page-table at once when device passthrough is used. VirtIO-IOMMU doesn't need that, and that makes it much faster and efficient. > Making ACPI meet the goals of embedded projects such as kata containers > would be a gigantic task with huge stability implications. By > comparison this 400-line parser is well contained and does the job. I > didn't yet see compelling reasons not to merge this, but I'll be > interested to see some more specific concerns. An ACPI table...

...don't send pkt when vq is not started > > > > > > Hi Jia, > > > thanks for the patch, some comments below: > > > > > > On Thu, Apr 30, 2020 at 10:13:14AM +0800, Jia He wrote: > > > > Ning Bo reported an abnormal 2-second gap when booting Kata container > > > [1]. > > > > The unconditional timeout is caused by > > > VSOCK_DEFAULT_CONNECT_TIMEOUT of > > > > connect at client side. The vhost vsock client tries to connect an > > > > initlizing virtio vsock server. > > > > &gt...

...uot;. > > That is just an implementation detail. Yes, QEMU emulates the hardware > and builds the ACPI tables. But it could also be implemented in a way > where the ACPI tables are build by guest firmware. All these extra levels of indirection is one of the reasons hypervisors such as kata try to avoid ACPI. > > I don't see why it would be much faster. The interface isn't that > > different from command queues of VTD. > > VirtIO IOMMU doesn't need to build page-tables that the hypervisor then > has to shadow, which makes things much faster. If you e...

On Wed, Mar 04, 2020 at 02:34:33PM -0500, Michael S. Tsirkin wrote: > All these extra levels of indirection is one of the reasons > hypervisors such as kata try to avoid ACPI. Platforms that don't use ACPI need another hardware detection mechanism, which can also be supported. But the first step here is to enable the general case, and for x86 platforms this means ACPI. Regards, Joerg

On Tue, Mar 03, 2020 at 09:00:05AM -0500, Michael S. Tsirkin wrote: > Not necessarily. E.g. some power systems have neither. > There are also systems looking to bypass ACPI e.g. for boot speed. If there is no firmware layer between the hardware and the OS the necessary information the OS needs to run on the hardware is probably hard-coded into the kernel? In that case the same can be done

On Tue, Mar 03, 2020 at 09:00:05AM -0500, Michael S. Tsirkin wrote: > Not necessarily. E.g. some power systems have neither. > There are also systems looking to bypass ACPI e.g. for boot speed. If there is no firmware layer between the hardware and the OS the necessary information the OS needs to run on the hardware is probably hard-coded into the kernel? In that case the same can be done

On Tue, Apr 28, 2020 at 04:13:22PM +0800, Jason Wang wrote: > > On 2020/4/27 ??10:25, Stefano Garzarella wrote: > > Hi David, Michael, Stefan, > > I'm restarting to work on this topic since Kata guys are interested to > > have that, especially on the guest side. > > > > While working on the v2 I had few doubts, and I'd like to have your > > suggestions: > > > > 1. netns assigned to the device inside the guest > > > > Currently I...

Hi David, Michael, Stefan, I'm restarting to work on this topic since Kata guys are interested to have that, especially on the guest side. While working on the v2 I had few doubts, and I'd like to have your suggestions: 1. netns assigned to the device inside the guest Currently I assigned this device to 'init_net'. Maybe it is better if we allow the...

Hi David, Michael, Stefan, I'm restarting to work on this topic since Kata guys are interested to have that, especially on the guest side. While working on the v2 I had few doubts, and I'd like to have your suggestions: 1. netns assigned to the device inside the guest Currently I assigned this device to 'init_net'. Maybe it is better if we allow the...

...are no > guarantees how much memory can actually get unplugged, it depends on the > setup (especially: fragmentation of physical memory). > > I am currently getting the QEMU side into shape (which will be posted as > RFC soon, see below for a link to the current state). Experimental Kata > support is in the works [4]. Also, a cloud-hypervisor implementation is > under discussion [5]. > > -------------------------------------------------------------------------- > 1. virtio-mem > -------------------------------------------------------------------------- > >...

So I dig rspec and BDD, of course. I thought that Dave''s Google Video was a great intro () -- even if it was a bit heavy on theory and a bit loose on the nuts and bolts. But I don''t see anyone sufficiently answering the big question: What do you test? How do you define higher level and lower level behaviors that should have tests written for them?

...I don't see why it would be much faster. The interface isn't that different from command queues of VTD. > And an ACPI table is also > portable to all ACPI platforms, same with device-tree. > > Regards, > > Joerg Making ACPI meet the goals of embedded projects such as kata containers would be a gigantic task with huge stability implications. By comparison this 400-line parser is well contained and does the job. I didn't yet see compelling reasons not to merge this, but I'll be interested to see some more specific concerns. -- MST

...============================== #centos-meeting: Virtualization SIG =================================== Meeting started by sbonazzo at 16:02:28 UTC. The full logs are available athttps://www.centos.org/minutes/2023/May/centos-meeting.2023-05-03-16.02.log.html . Meeting summary --------------- * kata-containers (sbonazzo, 16:03:22) * no updates this week (sbonazzo, 16:03:29) * oVirt updates (sbonazzo, 16:04:30) * upstream developers are suggesting users to swithch to nightly builds as there are no regular releases planned (sbonazzo, 16:04:42) * LINK: https://lists.ovirt.o...

...nce wise is an open question. These questions probably should > be addressed in the documentation, spec and possible qemu code. > I also want to note that using a disk/file as memory backend with NVDIMMs in QEMU essentially results in the exact same questions we have with virtio-pmem. E.g. kata-containers use nvdimms for the rootfile system (read-only) as far as I am aware. Conceptually, a virtio-pmem device is just an emulated nvdimm device with a flush interface. And the nice thing is, that it is designed to also work on architectures that don't speak "nvdimm". > &gt...

On Mon, Apr 27, 2020 at 04:25:18PM +0200, Stefano Garzarella wrote: > Hi David, Michael, Stefan, > I'm restarting to work on this topic since Kata guys are interested to > have that, especially on the guest side. > > While working on the v2 I had few doubts, and I'd like to have your > suggestions: > > 1. netns assigned to the device inside the guest > > Currently I assigned this device to 'init_net'...