search for: katas

On Thu, Apr 30, 2020 at 10:06:26AM +0000, Justin He wrote: > Hi Stefano > > > -----Original Message----- > > From: Stefano Garzarella <sgarzare at redhat.com> > > Sent: Thursday, April 30, 2020 4:26 PM > > To: Justin He <Justin.He at arm.com> > > Cc: Stefan Hajnoczi <stefanha at redhat.com>; Michael S. Tsirkin > > <mst at

On Thu, Apr 30, 2020 at 10:06:26AM +0000, Justin He wrote: > Hi Stefano > > > -----Original Message----- > > From: Stefano Garzarella <sgarzare at redhat.com> > > Sent: Thursday, April 30, 2020 4:26 PM > > To: Justin He <Justin.He at arm.com> > > Cc: Stefan Hajnoczi <stefanha at redhat.com>; Michael S. Tsirkin > > <mst at

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

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

Hi Michael, On Tue, Mar 03, 2020 at 11:09:41AM -0500, Michael S. Tsirkin wrote: > No. It's coded into the hardware. Which might even be practical > for bare-metal (e.g. on-board flash), but is very practical > when the device is part of a hypervisor. If its that way on PPC, than fine for them. But since this is enablement for x86, it should follow the x86 platform best practices,

Hi Michael, On Tue, Mar 03, 2020 at 11:09:41AM -0500, Michael S. Tsirkin wrote: > No. It's coded into the hardware. Which might even be practical > for bare-metal (e.g. on-board flash), but is very practical > when the device is part of a hypervisor. If its that way on PPC, than fine for them. But since this is enablement for x86, it should follow the x86 platform best practices,

On Thu, Apr 30, 2020 at 06:25:21PM +0200, Stefano Garzarella wrote: > On Thu, Apr 30, 2020 at 10:06:26AM +0000, Justin He wrote: > > Hi Stefano > > > > > -----Original Message----- > > > From: Stefano Garzarella <sgarzare at redhat.com> > > > Sent: Thursday, April 30, 2020 4:26 PM > > > To: Justin He <Justin.He at arm.com> > >

On Wed, Mar 04, 2020 at 02:37:08PM +0100, Joerg Roedel wrote: > Hi Michael, > > On Tue, Mar 03, 2020 at 11:09:41AM -0500, Michael S. Tsirkin wrote: > > No. It's coded into the hardware. Which might even be practical > > for bare-metal (e.g. on-board flash), but is very practical > > when the device is part of a hypervisor. > > If its that way on PPC, than

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 > >

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 user to decide which

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 user to decide which

On 02.03.20 14:49, David Hildenbrand wrote: > This series is based on latest linux-next. The patches are located at: > https://github.com/davidhildenbrand/linux.git virtio-mem-v1 > > The basic idea of virtio-mem is to provide a flexible, > cross-architecture memory hot(un)plug solution that avoids many limitations > imposed by existing technologies, architectures, and

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?

On Tue, Mar 03, 2020 at 04:53:19PM +0100, Joerg Roedel wrote: > 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

=================================== #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

On 04.02.19 23:56, Michael S. Tsirkin wrote: > > On Wed, Jan 09, 2019 at 08:17:31PM +0530, Pankaj Gupta wrote: >> This patch series has implementation for "virtio pmem". >> "virtio pmem" is fake persistent memory(nvdimm) in guest >> which allows to bypass the guest page cache. This also >> implements a VIRTIO based asynchronous flush

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 > >