> -Original Message-
> From: Shi, Guohuai
> Sent: Friday, March 17, 2023 01:28
> To: Christian Schoenebeck ; Greg Kurz
> ; qemu-devel@nongnu.org
> Cc: Meng, Bin
> Subject: RE: [PATCH v5 04/16] hw/9pfs: Implement Windows specific xxxdir()
> APIs
>
>
> -Original Message-
> From: Christian Schoenebeck
> Sent: Thursday, March 16, 2023 19:05
> To: Greg Kurz ; qemu-devel@nongnu.org
> Cc: Meng, Bin ; Shi, Guohuai
>
> Subject: Re: [PATCH v5 04/16] hw/9pfs: Implement Windows specific xxxdir()
> APIs
>
> CA
> -Original Message-
> From: Christian Schoenebeck
> Sent: Wednesday, March 15, 2023 00:06
> To: Greg Kurz ; qemu-devel@nongnu.org
> Cc: Shi, Guohuai ; Meng, Bin
>
> Subject: Re: [PATCH v5 04/16] hw/9pfs: Implement Windows specific xxxdir()
> APIs
>
> CA
> -Original Message-
> From: Christian Schoenebeck
> Sent: Tuesday, February 7, 2023 18:12
> To: Greg Kurz ; qemu-devel@nongnu.org
> Cc: Meng, Bin ; Marc-André Lureau
> ; Daniel P. Berrangé ; Shi,
> Guohuai
> Subject: Re: [PATCH v4 04/16] hw/9pfs: Implement
> -Original Message-
> From: Christian Schoenebeck
> Sent: Saturday, February 4, 2023 01:55
> To: Greg Kurz ; qemu-devel@nongnu.org
> Cc: Meng, Bin ; Marc-André Lureau
> ; Daniel P. Berrangé
> ; Shi, Guohuai
> Subject: Re: [PATCH v4 04/16] hw/9pfs: Implement
> -Original Message-
> From: Christian Schoenebeck
> Sent: Friday, February 3, 2023 22:41
> To: Greg Kurz ; qemu-devel@nongnu.org
> Cc: Meng, Bin ; Marc-André Lureau
> ; Daniel P. Berrangé ; Shi,
> Guohuai
> Subject: Re: [PATCH v4 04/16] hw/9pfs: Implement
> -Original Message-
> From: Christian Schoenebeck
> Sent: Friday, February 3, 2023 20:25
> To: Greg Kurz ; qemu-devel@nongnu.org
> Cc: Shi, Guohuai ; Meng, Bin
> ; Marc-André Lureau ;
> Daniel P. Berrangé
> Subject: Re: [PATCH v4 04/16] hw/9pfs: Implement
> From: Marc-André Lureau
> Sent: Tuesday, January 31, 2023 23:07
> To: Daniel P. Berrangé
> Cc: Meng, Bin ; Greg Kurz ; Christian
> Schoenebeck ; qemu-devel@nongnu.org; Shi, Guohuai
> ; Laurent > Vivier ; Paolo
> Bonzini ; Philippe Mathieu-Daudé ;
> Thomas Hut
> -Original Message-
> From: Christian Schoenebeck
> Sent: Wednesday, December 28, 2022 19:51
> To: Greg Kurz ; qemu-devel@nongnu.org
> Cc: Meng, Bin ; Shi, Guohuai
>
> Subject: Re: [PATCH v3 07/17] hw/9pfs: Support getting current directory
> offset for Wi
> -Original Message-
> From: Christian Schoenebeck
> Sent: Wednesday, December 21, 2022 22:48
> To: Greg Kurz ; qemu-devel@nongnu.org
> Cc: Shi, Guohuai ; Meng, Bin
>
> Subject: Re: [PATCH v3 07/17] hw/9pfs: Support getting current directory
> offset for Wi
Peter Maydell writes:
> On Tue, 29 Nov 2022 at 10:48, Schspa Shi wrote:
>>
>> We use 32bit value for linux,initrd-[start/end], when we have
>> loader_start > 4GB, there will be a wrong initrd_start passed
>> to the kernel, and the kernel will report the followin
lls type.
Signed-off-by: Schspa Shi
--
Changelog:
v1 -> v2:
- Use #[address/size]-cells for data type.
v2 -> v3:
- Use #address-cells for all data type.
- Fix indent.
---
hw/arm/boot.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git
Philippe Mathieu-Daudé writes:
> On 29/11/22 11:48, Schspa Shi wrote:
>> We use 32bit value for linux,initrd-[start/end], when we have
>> loader_start > 4GB, there will be a wrong initrd_start passed
>> to the kernel, and the kernel will report the following w
lls type.
Signed-off-by: Schspa Shi
--
Changelog:
v1 -> v2:
- Use #[address/size]-cells for data type.
---
hw/arm/boot.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/hw/arm/boot.c b/hw/arm/boot.c
index 57efb61ee419..98cd1fdad2c6 100644
--- a/hw/arm/
Peter Maydell writes:
> On Tue, 8 Nov 2022 at 02:35, Schspa Shi wrote:
>>
>> We use 32bit value for linux,initrd-[start/end], when we have
>> loader_start > 4GB, there will be a wrong initrd_start passed
>> to the kernel, and the kernel will report the following
> -Original Message-
> From: Christian Schoenebeck
> Sent: Thursday, November 17, 2022 23:55
> To: qemu-devel@nongnu.org
> Cc: Shi, Guohuai ; Greg Kurz ;
> Meng, Bin
> Subject: Re: [PATCH v2 07/19] hw/9pfs: Implement Windows specific utilities
> functions for
Peter Maydell writes:
> On Wed, 16 Nov 2022 at 06:11, Schspa Shi wrote:
>>
>>
>> Peter Maydell writes:
>>
>> > On Tue, 8 Nov 2022 at 15:50, Schspa Shi wrote:
>> >>
>> >>
>> >> Peter Maydell writes:
> -Original Message-
> From: Christian Schoenebeck
> Sent: Tuesday, November 15, 2022 00:41
> To: qemu-devel@nongnu.org
> Cc: Shi, Guohuai ; Greg Kurz ;
> Meng, Bin
> Subject: Re: [PATCH v2 06/19] hw/9pfs: Add missing definitions for Windows
>
> CAUTION:
Peter Maydell writes:
> On Tue, 8 Nov 2022 at 15:50, Schspa Shi wrote:
>>
>>
>> Peter Maydell writes:
>>
>> > On Tue, 8 Nov 2022 at 13:54, Peter Maydell
>> > wrote:
>> >>
>> >> On Tue, 8 Nov 2022 at 12:52, Schspa Shi wro
Peter Maydell writes:
> On Tue, 8 Nov 2022 at 13:54, Peter Maydell wrote:
>>
>> On Tue, 8 Nov 2022 at 12:52, Schspa Shi wrote:
>> > Alex Bennée writes:
>> > > There is a whole comment in boot.c talking about keeping initrd within
>> > > lowme
Alex Bennée writes:
> Schspa Shi writes:
>
>> We use 32bit value for linux,initrd-[start/end], when we have
>> loader_start > 4GB, there will be a wrong initrd_start passed
>> to the kernel, and the kernel will report the following warning.
>>
>>
off-by: Schspa Shi
---
hw/arm/boot.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/arm/boot.c b/hw/arm/boot.c
index 57efb61ee419..da719a4f8874 100644
--- a/hw/arm/boot.c
+++ b/hw/arm/boot.c
@@ -638,14 +638,14 @@ int arm_load_dtb(hwaddr addr, const struct arm_boot_i
> -Original Message-
> From: Christian Schoenebeck
> Sent: Wednesday, November 2, 2022 19:34
> To: qemu-devel@nongnu.org
> Cc: Greg Kurz ; Meng, Bin ; Shi,
> Guohuai
> Subject: Re: [PATCH 09/16] hw/9pfs: Disable unsupported flags and features
> for Windows
> -Original Message-
> From: Christian Schoenebeck
> Sent: Wednesday, November 2, 2022 19:06
> To: qemu-devel@nongnu.org
> Cc: Greg Kurz ; Meng, Bin ; Shi,
> Guohuai
> Subject: Re: [PATCH 07/16] hw/9pfs: Implement Windows specific utilities
> functions for
> -Original Message-
> From: Christian Schoenebeck
> Sent: Wednesday, November 2, 2022 02:59
> To: qemu-devel@nongnu.org
> Cc: Greg Kurz ; Meng, Bin ; Shi,
> Guohuai
> Subject: Re: [PATCH 09/16] hw/9pfs: Disable unsupported flags and features
> for Windows
&
> -Original Message-
> From: Christian Schoenebeck
> Sent: Wednesday, November 2, 2022 02:22
> To: qemu-devel@nongnu.org
> Cc: Greg Kurz ; Meng, Bin ; Shi,
> Guohuai
> Subject: Re: [PATCH 07/16] hw/9pfs: Implement Windows specific utilities
> functions for 9pfs
> -Original Message-
> From: Shi, Guohuai
> Sent: Tuesday, November 1, 2022 23:13
> To: Christian Schoenebeck ; qemu-devel@nongnu.org
> Cc: Greg Kurz ; Meng, Bin
> Subject: RE: [PATCH 07/16] hw/9pfs: Implement Windows specific utilities
> functions for 9pfs
>
> -Original Message-
> From: Christian Schoenebeck
> Sent: Tuesday, November 1, 2022 23:04
> To: qemu-devel@nongnu.org
> Cc: Shi, Guohuai ; Greg Kurz ;
> Meng, Bin
> Subject: Re: [PATCH 09/16] hw/9pfs: Disable unsupported flags and features
> for Windows
>
> -Original Message-
> From: Christian Schoenebeck
> Sent: Tuesday, November 1, 2022 22:28
> To: qemu-devel@nongnu.org
> Cc: Shi, Guohuai ; Greg Kurz ;
> Meng, Bin
> Subject: Re: [PATCH 07/16] hw/9pfs: Implement Windows specific utilities
> functions for 9pfs
&
> -Original Message-
> From: Greg Kurz
> Sent: 2022年5月11日 20:19
> To: Shi, Guohuai
> Cc: Christian Schoenebeck ; qemu-devel@nongnu.org;
> Meng,
> Bin ; Bin Meng
> Subject: Re: [PATCH 5/9] hw/9pfs: Add a 'local' file system backend driver for
> W
ing a symbolic link check during path-walk
operation and stop it when get a symbolic link.
Best Regards,
Guohuai
> -Original Message-
> From: Greg Kurz
> Sent: 2022年5月10日 22:35
> To: Christian Schoenebeck
> Cc: qemu-devel@nongnu.org; Meng, Bin ; Bin Meng
> ; Shi, Guohuai
> -Original Message-
> From: Greg Kurz
> Sent: 2022年5月10日 0:20
> To: Shi, Guohuai
> Cc: Bin Meng ; Christian Schoenebeck
> ;
> qemu-devel@nongnu.org; Meng, Bin
> Subject: Re: [PATCH 5/9] hw/9pfs: Add a 'local' file system backend driver for
> Wind
> -Original Message-
> From: Greg Kurz
> Sent: 2022年5月9日 22:29
> To: Bin Meng
> Cc: Christian Schoenebeck ; qemu-devel@nongnu.org;
> Shi,
> Guohuai ; Meng, Bin
> Subject: Re: [PATCH 5/9] hw/9pfs: Add a 'local' file system backend driver for
> Wind
> -Original Message-
> From: Christian Schoenebeck
> Sent: 2022年5月5日 19:44
> To: qemu-devel@nongnu.org; Shi, Guohuai ; Greg Kurz
>
> Cc: Meng, Bin ; Bin Meng
> Subject: Re: [PATCH 5/9] hw/9pfs: Add a 'local' file system backend driver for
> Windows
> -Original Message-
> From: Christian Schoenebeck
> Sent: Thursday, May 5, 2022 02:02
> To: qemu-devel@nongnu.org
> Cc: Greg Kurz ; Meng, Bin ; Shi,
> Guohuai ; Bin Meng
> Subject: Re: [PATCH 5/9] hw/9pfs: Add a 'local' file system backend driver
> f
change 9PFS readdir() implement on Windows host, to fix
this problem.
Thanks,
Guohuai
-Original Message-
From: Mark Cave-Ayland
Sent: Tuesday, April 19, 2022 18:59
To: Christian Schoenebeck
Cc: Shi, Guohuai ; qemu-devel@nongnu.org; Bin Meng
; Greg Kurz
Subject: Re: [RFC PATCH 0/4]
> -Original Message-
> From: Christian Schoenebeck
> Sent: 2022年4月14日 19:24
> To: qemu-devel@nongnu.org; Shi, Guohuai
> Cc: Bin Meng ; Greg Kurz
> Subject: Re: [RFC PATCH 0/4] 9pfs: Add 9pfs support for Windows host
>
> [Please note: This e-mail is from an
FS (e.g. FAT) which does not support
stream data,
then the "map" can not work.
Thanks
Guohuai
-Original Message-
From: Bin Meng
Sent: 2022年4月13日 11:19
To: Christian Schoenebeck ; Shi, Guohuai
Cc: qemu-devel@nongnu.org Developers ; Greg Kurz
Subject: Re: [RFC PATCH 0/4] 9pfs: A
1、install re2c。[url：http://re2c.org/index.html]
tar -xvzf re2c-1.0.3.tar.gz
cd re2c-1.0.3/
autoreconf -i -W all
./configure
make&&make install
2、git clone git://github.com/ninja-build/ninja.git && cd ninja
./configure.py --bootstrap
cp ninja /usr/bin/
[root@aix7 ~]# ninja -
Thank you very much.
Best regards.
Peter Maydell 于2021年3月5日周五 下午7:57写道：
> On Thu, 25 Feb 2021 at 05:36, schspa wrote:
> >
> > At the moment the following QEMU command line triggers an assertion
> > failure On xlnx-versal SOC:
> > qemu-system-aarch64 \
> > -machine xlnx-versal-virt -no
It works in my side after specify the full path to swtpm tpmemu.sock in qemu
command options. Thanks!
Steven Shi
Intel\SSG\STO\UEFI Firmware
Tel: +86 021-61166522
iNet: 821-6522
> -Original Message-
> From: Stefan Berger [mailto:stef...@linux.vnet.ibm.com]
> Sent: Friday
socket,id=chrtpm,path=tpmemu.sock: Failed to
connect socket tpmemu.sock: No such file or directory
I use the latest version qemu as below:
$ qemu-system-x86_64 --version
QEMU emulator version 2.11.50 (v2.10.0-4184-g930b01138b-dirty)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
Thanks
Steven Shi
e
swtpm?
Thanks
Steven Shi
* Cornelia Huck [2018-02-27 18:32:51 +0100]:
> The license text currently specifies "any version" of the GPL. It
> is unlikely that GPL v1 was ever intended; change this to the
> standard "or any later version" text.
>
> Cc: Dong Jia Shi
> Cc: Xiao Feng Re
t?
>
> I'm not sure about the later. What prevents the guest from believing
> the (to use your terminology shared) chp 0.00 has become unavailable
> if 0.00 becomes unavailable in the host?
>
> Would that adversely affect the virtual devices? It would at
> least look strange.
AFAI read the code, this series does not hurt the vritual devices, which
always have fixed path information in SCHIB.
The strange thing is, the chp 0.00 is both virtual and non-virtual with
mix use of virtual and non-virtual devices. And any existing problem is
not caused or enhanced by this work. If we can not fix the problem
without MCSS support or chp re-modelling in the near future, we should
document the problem and the effect.
I will do some test on this.
>
>>
>> We'd have to document this either I think.
>>
>>> Note: this is another unpleasant effect of not having MCSSE in the
>>> guest. The original design was to have a separate css for vfio, and
>>> then we would not have this kind of a problem. (Virtualization of
>>> chps would still be good for migration.)
>> Nod. BTW, I don't say that I do not want channel path virtualization in
>> the long run. It's just I want a minimal function set more currently
>> from what I'm focusing perspective.
>>
>> THANKS for these insightful questions!
>>
--
Dong Jia Shi
* Dong Jia Shi [2018-01-30 11:37:43 +0800]:
Damn.. Please just ignore the above mail. It's not the right draft.
> Halil Pasic writes:
>
> Hi Halil,
>
> As you may noticed, Conny replied to this thread on my mail. Some of her
> comments there could answer your questi
up being ignored)?
>> You mean the clash that sharing path 0.00 between a physical dasd and
>> the virtio ccw devices? The problem I saw is in the checking of the
>> chpid.is_virtual in css_do_rchp(). For a virtual chp, we should generate
>> INIT CRWs; while for a non-virtual one, we shouldn't. If the chp is
>> shared with virtual and non-virtual device, I don't know what to do
>> then...
>>
>> I don't think we can fix this before we re-modelled the channel path.
>> But this is neither introduced nor aggravated by this series, right?
>
> I'm not sure about the later. What prevents the guest from believing
> the (to use your terminology shared) chp 0.00 has become unavailable
> if 0.00 becomes unavailable in the host?
>
> Would that adversely affect the virtual devices? It would at
> least look strange.
>
>>
>> We'd have to document this either I think.
>>
>>> Note: this is another unpleasant effect of not having MCSSE in the
>>> guest. The original design was to have a separate css for vfio, and
>>> then we would not have this kind of a problem. (Virtualization of
>>> chps would still be good for migration.)
>> Nod. BTW, I don't say that I do not want channel path virtualization in
>> the long run. It's just I want a minimal function set more currently
>> from what I'm focusing perspective.
>>
>> THANKS for these insightful questions!
>>
--
Dong Jia Shi
* Halil Pasic [2018-01-16 16:57:13 +0100]:
>
>
> On 01/15/2018 09:59 AM, Dong Jia Shi wrote:
> > * Halil Pasic [2018-01-12 19:10:20 +0100]:
> >
> >>
> >>
> >> On 01/11/2018 04:04 AM, Dong Jia Shi wrote:
> >>> What are still missing
* Pierre Morel [2018-01-15 11:21:47 +0100]:
> On 15/01/2018 09:57, Dong Jia Shi wrote:
> >* Cornelia Huck [2018-01-11 11:54:22 +0100]:
> >
> >>On Thu, 11 Jan 2018 04:04:18 +0100
> >>Dong Jia Shi wrote:
> >>
> >>>Hi Folks,
> >>>
* Cornelia Huck [2018-01-15 13:24:22 +0100]:
> On Mon, 15 Jan 2018 10:50:00 +0100
> Pierre Morel wrote:
>
> > On 11/01/2018 04:04, Dong Jia Shi wrote:
> > > This introduces a new region for vfio-ccw to provide subchannel
> > > information for user space.
> &
* Halil Pasic [2018-01-12 19:10:20 +0100]:
>
>
> On 01/11/2018 04:04 AM, Dong Jia Shi wrote:
> > What are still missing, thus need to be offered in the next version are:
> > - I/O termination and FSM state handling if currently we have I/O on the
> > status
> &g
* Cornelia Huck [2018-01-11 11:54:22 +0100]:
> On Thu, 11 Jan 2018 04:04:18 +0100
> Dong Jia Shi wrote:
>
> > Hi Folks,
> >
> > Background
> > ==
> >
> > Some days ago, we had a discussion on the topic of channel path
> > virtua
* Cornelia Huck [2018-01-11 15:16:59 +0100]:
Hi Conny,
> On Thu, 11 Jan 2018 04:04:19 +0100
> Dong Jia Shi wrote:
>
> > This introduces a new region for vfio-ccw to provide subchannel
> > information for user space.
> >
> > Signed-off-by: Dong Jia S
le we are at it, touch one line of the comment around by
adding white space to make it aligned.
Signed-off-by: Dong Jia Shi
---
hw/s390x/css.c | 83 -
hw/s390x/s390-ccw.c | 20 +++
hw/vfio/ccw.c
path information update, we only do update if we were signaled.
We sets scsw.pno and pmcw.pnom to indicate path related event
for a guest. This is a bit lazy, but it works.
Signed-off-by: Dong Jia Shi
---
hw/s390x/css.c | 14 +--
hw/s390x/s390-ccw.c | 12 +
hw
the schib likeness.
Signed-off-by: Dong Jia Shi
---
hw/vfio/ccw.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/hw/vfio/ccw.c b/hw/vfio/ccw.c
index 16713f2c52..e673695509 100644
--- a/hw/vfio/ccw.c
+++ b/hw/vfio/ccw.c
@@ -32,6 +32,10 @@ typedef
Hi Folks,
This is the QEMU couterpart for the "basic channel path event handling" series.
For more information, please refer to the kernel counterpart.
Dong Jia Shi (5):
vfio: linux-headers update for vfio-ccw
vfio/ccw: get schib region info
vfio/ccw: get irq info and set up h
This adds channel path related event handler for vfio-ccw.
This also signals userland when there is a chp event.
Signed-off-by: Dong Jia Shi
---
drivers/s390/cio/vfio_ccw_drv.c | 51 +
drivers/s390/cio/vfio_ccw_fsm.c | 22
drivers
path information
out once got the eventfd signal, and do further process.
Signed-off-by: Dong Jia Shi
---
hw/vfio/ccw.c | 92 +--
1 file changed, 70 insertions(+), 22 deletions(-)
diff --git a/hw/vfio/ccw.c b/hw/vfio/ccw.c
index e673695509
This is a placeholder for a linux-headers update.
Signed-off-by: Dong Jia Shi
---
linux-headers/linux/vfio.h | 2 ++
linux-headers/linux/vfio_ccw.h | 6 ++
2 files changed, 8 insertions(+)
diff --git a/linux-headers/linux/vfio.h b/linux-headers/linux/vfio.h
index 4312e961ff..24d85be022
This introduces a new irq for vfio-ccw to provide channel path
related event for userland.
Signed-off-by: Dong Jia Shi
---
drivers/s390/cio/vfio_ccw_ops.c | 29 +
drivers/s390/cio/vfio_ccw_private.h | 2 ++
include/uapi/linux/vfio.h | 1 +
3 files
Use PIM PAM POM CHPIDs
--
0.0.3f3f 0.0.0002 3390/0c 3990/e9 f0 f0 ff 42434445
#Notice: PAM changed again.
Dong Jia Shi (3):
vfio: ccw: introduce schib region
vfio: ccw: introduce channel path irq
vfio: ccw: handle chp event
drivers/s390/cio/
This introduces a new region for vfio-ccw to provide subchannel
information for user space.
Signed-off-by: Dong Jia Shi
---
drivers/s390/cio/vfio_ccw_fsm.c | 21 ++
drivers/s390/cio/vfio_ccw_ops.c | 79 +++--
drivers/s390/cio/vfio_ccw_private.h
* Dong Jia Shi [2017-12-05 15:43:00 +0800]:
> * Cornelia Huck [2017-12-04 17:11:24 +0100]:
>
> [...]
>
> This one looks good to me too, so:
> Reviewed-by: Dong Jia Shi
>
> >
> > (...)
> >
> > > > Looks sane. We should put a note into th
* Dong Jia Shi [2017-12-05 15:43:00 +0800]:
> * Cornelia Huck [2017-12-04 17:11:24 +0100]:
>
> [...]
>
> This one looks good to me too, so:
> Reviewed-by: Dong Jia Shi
>
BTW, since we are deprecating s390-squash-mcss, I think any more
improment on it (e.g. more accu
* Cornelia Huck [2017-12-04 17:11:24 +0100]:
[...]
This one looks good to me too, so:
Reviewed-by: Dong Jia Shi
>
> (...)
>
> > > Looks sane. We should put a note into the 2.12 changelog as well.
> > >
> >
> > I agree. Who would be responsi
^
> >
>
> Nod.
>
> >> +" or not (read only, always true)",
>
> Do we need "." here ^ ?
>
> >> +NULL);
> >> }
> >>
> >> static const TypeInfo virtual_css_bridge_info = {
> >
> > Looks reasonable. If this works as expected, I'll squash it into the
> > previous patch.
> >
>
> I've just asked Shalini to verify the libvirt perspective.
>
> Supposed we verify this works as expected, I read I don't have to spin
> a v2 and you are going to fix the issues found yourself. Right?
Supposed this works as expected, you have my r-b. ;)
--
Dong Jia Shi
* Halil Pasic [2017-12-01 15:31:34 +0100]:
[...]
No comment for the message part.
The code looks good to me. So after squashing with patch #2:
Reviewed-by: Dong Jia Shi
> ---
> hw/s390x/3270-ccw.c| 2 +-
> hw/s390x/css.c | 28
&g
> > The differences of the test results between w and w/o this patch are in
> > the "squashing off" cases. I think these are things that we can accept.
>
> Yes, I think that makes sense. If you want reliable migration, you need
> to be specific with your ids. I'd just don't want us to break things
> explicitly.
>
Fair enough. Got the message.
--
Dong Jia Shi
* Halil Pasic [2017-11-29 17:30:15 +0100]:
>
>
> On 11/29/2017 12:47 PM, Cornelia Huck wrote:
> > On Wed, 29 Nov 2017 16:17:35 +0800
> > Dong Jia Shi wrote:
> >
> >> * Halil Pasic [2017-11-28 14:07:58 +0100]:
> >>
> >> [...]
> >&g
* Dong Jia Shi [2017-11-29 16:17:35 +0800]:
[...]
> T6. squashing off + explicit given id
> qemu-system-s390x: vmstate: get_nullptr expected VMS_NULLPTR_MARKER
> qemu-system-s390x: Failed to load s390_css:css
> qemu-system-s390x: error while loading state for instance 0
wn savevm section or instance '/00.0.0003/virtio-rng' 0
qemu-system-s390x: load of migration failed: Invalid argument
[Fail due to busid mismatch.]
T8. squashing on + explicit given id
Succeed.
Notice:
The differences of the test results between w and w/o this patch are in
the "squashing off" cases. I think these are things that we can accept.
[...]
--
Dong Jia Shi
* Cornelia Huck [2017-11-27 13:58:16 +0100]:
> On Mon, 27 Nov 2017 10:20:56 +0800
> Dong Jia Shi wrote:
>
> > * Halil Pasic [2017-11-24 17:39:04 +0100]:
> >
> > >
> > >
> > > On 11/24/2017 05:15 PM, Cornelia Huck wrote:
> > >
e can be put
> anywhere. This approach feels wrong to me (the non-restriction is not a
> property of the individual device, but of the whole css resp. the
> machine), so I would continue to veto this.
>
> Proposal 2: Export the default cssid as a machine property. If this
> property exists, it also implies that devices can be put into any css
> image (although it makes the most sense to put them into the default
> css image as indicated by the property). Can be made r/w later if it is
> too much for 2.12.
>
> Proposal 3: Add a machine property that indicates cssids are not
> restricted. Later, optionally add a second property that exposes the
> default cssid and makes it configurable.
>
> Personally, I prefer 2 (especially as this also allows to find out
> where the best place to put devices for non-mcss-e enabled guests is),
> but I could live with 3 as well (if making this r/w later would be
> problematic for libvirt.)
>
> (In every case, we would deprecate and later remove the squash
> parameter.)
>
> [As an aside, how hard is it to make the default cssid configurable? At
> a glance, it does not seem too bad to me.]
>
--
Dong Jia Shi
e operation of setting it's value to
true.
> >
> > (Unless we simply make this a "default cssid" prop after all - then it
> > would be more than just a simple indication for libvirt...)
> >
>
> We are now talking about the "cssid-unrestricted" property. The default
> cssid is not something I would like to do any time soon.
--
Dong Jia Shi
e cds_read. What we
want would be surely more than this. So to extend the coverage, we need
to design more modes (aka, test cases), right?
If nobody disagrees with the basic idea of this series, I can start a
review then. ;)
[...]
--
Dong Jia Shi
* Cornelia Huck [2017-11-14 11:50:14 +0100]:
Hallo Conny,
After spending some time, just some updates for this one.
> On Tue, 14 Nov 2017 16:25:47 +0800
> Dong Jia Shi wrote:
>
> > Dear Conny,
> >
> > Good day!
> >
> > Just now, our Libvirt folks
also for QEMU cmd line users. And we are wondering if there is some
way to improve it.
Thanks,
--
Dong Jia Shi
> >>> -ret = -EBUSY;
> >>> -goto out;
> >>> +return IOINST_CC_STATUS_PRESENT;
> >>> }
> >>
> >> ... but here you change -EBUSY (which got mapped to CC=2) to
> >> CC_STATUS_PRESENT which means CC=1. So that's a change in behavior. i.e.
> >> this is either a bug, or you should update the patch description with a
> >> justification for this change in behavior.
> >
> > Indeed, that's a bug. We still want cc 2.
> >
>
> Agree, it is a bug. It was OK in v1 but was already buggy in
> v2.
>
> Conny can you fix this up as well please?
>
> Thanks in advance!
>
I saw Conny fixed this in her branch. So:
Reviewed-by: Dong Jia Shi
--
Dong Jia Shi
n;
> }
> -setcc(cpu, cc);
> +setcc(cpu, css_do_hsch(sch));
> }
>
> static int ioinst_schib_valid(SCHIB *schib)
> --
> 2.13.5
>
Reviewed-by: Dong Jia Shi
--
Dong Jia Shi
gt; --
> 2.13.5
>
If we agree to replace 3 with IOINST_CC_NOT_OPERATIONAL, maybe Conny
could fix it. Or we can do that in a following cleanup patch?
W/ or w/o the fix, for now:
Reviewed-by: Dong Jia Shi
--
Dong Jia Shi
ENODEV:
> -cc = 3;
> -break;
> -case -EBUSY:
> -cc = 2;
> -break;
> -case 0:
> -cc = 0;
> -break;
> -default:
> -cc = 1;
> -break;
> +if (!sch || !css_subch_visible(sch)) {
> +setcc(cpu, 3);
?:
s/3/IOINST_CC_NOT_OPERATIONAL/
This also applies to other alike cases.
> +return;
> }
> -setcc(cpu, cc);
> +setcc(cpu, css_do_xsch(sch));
> }
>
> void ioinst_handle_csch(S390CPU *cpu, uint64_t reg1)
> --
> 2.13.5
>
Reviewed-by: Dong Jia Shi
--
Dong Jia Shi
;
Agree for what already planned to fix when applying.
LGTM:
Reviewed-by: Dong Jia Shi
--
Dong Jia Shi
* Cornelia Huck [2017-10-18 11:53:10 +0200]:
> On Wed, 18 Oct 2017 16:23:47 +0800
> Dong Jia Shi wrote:
>
> > * Halil Pasic [2017-10-17 18:19:20 +0200]:
> >
> > [...]
> >
> > > >> Testing
> > > >> ===
> > > >&
IOINST_CC_BUSY = 2,
> +/* inst. ineffective because not operational */
> +IOINST_CC_NOT_OPERATIONAL = 3
> +} IOInstEnding;
> +
> typedef struct SubchDev SubchDev;
> struct SubchDev {
> /* channel-subsystem related things: */
> --
> 2.13.5
>
With what ha
his series is quite
> under-tested, and the changes in vfio-ccw aren't just minor.
>
> Of course I could come up with a test setup myself, but I hope Dong Jia
> already has one, and he is certainly more involved with vfio-ccw.
>
Using Conny's s390-next branch + this series
* Halil Pasic [2017-10-11 12:54:51 +0200]:
>
>
> On 10/11/2017 05:47 AM, Dong Jia Shi wrote:
> > * Halil Pasic [2017-10-04 17:41:39 +0200]:
> >
> >> Simplify the error handling of the SSCH and RSCH handler avoiding
> >> arbitrary and cryptic error codes
* Halil Pasic [2017-10-10 12:06:23 +0200]:
>
>
> On 10/10/2017 10:13 AM, Dong Jia Shi wrote:
> > * Halil Pasic [2017-10-04 17:41:39 +0200]:
> >
> > [...]
> >
> >> diff --git a/hw/s390x/css.c b/hw/s390x/css.c
> >> index 4f47dbc8b0..b2978c
upt(sch);
> +return (IOInstEnding){.cc = 0};
> }
> -
> -return region->ret_code;
> }
>
> static void vfio_ccw_reset(DeviceState *dev)
> diff --git a/include/hw/s390x/css.h b/include/hw/s390x/css.h
> index 66916b6546..2116c6b3c7 100644
> --- a/include/hw/s390x/css.h
> +++ b/include/hw/s390x/css.h
[...]
> @@ -197,13 +208,14 @@ SubchDev *css_find_subch(uint8_t m, uint8_t cssid,
> uint8_t ssid,
> uint16_t schid);
> bool css_subch_visible(SubchDev *sch);
> void css_conditional_io_interrupt(SubchDev *sch);
> +
Extra change.
> int css_do_stsch(SubchDev *sch, SCHIB *schib);
> bool css_schid_final(int m, uint8_t cssid, uint8_t ssid, uint16_t schid);
> int css_do_msch(SubchDev *sch, const SCHIB *schib);
[...]
--
Dong Jia Shi
> +IOInstEnding s390_ccw_cmd_request(SubchDev *sch)
> {
> -S390CCWDeviceClass *cdc = S390_CCW_DEVICE_GET_CLASS(data);
> +S390CCWDeviceClass *cdc = S390_CCW_DEVICE_GET_CLASS(sch->driver_data);
>
> -if (cdc->handle_request) {
> -return cdc->handle_request(orb, scsw, data);
> -} else {
> -return -ENOSYS;
> +if (!cdc->handle_request) {
> +return (IOInstEnding){.cc = 1};
Same consideration as the last comment.
> }
> +return cdc->handle_request(sch);
> }
>
> static void s390_ccw_get_dev_info(S390CCWDevice *cdev,
[...]
--
Dong Jia Shi
>do_subchannel_work) {
> -return sch->do_subchannel_work(sch);
> -} else {
> +if (!sch->do_subchannel_work) {
> return -EINVAL;
> }
> + g_assert(sch->curr_status.scsw.ctrl & SCSW_CTRL_MASK_FCTL);
> +return sch->do_subchannel_work(sch);
> }
>
> static void copy_pmcw_to_guest(PMCW *dest, const PMCW *src)
With the fix of the message:
Reviewed-by: Dong Jia Shi
--
Dong Jia Shi
* Dong Jia Shi [2017-09-26 15:48:56 +0800]:
[...]
> > >
> > > Tried to test with the following method:
> > > 1. Start g1 (first level guest on kvm a host) with a virtio blk device
> > >defined:
> > > -drive
> > > file=/dev/disk/by-path
* Halil Pasic [2017-09-25 12:57:31 +0200]:
[restored Cc:]
>
>
> On 09/25/2017 09:31 AM, Dong Jia Shi wrote:
> > * Cornelia Huck [2017-09-08 11:59:50 +0200]:
> >
> >> On Fri, 8 Sep 2017 11:21:57 +0200
> >> Halil Pasic wrote:
> >>
> >>
* Cornelia Huck [2017-09-21 10:54:02 +0200]:
> On Thu, 21 Sep 2017 16:45:47 +0800
> Dong Jia Shi wrote:
>
> > * Cornelia Huck [2017-09-07 10:08:17 +0200]:
> >
> > [...]
> >
> > > > I'm thinking of a method these days:
> > > >
* Cornelia Huck [2017-09-08 11:59:50 +0200]:
> On Fri, 8 Sep 2017 11:21:57 +0200
> Halil Pasic wrote:
>
> > On 09/08/2017 05:41 AM, Dong Jia Shi wrote:
> > > Let' me summarize here, in case I misunderstand things. Now we have
> > > two ways to cho
* Cornelia Huck [2017-09-08 12:02:38 +0200]:
> On Fri, 8 Sep 2017 11:41:00 +0800
> Dong Jia Shi wrote:
>
> > I think the difficult part is in the Qemu side. For either A or B, in
> > Qemu, we'd need to return a cc0 to indicate the channel program is
> > accepted
; ---
> hw/s390x/css.c | 114
> -
> 1 file changed, 113 insertions(+), 1 deletion(-)
>
LGTM:
Reviewed-by: Dong Jia Shi
[...]
--
Dong Jia Shi
cds);
> diff --git a/include/hw/s390x/css.h b/include/hw/s390x/css.h
> index 078356e94c..69b374730e 100644
> --- a/include/hw/s390x/css.h
> +++ b/include/hw/s390x/css.h
> @@ -87,6 +87,7 @@ typedef struct CcwDataStream {
> #define CDS_F_MIDA 0x02
> #define CDS_F_I2K 0x04
> #define CDS_F_C64 0x08
> +#define CDS_F_FMT 0x10 /* CCW format-1 */
> #define CDS_F_STREAM_BROKEN 0x80
> uint8_t flags;
> uint8_t at_idaw;
> --
> 2.13.5
>
Reviewed-by: Dong Jia Shi
--
Dong Jia Shi
pt in a
synchronzing manner. And this causes g1's I/O interrupt handler getting
the interrupt and then signaling the Qemu instance on g1 with the I/O
result, even before return of the pwrite().
But, using gdb on the kvm host, I do see several ssch successfully
executed. I will dig the root reason, and see if there is some way to
fix the issue.
--
Dong Jia Shi
* Halil Pasic [2017-09-20 13:13:01 +0200]:
>
>
> On 09/20/2017 10:33 AM, Cornelia Huck wrote:
> > On Wed, 20 Sep 2017 15:42:38 +0800
> > Dong Jia Shi wrote:
> >
> >> * Halil Pasic [2017-09-19 20:27:45 +0200]:
> >>
> >>> Let'
1 - 100 of 400 matches
Mail list logo
