From: "Srivatsa S. Bhat (VMware)"
The comment that says mwait_play_dead() returns only on failure is a
bit misleading because mwait_play_dead() could actually return for
valid reasons (such as mwait not being supported by the platform) that
do not indicate a failure of the CPU offline operation.
In virtnet_probe(), if the device doesn't provide a MAC address the
driver assigns a random one.
As we modify the MAC address we need to notify the device to allow it
to update all the related information.
The problem can be seen with vDPA and mlx5_vdpa driver as it doesn't
assign a MAC address
When the MAC address is not provided by the vdpa device virtio_net
driver assigns a random one without notifying the device.
The consequence, in the case of mlx5_vdpa, is the internal routing
tables of the device are not updated and this can block the
communication between two namespaces.
To fix
failover relies on the MAC address to pair the primary and the standby
devices:
"[...] the hypervisor needs to enable VIRTIO_NET_F_STANDBY
feature on the virtio-net interface and assign the same MAC address
to both virtio-net and VF interfaces."
On Fri, Jan 27, 2023 at 12:31 AM Ryan Neph wrote:
>
> An interrupted dma_fence_wait() becomes an -ERESTARTSYS returned
> to userspace ioctl(DRM_IOCTL_VIRTGPU_EXECBUFFER) calls, prompting to
> retry the ioctl(), but the passed exbuf->fence_fd has been reset to -1,
> making the retry attempt fail
On Fri, Jan 27, 2023 at 01:28:01PM +0100, Laurent Vivier wrote:
> On 1/27/23 12:08, Michael S. Tsirkin wrote:
> > On Tue, Jan 24, 2023 at 12:04:24PM +0100, Laurent Vivier wrote:
> > > On 1/24/23 11:15, Michael S. Tsirkin wrote:
> > > > On Mon, Jan 23, 2023 at 01:00:22PM +0100, Laurent Vivier
On Fri, Jan 27, 2023 at 04:17:46PM +0200, Alexander Shishkin wrote:
> Greg Kroah-Hartman writes:
>
> > On Fri, Jan 27, 2023 at 02:47:55PM +0200, Alexander Shishkin wrote:
> >> "Michael S. Tsirkin" writes:
> >>
> >> > On Fri, Jan 27, 2023 at 01:55:43PM +0200, Alexander Shishkin wrote:
> >> >>
On Fri, Jan 27, 2023 at 04:17:46PM +0200, Alexander Shishkin wrote:
> Greg Kroah-Hartman writes:
>
> > On Fri, Jan 27, 2023 at 02:47:55PM +0200, Alexander Shishkin wrote:
> >> "Michael S. Tsirkin" writes:
> >>
> >> > On Fri, Jan 27, 2023 at 01:55:43PM +0200, Alexander Shishkin wrote:
> >> >>
On Fri, Jan 27, 2023 at 02:47:55PM +0200, Alexander Shishkin wrote:
> "Michael S. Tsirkin" writes:
>
> > On Fri, Jan 27, 2023 at 01:55:43PM +0200, Alexander Shishkin wrote:
> >> "Michael S. Tsirkin" writes:
> >>
> >> > On Thu, Jan 19, 2023 at 10:13:18PM +0200, Alexander Shishkin wrote:
> >> >>
On Fri, Jan 27, 2023 at 02:47:55PM +0200, Alexander Shishkin wrote:
> "Michael S. Tsirkin" writes:
>
> > On Fri, Jan 27, 2023 at 01:55:43PM +0200, Alexander Shishkin wrote:
> >> "Michael S. Tsirkin" writes:
> >>
> >> > On Thu, Jan 19, 2023 at 10:13:18PM +0200, Alexander Shishkin wrote:
> >> >>
On 1/27/23 12:08, Michael S. Tsirkin wrote:
On Tue, Jan 24, 2023 at 12:04:24PM +0100, Laurent Vivier wrote:
On 1/24/23 11:15, Michael S. Tsirkin wrote:
On Mon, Jan 23, 2023 at 01:00:22PM +0100, Laurent Vivier wrote:
In virtnet_probe(), if the device doesn't provide a MAC address the
driver
On Fri, Jan 27, 2023 at 01:55:43PM +0200, Alexander Shishkin wrote:
> "Michael S. Tsirkin" writes:
>
> > On Thu, Jan 19, 2023 at 10:13:18PM +0200, Alexander Shishkin wrote:
> >> When handling control messages, instead of peeking at the device memory
> >> to obtain bits of the control structure,
On Fri 2023-01-27 11:37:02, Peter Zijlstra wrote:
> On Thu, Jan 26, 2023 at 08:43:55PM -0800, Josh Poimboeuf wrote:
> > On Thu, Jan 26, 2023 at 03:12:35PM -0600, Seth Forshee (DigitalOcean) wrote:
> > > On Thu, Jan 26, 2023 at 06:03:16PM +0100, Petr Mladek wrote:
> > > > On Fri 2023-01-20
On Thu 2023-01-26 15:12:35, Seth Forshee (DigitalOcean) wrote:
> On Thu, Jan 26, 2023 at 06:03:16PM +0100, Petr Mladek wrote:
> > On Fri 2023-01-20 16:12:20, Seth Forshee (DigitalOcean) wrote:
> > > We've fairly regularaly seen liveptches which cannot transition within
> > > kpatch's
> > >
On Mon, Nov 28, 2022 at 05:14:44AM -0500, Michael S. Tsirkin wrote:
> On Mon, Nov 28, 2022 at 10:10:01AM +0800, Li Zetao wrote:
> > This patchset fixes similar issue, the root cause of the
> > problem is that the virtqueues are not stopped on error
> > handling path.
>
> I've been thinking about
On Tue, Jan 24, 2023 at 12:04:24PM +0100, Laurent Vivier wrote:
> On 1/24/23 11:15, Michael S. Tsirkin wrote:
> > On Mon, Jan 23, 2023 at 01:00:22PM +0100, Laurent Vivier wrote:
> > > In virtnet_probe(), if the device doesn't provide a MAC address the
> > > driver assigns a random one.
> > > As we
On Thu, Jan 19, 2023 at 10:13:18PM +0200, Alexander Shishkin wrote:
> Greg Kroah-Hartman writes:
>
> > Then you need to copy it out once, and then only deal with the local
> > copy. Otherwise you have an incomplete snapshot.
>
> Ok, would you be partial to something like this:
>
> >From
On Fri, Jan 20, 2023 at 06:41:27PM +0200, Alexander Shishkin wrote:
> "Michael S. Tsirkin" writes:
>
> > On Thu, Jan 19, 2023 at 04:22:09PM +0100, Greg Kroah-Hartman wrote:
> >> On Thu, Jan 19, 2023 at 03:57:19PM +0200, Alexander Shishkin wrote:
> >> > In handle_control_message(), we look at the
On Wed, Jan 18, 2023 at 05:43:57PM +0100, Eugenio Pérez wrote:
> The use of set_vq_state is to indicate vdpa device the state of a virtqueue.
> In the case of split, it means the avail_idx. This is mandatory for use
> cases like live migration.
>
> However, vdpa_sim reset the vq state at
Were you going to do this?
On Wed, Jan 04, 2023 at 02:31:52PM +, Eli Cohen wrote:
> Sure, thanks!
>
> > -Original Message-
> > From: Michael S. Tsirkin
> > Sent: Wednesday, 4 January 2023 15:58
> > To: Eli Cohen
> > Cc: Yang Yingliang ; virtualization@lists.linux-
> >
On Tue, Dec 27, 2022 at 10:15:25PM +0100, Tanmay Bhushan wrote:
> >From 7eae04667ddaac8baa4812d48ef2c942cedef946 Mon Sep 17 00:00:00 2001
> From: Tanmay Bhushan <0070472...@gmail.com>
> Date: Tue, 27 Dec 2022 22:02:16 +0100
> Subject: [PATCH] vdpa: ifcvf: Do proper cleanup if IFCVF init fails
>
>
On Thu, Jan 26, 2023 at 08:43:55PM -0800, Josh Poimboeuf wrote:
> On Thu, Jan 26, 2023 at 03:12:35PM -0600, Seth Forshee (DigitalOcean) wrote:
> > On Thu, Jan 26, 2023 at 06:03:16PM +0100, Petr Mladek wrote:
> > > On Fri 2023-01-20 16:12:20, Seth Forshee (DigitalOcean) wrote:
> > > > We've fairly
On Fri, Dec 30, 2022 at 11:43:08AM +0800, Jason Wang wrote:
> On Thu, Dec 29, 2022 at 4:10 PM Michael S. Tsirkin wrote:
> >
> > On Thu, Dec 29, 2022 at 04:04:13PM +0800, Jason Wang wrote:
> > > On Thu, Dec 29, 2022 at 3:07 PM Michael S. Tsirkin
> > > wrote:
> > > >
> > > > On Wed, Dec 28, 2022
On Mon, Dec 26, 2022 at 12:12:42PM +0800, Jason Wang wrote:
> > >@@ -682,6 +553,11 @@ static int vdpasim_dma_unmap(struct vdpa_device
> > >*vdpa, unsigned int asid,
> > > if (asid >= vdpasim->dev_attr.nas)
> > > return -EINVAL;
> > >
> > >+ if (vdpasim->iommu_pt[asid]) {
On Mon, Dec 19, 2022 at 05:36:02PM +0800, Yongji Xie wrote:
> On Mon, Dec 19, 2022 at 3:33 PM Michael S. Tsirkin wrote:
> >
> > On Mon, Dec 05, 2022 at 04:41:17PM +0800, Xie Yongji wrote:
> > > Export irq_create_affinity_masks() so that some modules
> > > can make use of it to implement interrupt
On Mon, Dec 19, 2022 at 11:24:26AM +0300, Andrey Smetanin wrote:
> Sorry for the delay.
> I will send update on this week after some tests.
> 19.12.2022, 10:39, "Michael S. Tsirkin" :
Do you still plan to send something? Dropping this for now.
___
Did you say you are going to post v4 of this?
I'm dropping this from review for now.
--
MST
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On Thu, Jan 26, 2023 at 01:55:09AM +0300, Dmitry Osipenko wrote:
> Hello Thomas and Gerd,
>
> On 1/9/23 00:04, Dmitry Osipenko wrote:
> > This series:
> >
> > 1. Makes minor fixes for drm_gem_lru and Panfrost
> > 2. Brings refactoring for older code
> > 3. Adds common drm-shmem memory
On Thu, Jan 26, 2023 at 03:24:30PM +0300, Dmitry Osipenko wrote:
> On 1/26/23 15:17, Gerd Hoffmann wrote:
> > On Mon, Jan 09, 2023 at 12:04:40AM +0300, Dmitry Osipenko wrote:
> >> its own refcounting of vmaps, use it instead of drm-shmem
> >> counting. This change prepares drm-shmem for addition
On Mon, Jan 09, 2023 at 12:04:44AM +0300, Dmitry Osipenko wrote:
> Support generic drm-shmem memory shrinker and add new madvise IOCTL to
> the VirtIO-GPU driver. BO cache manager of Mesa driver will mark BOs as
> "don't need" using the new IOCTL to let shrinker purge the marked BOs on
> OOM, the
30 matches
Mail list logo
