From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5708930E0D3 for ; Thu, 28 Aug 2025 12:22:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756383755; cv=none; b=TMFbfYN2L9P0ZgQTFqrGiXmUpmwBhHb98wwsvCOJ1G/JXbMK0tKpCsmIyhR3yxTDHMbvanafBcRbAHs+K9s/Sqm8txEEh18+NJONGdNoN+073Nb676x67MA2lPpCsI1nb0G91cAaSmlZ85ax/ic2UpxAD4rl6d2qY6/l9Yr55uk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756383755; c=relaxed/simple; bh=XoHfNzd9TzAflaxVnsWKe6PmdGkidLY3mwWJ8PoI0Cw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=ocbuCoAdTu8y3KROjw2nyMq3IMJfJ4s+9JzXJN0MhhVgpuWeVEijoZbRg9y5/MZiqvUqkyoS+u/yKGvAYo+sDjUUvgnU3B+Or6MWcRZQnMyftjvj0J1Zn+TUPAb/eqIZZS1KGbb2BEcTvVsAz16XKOayg3EZeWve0SSVUFfGbRk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=FULuvIdX; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="FULuvIdX" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1756383752; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+RCok65salaUoQjWE+4RzDLHzVJ7fbcHVunYgHTZPTo=; b=FULuvIdXL0iNgW6FoCqNTgzojkcFUgauQ2N5AZQEeTMU034v88gn7/viy4YYq3V0IN2zsn XCdO1NwClGXsdR1EEw/Q/tyYL0aUJtCSAYMOf+vBKee/6CkVe+sZDU2ZSV4ERGSGyPV5Jm taguIzICxxsfAPxkeUrRWVlrM/CyldQ= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-352-5Ks8oVAcNF2gA11hoxKoKg-1; Thu, 28 Aug 2025 08:22:27 -0400 X-MC-Unique: 5Ks8oVAcNF2gA11hoxKoKg-1 X-Mimecast-MFC-AGG-ID: 5Ks8oVAcNF2gA11hoxKoKg_1756383746 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 3EF1B18002A4; Thu, 28 Aug 2025 12:22:26 +0000 (UTC) Received: from localhost (unknown [10.45.224.217]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id D7226300019F; Thu, 28 Aug 2025 12:22:24 +0000 (UTC) From: Cornelia Huck To: "Michael S. Tsirkin" Cc: Parav Pandit , "virtualization@lists.linux.dev" , "jasowang@redhat.com" , "stefanha@redhat.com" , "pbonzini@redhat.com" , "xuanzhuo@linux.alibaba.com" , "stable@vger.kernel.org" , Max Gurtovoy , "NBU-Contact-Li Rongqing (EXTERNAL)" , linux-s390@vger.kernel.org Subject: Re: [PATCH] Revert "virtio_pci: Support surprise removal of virtio pci device" In-Reply-To: <20250828081717-mutt-send-email-mst@kernel.org> Organization: "Red Hat GmbH, Sitz: Werner-von-Siemens-Ring 12, D-85630 Grasbrunn, Handelsregister: Amtsgericht =?utf-8?Q?M=C3=BCnchen=2C?= HRB 153243, =?utf-8?Q?Gesch=C3=A4ftsf=C3=BChrer=3A?= Ryan Barnhart, Charles Cachera, Avril Crosse O'Flaherty" References: <20250822090249-mutt-send-email-mst@kernel.org> <20250822095225-mutt-send-email-mst@kernel.org> <20250824102947-mutt-send-email-mst@kernel.org> <20250827061537-mutt-send-email-mst@kernel.org> <87frdddmni.fsf@redhat.com> <87cy8fej4z.fsf@redhat.com> <20250828081717-mutt-send-email-mst@kernel.org> User-Agent: Notmuch/0.38.3 (https://notmuchmail.org) Date: Thu, 28 Aug 2025 14:22:21 +0200 Message-ID: <87a53jeiv6.fsf@redhat.com> Precedence: bulk X-Mailing-List: virtualization@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 On Thu, Aug 28 2025, "Michael S. Tsirkin" wrote: > On Thu, Aug 28, 2025 at 02:16:28PM +0200, Cornelia Huck wrote: >> On Thu, Aug 28 2025, Parav Pandit wrote: >> >> >> From: Cornelia Huck >> >> Sent: 27 August 2025 05:04 PM >> >> >> >> On Wed, Aug 27 2025, "Michael S. Tsirkin" wrote: >> >> >> >> > On Tue, Aug 26, 2025 at 06:52:03PM +0000, Parav Pandit wrote: >> >> >> > What I do not understand, is what good does the revert do. Sorry. >> >> >> > >> >> >> Let me explain. >> >> >> It prevents the issue of vblk requests being stuck due to broken VQ. >> >> >> It prevents the vnet driver start_xmit() to be not stuck on skb completions. >> >> > >> >> > This is the part I don't get. In what scenario, before 43bb40c5b9265 >> >> > start_xmit is not stuck, but after 43bb40c5b9265 it is stuck? >> >> > >> >> > Once the device is gone, it is not using any buffers at all. >> >> >> >> What I also don't understand: virtio-ccw does exactly the same thing >> >> (virtio_break_device(), added in 2014), and it supports surprise removal >> >> _only_, yet I don't remember seeing bug reports? >> > >> > I suspect that stress testing may not have happened for ccw with active vblk Ios and outstanding transmit pkt and cvq commands. >> > Hard to say as we don't have ccw hw or systems. >> >> cc:ing linux-s390 list. I'd be surprised if nobody ever tested surprise >> removal on a loaded system in the last 11 years. > > > As it became very clear from follow up discussion, the issue is nothing > to do with virtio, it is with a broken hypervisor that allows device to > DMA into guest memory while also telling the guest that the device has > been removed. > > I guess s390 is just not broken like this. Ah good, I missed that -- that indeed sounds broken, and needs to be fixed there.