Re: [RFC QEMU PATCH v7 1/1] virtio-pci: implement No_Soft_Reset bit

Hi MST, I modified this patch according to your comments. Do you have any other suggestions? On 2024/3/25 15:07, Jiqian Chen wrote: > In current code, when guest does S3, virtio devices are reset due to > the bit No_Soft_Reset is not set. After resetting, the display resources > of virtio-gpu are

Re: [RFC QEMU PATCH v7 1/1] virtio-pci: implement No_Soft_Reset bit

On 2024/3/28 16:11, Michael S. Tsirkin wrote: > >> +VirtIOPCIProxy *proxy = VIRTIO_PCI(dev); >> + >> pcie_cap_deverr_reset(dev); >> pcie_cap_lnkctl_reset(dev); >> >> -pci_set_word(dev->config + dev->exp.pm_cap + PCI_PM_CTRL, 0); >> +if (proxy->flags & V

Re: [RFC QEMU PATCH v8 2/2] virtio-pci: implement No_Soft_Reset bit

On 2024/3/28 18:57, Michael S. Tsirkin wrote: > On Thu, Mar 28, 2024 at 06:39:03PM +0800, Jiqian Chen wrote: >> In current code, when guest does S3, virtio devices are reset due to >> the bit No_Soft_Reset is not set. After resetting, the display resources >> of virtio-gpu are destroyed, then the d

Re: [RFC QEMU PATCH v8 2/2] virtio-pci: implement No_Soft_Reset bit

On 2024/3/28 20:36, Michael S. Tsirkin wrote: +} + static void virtio_pci_bus_reset_hold(Object *obj) { PCIDevice *dev = PCI_DEVICE(obj); DeviceState *qdev = DEVICE(obj); +if (virtio_pci_no_soft_reset(dev)) { +return; +

Re: [RFC QEMU PATCH v8 2/2] virtio-pci: implement No_Soft_Reset bit

On 2024/3/29 15:20, Jason Wang wrote: > On Fri, Mar 29, 2024 at 3:07 PM Chen, Jiqian wrote: >> >> On 2024/3/28 20:36, Michael S. Tsirkin wrote: >>>>>> +} >>>>>> + >>>>>> static void virtio_pci_bus_reset_ho

Re: [RFC QEMU PATCH v8 2/2] virtio-pci: implement No_Soft_Reset bit

On 2024/3/29 18:38, Jason Wang wrote: > On Fri, Mar 29, 2024 at 4:00 PM Chen, Jiqian wrote: >> >> On 2024/3/29 15:20, Jason Wang wrote: >>> On Fri, Mar 29, 2024 at 3:07 PM Chen, Jiqian wrote: >>>> >>>> On 2024/3/28 20:36, Michael S. Tsirkin wro

Re: [RFC QEMU PATCH v8 2/2] virtio-pci: implement No_Soft_Reset bit

On 2024/3/29 18:44, Michael S. Tsirkin wrote: > On Fri, Mar 29, 2024 at 03:20:59PM +0800, Jason Wang wrote: >> On Fri, Mar 29, 2024 at 3:07 PM Chen, Jiqian wrote: >>> >>> On 2024/3/28 20:36, Michael S. Tsirkin wrote: >>>>>>> +} >>>>>

Re: [QEMU PATCH v6 1/1] virtio-pci: implement No_Soft_Reset bit

Hi Michael S. Tsirkin, Do you have any comments on this patch? On 2024/2/22 11:40, Jiqian Chen wrote: > In current code, when guest does S3, virtio devices are reset due to > the bit No_Soft_Reset is not set. After resetting, the display resources > of virtio-gpu are destroyed, then the display ca

Re: [QEMU PATCH v6 1/1] virtio-pci: implement No_Soft_Reset bit

On 2024/3/18 16:04, Michael S. Tsirkin wrote: > On Thu, Feb 22, 2024 at 11:40:10AM +0800, Jiqian Chen wrote: >> In current code, when guest does S3, virtio devices are reset due to >> the bit No_Soft_Reset is not set. After resetting, the display resources >> of virtio-gpu are destroyed, then the d

Re: [RFC QEMU PATCH v8 2/2] virtio-pci: implement No_Soft_Reset bit

On 2024/4/7 11:20, Jason Wang wrote: > On Tue, Apr 2, 2024 at 11:03 AM Chen, Jiqian wrote: >> >> On 2024/3/29 18:44, Michael S. Tsirkin wrote: >>> On Fri, Mar 29, 2024 at 03:20:59PM +0800, Jason Wang wrote: >>>> On Fri, Mar 29, 2024 at 3:07 PM Chen, Jiqian w

Re: [RFC QEMU PATCH v8 2/2] virtio-pci: implement No_Soft_Reset bit

On 2024/4/7 19:49, Michael S. Tsirkin wrote: >>> I will set the default value of No_Soft_Reset bit to true in next version >>> according to your opinion. >>> About the compatibility of old machine types, which types should I >>> consider? Does the same as x-pcie-pm-init(hw_compat_2_8)? >>> Forgiv

Re: [RFC QEMU PATCH v8 2/2] virtio-pci: implement No_Soft_Reset bit

On 2024/4/8 12:56, Jason Wang wrote: I will set the default value of No_Soft_Reset bit to true in next version according to your opinion. About the compatibility of old machine types, which types should I consider? Does the same as x-pcie-pm-init(hw_compat_2_8)? Forgive m

Re: [RFC QEMU PATCH v8 2/2] virtio-pci: implement No_Soft_Reset bit

On 2024/4/12 14:41, Jason Wang wrote: > On Fri, Apr 12, 2024 at 2:05 PM Chen, Jiqian wrote: >> >> On 2024/4/7 19:49, Michael S. Tsirkin wrote: >>>>> I will set the default value of No_Soft_Reset bit to true in next version >>>>> according to your

Re: [RFC QEMU PATCH v9 2/2] virtio-pci: implement No_Soft_Reset bit

On 2024/4/16 23:45, Igor Mammedov wrote: > On Tue, 16 Apr 2024 15:01:27 +0800 > Jiqian Chen wrote: > >> In current code, when guest does S3, virtio-gpu are reset due to the >> bit No_Soft_Reset is not set. After resetting, the display resources >> of virtio-gpu are destroyed, then the display can

Re: [RFC QEMU PATCH v9 2/2] virtio-pci: implement No_Soft_Reset bit

On 2024/4/17 13:33, Yan Vugenfirer wrote: > On Wed, Apr 17, 2024 at 6:13 AM Chen, Jiqian wrote: >> >> On 2024/4/16 23:45, Igor Mammedov wrote: >>> On Tue, 16 Apr 2024 15:01:27 +0800 >>> Jiqian Chen wrote: >>> >>>> In current code, when g

Re: [RFC QEMU PATCH v9 1/2] virtio-pci: only reset pm state during resetting

Hi, On 2024/4/16 15:01, Jiqian Chen wrote: > Fix bug imported by 27ce0f3afc9dd25d21b43bbce505157afd93d111 > (fix Power Management Control Register for PCI Express virtio devices) > > Only state of PM_CTRL is writable. > Only when flag VIRTIO_PCI_FLAG_INIT_PM is set, need to reset state. > > Sign

Re: [RFC QEMU PATCH v9 1/2] virtio-pci: only reset pm state during resetting

On 2024/5/10 18:18, Michael S. Tsirkin wrote: > On Tue, Apr 16, 2024 at 03:01:26PM +0800, Jiqian Chen wrote: >> Fix bug imported by 27ce0f3afc9dd25d21b43bbce505157afd93d111 >> (fix Power Management Control Register for PCI Express virtio devices) > > > should be: > > 27ce0f3afc9dd ("fix Power Ma

Re: [PATCH v11 2/2] virtio-pci: implement No_Soft_Reset bit

On 2024/6/21 17:20, Chen, Jiqian wrote: > Hi MST, > > On 2024/6/6 18:22, Jiqian Chen wrote: >> In current code, when guest does S3, virtio-gpu are reset due to the >> bit No_Soft_Reset is not set. After resetting, the display resources >> of virtio-gpu are destroyed,

Re: [PATCH v10 2/2] virtio-pci: implement No_Soft_Reset bit

On 2024/6/2 22:33, Michael S. Tsirkin wrote: > On Wed, May 15, 2024 at 03:35:26PM +0800, Jiqian Chen wrote: >> In current code, when guest does S3, virtio-gpu are reset due to the >> bit No_Soft_Reset is not set. After resetting, the display resources >> of virtio-gpu are destroyed, then the displa

Re: [PATCH v11 2/2] virtio-pci: implement No_Soft_Reset bit

Hi MST, On 2024/6/6 18:22, Jiqian Chen wrote: > In current code, when guest does S3, virtio-gpu are reset due to the > bit No_Soft_Reset is not set. After resetting, the display resources > of virtio-gpu are destroyed, then the display can't come back and only > show blank after resuming. > > Imp

Re: [PATCH v11 1/2] virtio-pci: only reset pm state during resetting

Hi MST, On 2024/6/6 18:22, Jiqian Chen wrote: > Fix bug imported by 27ce0f3afc9dd ("fix Power Management Control Register for > PCI Express virtio devices" > After this change, observe that QEMU may erroneously clear the power status > of the device, > or may erroneously clear non writable regis

Re: [virtio-dev] [RESEND VIRTIO GPU PATCH v3 1/1] virtio-gpu: Add new feature flag VIRTIO_GPU_F_FREEZE_S3

Hi Mikhail Golubev-Ciuchea, I have improved this implementation to the virtio pci level. Could you please try my patches and see if them are useful in your scene? My new series: V5 of Qemu patch: https://lore.kernel.org/qemu-devel/20230919110225.2282914-1-jiqian.c...@amd.com/T/#t V5 of kernel pat

Re: [virtio-dev] RE: [VIRTIO PCI PATCH v5 1/1] transport-pci: Add freeze_mode to virtio_pci_common_cfg

Hi Parav, On 2023/9/19 20:10, Parav Pandit wrote: > Hi Jiqian, > >> From: Jiqian Chen >> Sent: Tuesday, September 19, 2023 5:13 PM >> >> When guest vm does S3, Qemu will reset and clear some things of virtio >> devices, but guest can't aware that, so that may cause some problems. > It is not tru

Re: [VIRTIO PCI PATCH v5 1/1] transport-pci: Add freeze_mode to virtio_pci_common_cfg

Hi Michael S. Tsirkin, On 2023/9/19 20:31, Michael S. Tsirkin wrote: > On Tue, Sep 19, 2023 at 07:42:42PM +0800, Jiqian Chen wrote: >> When guest vm does S3, Qemu will reset and clear some things of virtio >> devices, but guest can't aware that, so that may cause some problems. >> For excample, Qe

Re: [virtio-dev] Re: [virtio-comment] Re: [VIRTIO PCI PATCH v5 1/1] transport-pci: Add freeze_mode to virtio_pci_common_cfg

Hi Lingshan, On 2023/9/20 13:59, Zhu, Lingshan wrote: > > > On 9/19/2023 8:31 PM, Michael S. Tsirkin wrote: >> On Tue, Sep 19, 2023 at 07:42:42PM +0800, Jiqian Chen wrote: >>> When guest vm does S3, Qemu will reset and clear some things of virtio >>> devices, but guest can't aware that, so that

Re: [virtio-comment] Re: [virtio-dev] Re: [virtio-comment] Re: [VIRTIO PCI PATCH v5 1/1] transport-pci: Add freeze_mode to virtio_pci_common_cfg

Hi Lingshan, On 2023/9/20 14:58, Zhu, Lingshan wrote: > > > On 9/20/2023 2:33 PM, Chen, Jiqian wrote: >> Hi Lingshan, >> >> On 2023/9/20 13:59, Zhu, Lingshan wrote: >>> >>> On 9/19/2023 8:31 PM, Michael S. Tsirkin wrote: >>>> On

Re: [virtio-dev] Re: [virtio-comment] Re: [VIRTIO PCI PATCH v5 1/1] transport-pci: Add freeze_mode to virtio_pci_common_cfg

Hi Lingshan, It seems you reply to the wrong email thread. They are not related to my patch. On 2023/9/20 15:06, Zhu, Lingshan wrote: > > > On 9/20/2023 2:58 PM, Parav Pandit wrote: >>> From: Chen, Jiqian >>> Sent: Wednesday, September 20, 2023 12:03 PM >>&g

Re: [virtio-dev] Re: [virtio-comment] Re: [VIRTIO PCI PATCH v5 1/1] transport-pci: Add freeze_mode to virtio_pci_common_cfg

gt;>> >>> On 9/20/2023 3:24 PM, Chen, Jiqian wrote: >>>> Hi Lingshan, >>>> It seems you reply to the wrong email thread. They are not related to my >>> patch. >>> These reply to Parva's comments. >>> @Parva, if you want to dis

Re: [virtio-comment] RE: [virtio-dev] Re: [virtio-comment] Re: [VIRTIO PCI PATCH v5 1/1] transport-pci: Add freeze_mode to virtio_pci_common_cfg

On 2023/9/20 15:56, Parav Pandit wrote: > Hi Jiquian, > >> From: Chen, Jiqian >> Sent: Wednesday, September 20, 2023 1:24 PM >> >> Hi Lingshan, >> Please reply to your own email thread, below are not related to my patches. >> Thanks a lot. >

Re: [virtio-dev] Re: [VIRTIO PCI PATCH v5 1/1] transport-pci: Add freeze_mode to virtio_pci_common_cfg

Hi Jason, On 2023/9/21 12:22, Jason Wang wrote: > On Tue, Sep 19, 2023 at 7:43 PM Jiqian Chen wrote: >> >> When guest vm does S3, Qemu will reset and clear some things of virtio >> devices, but guest can't aware that, so that may cause some problems. >> For excample, Qemu calls virtio_reset->virt

Re: [QEMU PATCH v4 0/1] S3 support

Hi all, Please forgive me for asking. Do you have any other comments on my latest version patches about virtio-gpu S3 on Xen? Looking forward to your reply. On 2023/7/20 20:08, Jiqian Chen wrote: > v4: > > Hi all, > Thanks for Gerd Hoffmann's advice. V4 makes below changes: > * Use enum for fre

Re: [QEMU PATCH v2 1/1] virtgpu: do not destroy resources when guest suspend

Hi, On 2023/7/11 04:28, Michael S. Tsirkin wrote: > On Fri, Jun 30, 2023 at 03:00:16PM +0800, Jiqian Chen wrote: >> After suspending and resuming guest VM, you will get >> a black screen, and the display can't come back. >> >> This is because when guest did suspending, it called >> into qemu to ca

Re: [QEMU PATCH 1/1] virtgpu: do not destroy resources when guest suspend

Hi Dongwon, On 2023/6/30 00:53, Kim, Dongwon wrote: > This method - letting QEMU not remove resources would work on S3 case but > with S4, the QEMU would lose all the resources anyway as the process will be > terminated. So objects restoring was only option for us as My patch is for S3 function

Re: [QEMU PATCH v2 0/1] S3 support

Hi all, V2 patch of kernel is https://lore.kernel.org/lkml/20230630073448.842767-1-jiqian.c...@amd.com/T/#t. On 2023/6/30 15:00, Jiqian Chen wrote: > v2: > > Hi all, > > Thanks to Marc-André Lureau, Robert Beckett and Gerd Hoffmann for > their advice and guidance. V2 makes below changes: > >

Re: [QEMU PATCH 1/1] virtgpu: do not destroy resources when guest suspend

Hi Marc-André Lureau On 2023/6/12 20:42, Marc-André Lureau wrote: > Hi > > On Thu, Jun 8, 2023 at 6:26 AM Jiqian Chen > wrote: > > After suspending and resuming guest VM, you will get > a black screen, and the display can't come back. > > This is because

Re: [QEMU PATCH 1/1] virtgpu: do not destroy resources when guest suspend

On 2023/6/9 00:41, Robert Beckett wrote: > > On 08/06/2023 03:56, Jiqian Chen wrote: >> After suspending and resuming guest VM, you will get >> a black screen, and the display can't come back. >> >> This is because when guest did suspending, it called >> into qemu to call virtio_gpu_gl_reset. In

Re: [QEMU PATCH 1/1] virtgpu: do not destroy resources when guest suspend

Hi Gerd Hoffmann On 2023/6/19 20:51, Gerd Hoffmann wrote: > Hi, >> Adding a new command requires new feature flag (and maybe it should be in >> the <0x1000 range instead) >> >> But I am not sure we need a new message at the virtio-gpu level. Gerd, wdyt? >> >> Maybe it's not a good place to rese

Re: [QEMU PATCH 0/1]

| 3 +++ > include/standard-headers/linux/virtio_gpu.h | 9 +++ > 5 files changed, 47 insertions(+), 3 deletions(-) > -- Best regards, Chen, Jiqian.

Re: [QEMU PATCH 1/1] virtgpu: do not destroy resources when guest suspend

On 2023/6/9 00:41, Robert Beckett wrote: > > On 08/06/2023 03:56, Jiqian Chen wrote: >> After suspending and resuming guest VM, you will get >> a black screen, and the display can't come back. >> >> This is because when guest did suspending, it called >> into qemu to call virtio_gpu_gl_reset. In f

Re: [virtio-dev] [RESEND VIRTIO GPU PATCH v3 1/1] virtio-gpu: Add new feature flag VIRTIO_GPU_F_FREEZE_S3

Hi Mikhail Golubev-Ciuchea, On 2023/9/12 00:33, Mikhail Golubev-Ciuchea wrote: > Hi Jiqian, > > Thanks for the proposal. > > Some time ago I was working on the same issue with suspending the gpu device > (on arm). Additionally, I had troubles with virtio-video device as well, see > https://lore

Re: [RFC QEMU PATCH v3 1/1] xen: Use gsi instead of irq for mapping pirq

On 2023/12/11 23:33, Roger Pau Monné wrote: > On Mon, Dec 11, 2023 at 12:52:40AM +0800, Jiqian Chen wrote: >> In PVH dom0, it uses the linux local interrupt mechanism, >> when it allocs irq for a gsi, it is dynamic, and follow >> the principle of applying first, distributing first. And >> the irq n

Re: [RFC QEMU PATCH v7 1/1] xen/pci: get gsi for passthrough devices

On 2024/10/15 03:34, Stewart Hildebrand wrote: > +Edgar > > On 5/16/24 06:13, Jiqian Chen wrote: >> In PVH dom0, it uses the linux local interrupt mechanism, >> when it allocs irq for a gsi, it is dynamic, and follow >> the principle of applying first, distributing first. And >> the irq number is

Re: [QEMU PATCH v8] xen/passthrough: use gsi to map pirq when dom0 is PVH

On 2024/10/23 07:07, Marek Marczykowski-Górecki wrote: > On Wed, Oct 16, 2024 at 02:28:27PM +0800, Jiqian Chen wrote: >> --- a/hw/xen/xen_pt.h >> +++ b/hw/xen/xen_pt.h >> @@ -36,6 +36,7 @@ void xen_pt_log(const PCIDevice *d, const char *f, ...) >> G_GNUC_PRINTF(2, 3); >> # define XEN_PT_LOG_CONF

Re: [QEMU PATCH v8] xen/passthrough: use gsi to map pirq when dom0 is PVH

On 2024/10/22 04:55, Stewart Hildebrand wrote: > On 10/16/24 02:28, Jiqian Chen wrote: >> In PVH dom0, when passthrough a device to domU, QEMU code >> xen_pt_realize->xc_physdev_map_pirq wants to use gsi, but in current codes >> the gsi number is got from file /sys/bus/pci/devices//irq, that is >>

Re: [QEMU PATCH v9] xen/passthrough: use gsi to map pirq when dom0 is PVH

On 2024/11/1 21:09, Stewart Hildebrand wrote: > On 10/24/24 05:06, Jiqian Chen wrote: >> diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c >> index 3635d1b39f79..5b10d501d566 100644 >> --- a/hw/xen/xen_pt.c >> +++ b/hw/xen/xen_pt.c >> @@ -766,6 +766,50 @@ static void xen_pt_destroy(PCIDevice *d) { >>

Re: [QEMU PATCH v9] xen/passthrough: use gsi to map pirq when dom0 is PVH

Hi, On 2024/10/24 17:06, Jiqian Chen wrote: > In PVH dom0, when passthrough a device to domU, QEMU code > xen_pt_realize->xc_physdev_map_pirq wants to use gsi, but in current codes > the gsi number is got from file /sys/bus/pci/devices//irq, that is > wrong, because irq is not equal with gsi, they

Re: [QEMU PATCH v10] xen/passthrough: use gsi to map pirq when dom0 is PVH

On 2024/11/19 00:05, Anthony PERARD wrote: > On Wed, Nov 06, 2024 at 02:14:18PM +0800, Jiqian Chen wrote: >> In PVH dom0, when passthrough a device to domU, QEMU code >> xen_pt_realize->xc_physdev_map_pirq wants to use gsi, but in current codes >> the gsi number is got from file /sys/bus/pci/device

Re: [QEMU PATCH v10] xen/passthrough: use gsi to map pirq when dom0 is PVH

Hi MST and Marcel, On 2024/11/19 00:05, Anthony PERARD wrote: > On Wed, Nov 06, 2024 at 02:14:18PM +0800, Jiqian Chen wrote: >> In PVH dom0, when passthrough a device to domU, QEMU code >> xen_pt_realize->xc_physdev_map_pirq wants to use gsi, but in current codes >> the gsi number is got from file

Re: [QEMU PATCH v10] xen/passthrough: use gsi to map pirq when dom0 is PVH

On 2024/11/19 00:05, Anthony PERARD wrote: > On Wed, Nov 06, 2024 at 02:14:18PM +0800, Jiqian Chen wrote: >> In PVH dom0, when passthrough a device to domU, QEMU code >> xen_pt_realize->xc_physdev_map_pirq wants to use gsi, but in current codes >> the gsi number is got from file /sys/bus/pci/device

Re: [QEMU PATCH v10] xen/passthrough: use gsi to map pirq when dom0 is PVH

On 2024/12/12 23:38, Anthony PERARD wrote: > On Tue, Dec 10, 2024 at 07:17:30AM +0000, Chen, Jiqian wrote: >> On 2024/11/19 00:05, Anthony PERARD wrote: >>> On Wed, Nov 06, 2024 at 02:14:18PM +0800, Jiqian Chen wrote: >>>> In PVH dom0, when passthrou

Re: [QEMU PATCH v10] xen/passthrough: use gsi to map pirq when dom0 is PVH

Hi Anthony, On 2024/12/12 23:38, Anthony PERARD wrote: > On Tue, Dec 10, 2024 at 07:17:30AM +0000, Chen, Jiqian wrote: >> On 2024/11/19 00:05, Anthony PERARD wrote: >>> On Wed, Nov 06, 2024 at 02:14:18PM +0800, Jiqian Chen wrote: >>>> In PVH dom0, when passthrou