On 06/07/2019 10:53 AM, Cornelia Huck wrote:
A vfio-ccw device may provide an async command subregion for
issuing halt/clear subchannel requests. If it is present, use
it for sending halt/clear request to the device; if not, fall
back to emulation (as done today).
Signed-off-by: Cornelia Huck
On 06/07/2019 11:09 AM, Cornelia Huck wrote:
On Fri, 7 Jun 2019 11:02:36 -0400
Farhan Ali wrote:
On 06/07/2019 10:53 AM, Cornelia Huck wrote:
A vfio-ccw device may provide an async command subregion for
issuing halt/clear subchannel requests. If it is present, use
it for sending halt
On 06/07/2019 10:53 AM, Cornelia Huck wrote:
A vfio-ccw device may provide an async command subregion for
issuing halt/clear subchannel requests. If it is present, use
it for sending halt/clear request to the device; if not, fall
back to emulation (as done today).
Signed-off-by: Cornelia Huck
On 06/11/2019 07:37 AM, Cornelia Huck wrote:
On Fri, 7 Jun 2019 11:19:09 -0400
Farhan Ali wrote:
On 06/07/2019 11:09 AM, Cornelia Huck wrote:
On Fri, 7 Jun 2019 11:02:36 -0400
Farhan Ali wrote:
On 06/07/2019 10:53 AM, Cornelia Huck wrote:
diff --git a/hw/s390x/css.c b/hw/s390x
On 06/12/2019 05:38 AM, Cornelia Huck wrote:
On Tue, 11 Jun 2019 15:33:59 -0400
Farhan Ali wrote:
On 06/07/2019 10:53 AM, Cornelia Huck wrote:
A vfio-ccw device may provide an async command subregion for
issuing halt/clear subchannel requests. If it is present, use
it for sending halt
Hi,
I noticed qemu iotest 55 was broken on the latest master (My head commit
is dbbc277 Merge remote-tracking branch
'remotes/stefanha/tags/block-pull-request' into staging).
The backtrace of the qemu process when the test fails:
#0 0x7f82047cd428 in __GI_raise (sig=sig@entry=6) at
../
On 03/14/2019 01:11 PM, Eric Blake wrote:
On 3/14/19 11:33 AM, Farhan Ali wrote:
Hi,
I noticed qemu iotest 55 was broken on the latest master (My head commit
is dbbc277 Merge remote-tracking branch
'remotes/stefanha/tags/block-pull-request' into staging).
Patch has been propos
-ccw/s390-ccw.h | 1 +
pc-bios/s390-ccw/start.S| 29 +
4 files changed, 301 insertions(+), 3 deletions(-)
Reviewed-by: Farhan Ali
ms to solve the issue.
Tested-by : Farhan Ali
Thank you
Farhan
On 11/16/2016 02:50 PM, Christian Borntraeger wrote:
On 11/15/2016 02:46 PM, Paolo Bonzini wrote:
Patch 1 fixes vhost, patches 2-3 fix Windows hibernation.
Paolo
Paolo Bonzini (3):
virtio: introduce grab/release_ioeventfd t
On 11/16/2016 03:16 PM, Michael S. Tsirkin wrote:
On Wed, Nov 16, 2016 at 03:03:13PM -0500, Farhan Ali wrote:
Hi Paolo,
I was able to test your patches in our s390 environment. I don't see the
qemu crashes anymore which I noticed before.
Testing a guest running high stress I/O wor
On 11/16/2016 03:32 PM, Farhan Ali wrote:
On 11/16/2016 03:16 PM, Michael S. Tsirkin wrote:
On Wed, Nov 16, 2016 at 03:03:13PM -0500, Farhan Ali wrote:
Hi Paolo,
I was able to test your patches in our s390 environment. I don't see
the
qemu crashes anymore which I noticed b
Hi Thomas,
Thanks for the review.
On 02/20/2017 10:28 AM, Thomas Huth wrote:
On 20.02.2017 15:19, Cornelia Huck wrote:
From: Farhan Ali
Load the network boot image into guest RAM when the boot
device selected is a network device. Use some of the reserved
space in IplBlockCcw to store the
On 02/24/2017 05:44 AM, Thomas Huth wrote:
On 21.02.2017 11:23, Christian Borntraeger wrote:
On 02/20/2017 04:33 PM, Thomas Huth wrote:
On 20.02.2017 15:19, Cornelia Huck wrote:
From: Farhan Ali
The current QEMU ROM infrastructure rejects late loading of ROMs.
And ELFs are currently
On 02/24/2017 05:11 AM, Thomas Huth wrote:
On 22.02.2017 16:01, Farhan Ali wrote:
Hi Thomas,
Thanks for the review.
On 02/20/2017 10:28 AM, Thomas Huth wrote:
On 20.02.2017 15:19, Cornelia Huck wrote:
From: Farhan Ali
[...]
+}
+
+ram_ptr = memory_region_get_ram_ptr(mr);
+if
Hi Thomas,
This is really interesting :)
On 06/27/2017 07:48 AM, Thomas Huth wrote:
It's already possible to do a network boot of an s390x guest with an
external netboot image (based on a Linux installation), but it would
be much more convenient if the s390-ccw firmware supported network
bootin
"virtio.h"
#include "scsi.h"
diff --git a/pc-bios/s390-ccw/virtio.c b/pc-bios/s390-ccw/virtio.c
index 6ee93d5..8768331 100644
--- a/pc-bios/s390-ccw/virtio.c
+++ b/pc-bios/s390-ccw/virtio.c
@@ -8,6 +8,7 @@
* directory.
*/
+#include "libc.h"
#include "s390-ccw.h"
#include "virtio.h"
#include "virtio-scsi.h"
Reviewed-by: Farhan Ali
On 07/07/2017 06:26 AM, Thomas Huth wrote:
We will later need this array in a file that we will link to the
netboot code, too. Since there is some ebcdic convertion done
in sclp_get_loadparm_ascii(), the sclp.c file seems to be a good
candidate.
s/convertion/conversion
Signed-off-by: Thomas
Hi,
There is an issue in QEMU bios which is exposed by commit
commit 198c0d1f9df8c429502cb744fc26b6ba6e71db74
Author: Halil Pasic
Date: Thu Jul 27 17:48:42 2017 +0200
s390x/css: check ccw address validity
According to the PoP channel command words (CCW) must be doubleword
aligne
On 08/24/2017 11:50 AM, Thomas Huth wrote:
On 24.08.2017 17:47, Halil Pasic wrote:
On 08/24/2017 05:35 PM, Thomas Huth wrote:
On 24.08.2017 17:13, Cornelia Huck wrote:
On Thu, 24 Aug 2017 11:05:08 -0400
Farhan Ali wrote:
Hi,
There is an issue in QEMU bios which is exposed by commit
On 08/24/2017 12:07 PM, Peter Maydell wrote:
On 24 August 2017 at 16:53, Farhan Ali wrote:
On 08/24/2017 11:50 AM, Thomas Huth wrote:
True, so that could still be an issue. Looking at the cio.h in the
kernel, they define the struct like this:
struct ccw1 {
__u8 cmd_code
.
On 08/24/2017 05:05 PM, Farhan Ali wrote:
Hi,
There is an issue in QEMU bios which is exposed by commit
commit 198c0d1f9df8c429502cb744fc26b6ba6e71db74
Author: Halil Pasic
Date: Thu Jul 27 17:48:42 2017 +0200
s390x/css: check ccw address validity
According to the PoP channel
The commit 198c0d1f9df8c4 s390x/css: check ccw address validity
exposes an alignment issue in ccw bios.
According to PoP the CCW must be doubleword aligned. Let's fix
this in the bios.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Farhan Ali
Reviewed-by: Halil Pasic
Reviewed-by: Eric Farman
On 08/25/2017 10:04 AM, Cornelia Huck wrote:
On Fri, 25 Aug 2017 09:24:46 -0400
Farhan Ali wrote:
The commit 198c0d1f9df8c4 s390x/css: check ccw address validity
exposes an alignment issue in ccw bios.
According to PoP the CCW must be doubleword aligned. Let's fix
this in the bios
On 08/28/2017 04:22 AM, Cornelia Huck wrote:
On Fri, 25 Aug 2017 11:05:30 -0400
Farhan Ali wrote:
On 08/25/2017 10:04 AM, Cornelia Huck wrote:
On Fri, 25 Aug 2017 09:24:46 -0400
Farhan Ali wrote:
The commit 198c0d1f9df8c4 s390x/css: check ccw address validity
exposes an alignment issue
On 08/28/2017 09:06 AM, Cornelia Huck wrote:
On Mon, 28 Aug 2017 08:56:42 -0400
Farhan Ali wrote:
On 08/28/2017 04:22 AM, Cornelia Huck wrote:
On Fri, 25 Aug 2017 11:05:30 -0400
Farhan Ali wrote:
On 08/25/2017 10:04 AM, Cornelia Huck wrote:
On Fri, 25 Aug 2017 09:24:46 -0400
Farhan Ali
On 08/28/2017 09:24 AM, Christian Borntraeger wrote:
On 08/28/2017 03:18 PM, Farhan Ali wrote:
On 08/28/2017 09:06 AM, Cornelia Huck wrote:
On Mon, 28 Aug 2017 08:56:42 -0400
Farhan Ali wrote:
On 08/28/2017 04:22 AM, Cornelia Huck wrote:
On Fri, 25 Aug 2017 11:05:30 -0400
Farhan Ali
On 08/28/2017 10:05 AM, Cornelia Huck wrote:
It's the alignment of the CCW which causes the problem.
The exact error message when starting the guest was:
! No virtio device found !
Since it worked for SCSI and CDL, and failed for LDL disks on that particular
system, we are not really sure w
On 08/28/2017 10:19 AM, Halil Pasic wrote:
On 08/28/2017 04:15 PM, Farhan Ali wrote:
On 08/28/2017 10:05 AM, Cornelia Huck wrote:
It's the alignment of the CCW which causes the problem.
The exact error message when starting the guest was:
! No virtio device found !
Since it worke
Hi Phil,
On 08/28/2017 11:04 AM, Philippe Mathieu-Daudé wrote:
Can you provide the link script used in both systems?
See on the previous thread:
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.nongnu.org_archive_html_qemu-2Ddevel_2017-2D08_msg05134.html&d=DwIC-g&c=jf_iaSHvJObTbx-siA1Z
On 08/29/2017 08:04 AM, Cornelia Huck wrote:
On Mon, 28 Aug 2017 10:28:53 -0400
Farhan Ali wrote:
On 08/28/2017 10:19 AM, Halil Pasic wrote:
On 08/28/2017 04:15 PM, Farhan Ali wrote:
On 08/28/2017 10:05 AM, Cornelia Huck wrote:
It's the alignment of the CCW which causes the pr
sc->read_SCP_info = read_SCP_info;
sc->read_storage_element0_info = read_storage_element0_info;
Reviewed-by: Farhan Ali
Wire up the virtio-input HID devices (keyboard, mouse, tablet)
for the CCW bus. The virtio-input is a virtio-1 device,
so disable legacy revision 0.
Signed-off-by: Farhan Ali
Reviewed-by: Halil Pasic
Reviewed-by: Christian Borntraeger
---
hw/s390x/virtio-ccw.c | 100
On 12/11/2017 05:19 PM, Collin L. Walling wrote:
When the boot menu options are present and the guest's
disk has been configured by the zipl tool, then the user
will be presented with an interactive boot menu with
labeled entries. An example of what the menu might look
like:
zIPL v1.37.1-
shouldn't the commit message say exit -> unrealize?
Thanks
Farhan
On 01/16/2018 08:15 AM, Philippe Mathieu-Daudé wrote:
Signed-off-by: Philippe Mathieu-Daudé
---
hw/s390x/virtio-ccw.h | 2 +-
hw/s390x/virtio-ccw.c | 35 +--
2 files changed, 18 insertions(+
On 01/16/2018 09:07 AM, Philippe Mathieu-Daudé wrote:
On 01/16/2018 10:41 AM, Farhan Ali wrote:
shouldn't the commit message say exit -> unrealize?
Oops, indeed :|
Thanks :)
Phil.
Sure, you are welcome :)
With the change in commit message, the patch looks good to me:
Rev
Test 232 creates image files with read-only permission and
expects an error message when trying to access the image
files with read-only and auto-read-only turned off.
Don't run as root user, since root can open files with read/write
access for read-only files.
Signed-off-by: Farha
On 12/05/2018 07:54 AM, Cornelia Huck wrote:
Yeah, that is perfectly clear, but it ain't the complete story. E.g.
are subsequent commands blocking until the preceding command finishes
is part of the interface. And what is good implementation depends on the
answer. What I mean, I first need to
On 12/06/2018 09:39 AM, Cornelia Huck wrote:
On Wed, 5 Dec 2018 13:34:11 -0500
Farhan Ali wrote:
On 12/05/2018 07:54 AM, Cornelia Huck wrote:
Yeah, that is perfectly clear, but it ain't the complete story. E.g.
are subsequent commands blocking until the preceding command finishes
is
On 12/06/2018 11:21 AM, Cornelia Huck wrote:
On Thu, 6 Dec 2018 10:26:12 -0500
Farhan Ali wrote:
On 12/06/2018 09:39 AM, Cornelia Huck wrote:
On Wed, 5 Dec 2018 13:34:11 -0500
Farhan Ali wrote:
On 12/05/2018 07:54 AM, Cornelia Huck wrote:
Yeah, that is perfectly clear, but it ain&#
csw;
+copy_scsw_from_guest(&destscsw, &srcscsw);
+dest->scsw = destscsw;
dest->mba = be64_to_cpu(src->mba);
for (i = 0; i < ARRAY_SIZE(dest->mda); i++) {
dest->mda[i] = src->mda[i];
Reviewed-by: Farhan Ali
py_scsw_from_guest(&dest_scsw, &src_scsw);
+dest->scsw = dest_scsw;
dest->mba = be64_to_cpu(src->mba);
for (i = 0; i < ARRAY_SIZE(dest->mda); i++) {
dest->mda[i] = src->mda[i];
Reviewed-by: Farhan Ali
ADPARM_LEN);
sclp_print(ldp);
@@ -168,6 +173,7 @@ static void virtio_setup(void)
int main(void)
{
sclp_setup();
+css_setup();
virtio_setup();
zipl_load(); /* no return */
Reviewed-by: Farhan Ali
eters));
-if (store_iplb(&iplb)) {
+if (have_iplb) {
switch (iplb.pbt) {
case S390_IPL_TYPE_CCW:
dev_no = iplb.ccw.devno;
@@ -174,6 +185,7 @@ int main(void)
{
sclp_setup();
css_setup();
+boot_setup();
virtio_setup();
zipl_load(); /* no return */
Reviewed-by: Farhan Ali
On 12/12/2018 09:11 AM, Jason J. Herne wrote:
Make a new routine find_boot_device to locate the boot device for all
cases. not just virtio.
I don't think there should be a period after cases?
In one case no boot device is specified and a suitable boot device can not
be auto detected. The
On 12/12/2018 09:11 AM, Jason J. Herne wrote:
Add struct for format-0 ccws. Support executing format-0 channel
programs and waiting for their completion before continuing execution.
This will be used for real dasd ipl.
Add cu_type() to channel io library. This will be used to query control
un
On 12/12/2018 09:11 AM, Jason J. Herne wrote:
Add verbose error output for when unexpected i/o errors happen. This eases the
burden of debugging and reporting i/o errors. No error information is printed
in the success case, here is an example of what is output on error:
vfio-ccw device I/O er
Commit 9cbef9d68ee: qemu-option: improve qemu_opts_print_help() output,
changed some of the output for qemu-img tool but did not
update the corresponding 082 test case file. This broke
qemu-iotests.
Signed-off-by: Farhan Ali
---
tests/qemu-iotests/082.out | 956
On 10/15/2018 11:45 AM, Max Reitz wrote:
082 is failing for me on master (046936ed), and this fixes it.
I'm wondering if/why other people are not running into this, as 082 runs
with qcow2 and is included on `make check-block`.
+ Max,
FIY, I ran into this while reviewing/testing your Python
+++ b/MAINTAINERS
@@ -1204,6 +1204,8 @@ F: include/hw/vfio/
vfio-ccw
M: Cornelia Huck
+M: Eric Farman
+M: Farhan Ali
S: Supported
F: hw/vfio/ccw.c
F: hw/s390x/s390-ccw.c
Acked-by: Farhan Ali
On 11/22/2018 11:54 AM, Cornelia Huck wrote:
[This is the Linux kernel part, git tree is available at
https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/vfio-ccw.git
vfio-ccw-caps
The companion QEMU patches are available at
https://github.com/cohuck/qemu vfio-ccw-caps]
Currently, vfio-
On 11/22/2018 11:54 AM, Cornelia Huck wrote:
diff --git a/drivers/s390/cio/vfio_ccw_private.h
b/drivers/s390/cio/vfio_ccw_private.h
index 078e46f9623d..a6f9f84526e2 100644
--- a/drivers/s390/cio/vfio_ccw_private.h
+++ b/drivers/s390/cio/vfio_ccw_private.h
@@ -3,9 +3,11 @@
* Private stuff f
On 11/22/2018 11:54 AM, Cornelia Huck wrote:
Add a region to the vfio-ccw device that can be used to submit
asynchronous I/O instructions. ssch continues to be handled by the
existing I/O region; the new region handles hsch and csch.
Interrupt status continues to be reported through the same
On 11/22/2018 11:54 AM, Cornelia Huck wrote:
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 565669f95534..c01472ec77ea 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -304,6 +304,7 @@ struct vfio_region_info_cap_type {
#define VFIO_REGION_S
On 11/28/2018 04:02 AM, Cornelia Huck wrote:
On Tue, 27 Nov 2018 14:09:49 -0500
Farhan Ali wrote:
On 11/22/2018 11:54 AM, Cornelia Huck wrote:
Add a region to the vfio-ccw device that can be used to submit
asynchronous I/O instructions. ssch continues to be handled by the
existing I/O
On 11/28/2018 09:52 AM, Cornelia Huck wrote:
On Wed, 28 Nov 2018 09:31:51 -0500
Farhan Ali wrote:
On 11/28/2018 04:02 AM, Cornelia Huck wrote:
On Tue, 27 Nov 2018 14:09:49 -0500
Farhan Ali wrote:
On 11/22/2018 11:54 AM, Cornelia Huck wrote:
Add a region to the vfio-ccw device that
On 11/28/2018 10:35 AM, Cornelia Huck wrote:
On Wed, 28 Nov 2018 10:00:59 -0500
Farhan Ali wrote:
On 11/28/2018 09:52 AM, Cornelia Huck wrote:
On Wed, 28 Nov 2018 09:31:51 -0500
Farhan Ali wrote:
On 11/28/2018 04:02 AM, Cornelia Huck wrote:
On Tue, 27 Nov 2018 14:09:49 -0500
Farhan
Hi,
I am seeing a failure of the qemu-iotest number 232 when running the
test as a root user. Is this the expected behavior?
Here is the output of the failure:
sudo ./check -qcow2 232
QEMU --
"/home/alifm/kvmdev/qemu/tests/qemu-iotests/../../x86_64-softmmu/qemu-system-x86_64"
-nod
On 11/29/2018 04:07 PM, Eric Blake wrote:
On 11/29/18 3:03 PM, Farhan Ali wrote:
Hi,
I am seeing a failure of the qemu-iotest number 232 when running the
test as a root user. Is this the expected behavior?
Here is the output of the failure:
-QEMU_PROG: -drive
driver=file,file
On 11/30/2018 12:50 PM, Eric Blake wrote:
Adding qemu-devel - all patches should go there, especially if you want
to get Peter's attention that this might be a 3.1 candidate if we have
other reasons to spin -rc4.
On 11/30/18 10:04 AM, Farhan Ali wrote:
Test 232 creates image files
Test 232 creates image files with read-only permission and
expects an error message when trying to access the image
files with read-only and auto-read-only turned off.
Don't run as root user, since root can open files with read/write
access for read-only files.
Signed-off-by: Farha
On 11/30/2018 03:52 PM, Eric Blake wrote:
On 11/30/18 2:37 PM, Farhan Ali wrote:
Test 232 creates image files with read-only permission and
expects an error message when trying to access the image
files with read-only and auto-read-only turned off.
Don't run as root user, since roo
Hi,
I am seeing some strange QEMU assertion failures for qemu on s390x,
which prevents a guest from starting.
Git bisecting points to the following commit as the source of the error.
commit ed6e2161715c527330f936d44af4c547f25f687e
Author: Nishanth Aravamudan
Date: Fri Jun 22 12:37:00 2018 -0
On 07/17/2018 04:52 PM, Nishanth Aravamudan wrote:
iiuc, this possibly implies AIO was not actually used previously on this
guest (it might have silently been falling back to threaded IO?). I
don't have access to s390x, but would it be possible to run qemu under
gdb and see if aio_setup_linux_
On 07/18/2018 09:42 AM, Farhan Ali wrote:
On 07/17/2018 04:52 PM, Nishanth Aravamudan wrote:
iiuc, this possibly implies AIO was not actually used previously on this
guest (it might have silently been falling back to threaded IO?). I
don't have access to s390x, but would it be possib
the affected driver
definitions.
Fixes: ed6e2161 ("linux-aio: properly bubble up errors from initialization")
Reported-by: Farhan Ali
Signed-off-by: Nishanth Aravamudan
Cc: Eric Blake
Cc: Kevin Wolf
Cc: John Snow
Cc: Max Reitz
Cc: Stefan Hajnoczi
Cc: Fam Zheng
Cc: Paolo Bonzini
Cc:
On 07/20/2018 03:32 PM, Nishanth Aravamudan wrote:
On 20.07.2018 [15:11:14 -0400], Farhan Ali wrote:
I am seeing another issue pop up, in a different test. Even though it's a
different assertion, it might be related based on the call trace.
Just to be clear, this does not happen i
On 07/20/2018 03:11 PM, Farhan Ali wrote:
I am seeing another issue pop up, in a different test. Even though it's
a different assertion, it might be related based on the call trace.
Stack trace of thread 276199:
#0 0x03ff8473e274 raise (libc.so.6)
#1 0x03ff847239a8 abort (li
On 07/23/2018 12:30 PM, Stefan Hajnoczi wrote:
On Fri, Jul 20, 2018 at 03:11:14PM -0400, Farhan Ali wrote:
I am seeing another issue pop up, in a different test. Even though it's a
different assertion, it might be related based on the call trace.
Which test case?
This test case inv
On 04/25/2018 05:08 AM, Thomas Huth wrote:
When we want to support pxelinux-style network booting later, we've got
to do several TFTP transfers - and we do not want to apply for a new IP
address via DHCP each time. So split up net_load into three parts:
1. net_init(), which initializes virtio-
c | 8
pc-bios/s390-ccw/sclp.c | 2 +-
pc-bios/s390-ccw/sclp.h | 2 +-
4 files changed, 9 insertions(+), 7 deletions(-)
Reviewed-by: Farhan Ali
On 05/30/2018 05:16 AM, Thomas Huth wrote:
Since it is quite cumbersome to manually create a combined kernel with
initrd image for network booting, we now support loading via pxelinux
configuration files, too. In these files, the kernel, initrd and command
line parameters can be specified sepe
Reviewed-by: Farhan Ali
On 05/31/2018 11:21 PM, Thomas Huth wrote:
Just a question do we want to clear cfgbuf here, before calling
pxelinux_load_parse_cfg?
That's theoretically not necessary. The buffer either gets populated
with data, or the function errors out. The code also makes sure that
there is a final NUL-ch
On 07/27/2018 09:26 AM, Stefan Hajnoczi wrote:
On Mon, Jul 23, 2018 at 12:42:02PM -0400, Farhan Ali wrote:
On 07/23/2018 12:30 PM, Stefan Hajnoczi wrote:
On Fri, Jul 20, 2018 at 03:11:14PM -0400, Farhan Ali wrote:
I am seeing another issue pop up, in a different test. Even though it
Polite ping :)
Would like to know how to merge these patches in the mainline kernel.
Thanks
Farhan
On 06/19/2018 11:41 AM, Farhan Ali wrote:
Hi,
Currently the Linux virtio-crypto driver registers the crypto
algorithm without verifying if the backend actually supports the
algorithm.
This
On 06/15/2018 09:17 AM, Viktor VM Mihajlovski wrote:
On 14.06.2018 18:12, Farhan Ali wrote:
On 06/14/2018 11:10 AM, Daniel P. Berrangé wrote:
On Thu, Jun 14, 2018 at 10:50:40AM -0400, Farhan Ali wrote:
On 06/14/2018 04:21 AM, Daniel P. Berrangé wrote:
On Wed, Jun 13, 2018 at 07:28
A polite ping :)
If no one has any more comments/feedback then I would like to how to
merge these patches to the mainline kernel tree.
Thanks
Farhan
On 06/13/2018 04:38 PM, Farhan Ali wrote:
Hi,
Currently the Linux virtio-crypto driver registers the crypto
algorithm without verifying if
On 06/19/2018 10:32 AM, Herbert Xu wrote:
On Tue, Jun 19, 2018 at 04:08:05PM +0200, Christian Borntraeger wrote:
On 06/19/2018 03:26 PM, Farhan Ali wrote:
A polite ping :)
If no one has any more comments/feedback then I would like to how to merge
these patches to the mainline kernel tree
Read the crypto services and algorithm masks which provides
information about the services and algorithms supported by
virtio-crypto backend.
Signed-off-by: Farhan Ali
Acked-by: Gonglei
Acked-by: Christian Borntraeger
---
drivers/crypto/virtio/virtio_crypto_common.h | 14
v3
- Add Christian Borntrager's acks for the patches.
v1 -> v2
- Modify comment as suggested by Arei (patch 1)
- Modify error message as suggested by Arei (patch 2)
Farhan Ali (2):
crypto/virtio-crypto: Read crypto services and algorithm masks
crypto/virtio-crypto: Register an algo o
From: Farhan Ali
Register a crypto algo with the Linux crypto layer only if
the algorithm is supported by the backend virtio-crypto
device.
Also route crypto requests to a virtio-crypto
device, only if it can support the requested service and
algorithm.
Signed-off-by: Farhan Ali
Acked-by
also makes the driver more compliant with
the virtio-crypto spec [1].
I would appreciate any feedback or comments on this.
Thank you
Farhan
Reference
-
[1] Virtio crypto spec proposal
https://lists.gnu.org/archive/html/qemu-devel/2017-12/msg00816.html
Farhan Ali (2):
crypto/virtio
Read the crypto services and algorithm masks which provides
information about the services and algorithms supported by
virtio-crypto backend.
Signed-off-by: Farhan Ali
---
drivers/crypto/virtio/virtio_crypto_common.h | 14 ++
drivers/crypto/virtio/virtio_crypto_core.c | 29
From: Farhan Ali
Register a crypto algo with the Linux crypto layer only if
the algorithm is supported by the backend virtio-crypto
device.
Also route crypto requests to a virtio-crypto
device, only if it can support the requested service and
algorithm.
Signed-off-by: Farhan Ali
---
drivers
Hi Arei
On 06/11/2018 02:43 AM, Gonglei (Arei) wrote:
-Original Message-
From: Farhan Ali [mailto:al...@linux.ibm.com]
Sent: Saturday, June 09, 2018 3:09 AM
To: linux-ker...@vger.kernel.org; k...@vger.kernel.org
Cc: m...@redhat.com; qemu-devel@nongnu.org; Gonglei (Arei)
; longpeng
On 06/11/2018 04:48 AM, Gonglei (Arei) wrote:
-Original Message-
From: Farhan Ali [mailto:al...@linux.ibm.com]
Sent: Saturday, June 09, 2018 3:09 AM
To: linux-ker...@vger.kernel.org; k...@vger.kernel.org
Cc: m...@redhat.com; qemu-devel@nongnu.org; Gonglei (Arei)
; longpeng ;
pa
adds support for disabling the cipher
algorithms of the backend cryptodev.
eg:
-object cryptodev-backend-builtin,id=cryptodev0
-device virtio-crypto-ccw,id=crypto0,cryptodev=cryptodev0,cipher-aes-cbc=off
Signed-off-by: Farhan Ali
---
Please note this patch is not complete, and there are TODOs to
Hi Daniel
On 06/13/2018 05:37 AM, Daniel P. Berrangé wrote:
On Tue, Jun 12, 2018 at 03:48:34PM -0400, Farhan Ali wrote:
The virtio-crypto driver currently propagates to the guest
all the cipher algorithms that the backend cryptodev can
support. But in certain cases where the guest has more
Hi Arei
On 06/12/2018 08:57 PM, Gonglei (Arei) wrote:
-Original Message-
From: Farhan Ali [mailto:al...@linux.ibm.com]
Sent: Wednesday, June 13, 2018 3:49 AM
To: qemu-devel@nongnu.org
Cc: m...@redhat.com; Gonglei (Arei) ; longpeng
; pa...@linux.ibm.com; borntrae...@de.ibm.com;
fran
From: Farhan Ali
Register a crypto algo with the Linux crypto layer only if
the algorithm is supported by the backend virtio-crypto
device.
Also route crypto requests to a virtio-crypto
device, only if it can support the requested service and
algorithm.
Signed-off-by: Farhan Ali
Acked-by
Read the crypto services and algorithm masks which provides
information about the services and algorithms supported by
virtio-crypto backend.
Signed-off-by: Farhan Ali
Acked-by: Gonglei
---
drivers/crypto/virtio/virtio_crypto_common.h | 14 ++
drivers/crypto/virtio
v2
- Modify comment as suggested by Arei (patch 1)
- Modify error message as suggested by Arei (patch 2)
Farhan Ali (2):
crypto/virtio-crypto: Read crypto services and algorithm masks
crypto/virtio-crypto: Register an algo only if it's supported
drivers/crypto/virtio/virtio_crypto_algs.c
On 06/14/2018 04:21 AM, Daniel P. Berrangé wrote:
On Wed, Jun 13, 2018 at 07:28:08PM +0200, Halil Pasic wrote:
On 06/13/2018 05:05 PM, Daniel P. Berrangé wrote:
On Wed, Jun 13, 2018 at 11:01:05AM -0400, Farhan Ali wrote:
Hi Daniel
On 06/13/2018 05:37 AM, Daniel P. Berrangé wrote:
On
On 06/14/2018 11:10 AM, Daniel P. Berrangé wrote:
On Thu, Jun 14, 2018 at 10:50:40AM -0400, Farhan Ali wrote:
On 06/14/2018 04:21 AM, Daniel P. Berrangé wrote:
On Wed, Jun 13, 2018 at 07:28:08PM +0200, Halil Pasic wrote:
On 06/13/2018 05:05 PM, Daniel P. Berrangé wrote:
On Wed, Jun 13
Virtio GPU code currently only supports litte endian format,
and so using the Virtio GPU device on a big endian machine
does not work.
Let's fix it by supporting the correct host cpu byte order.
Signed-off-by: Farhan Ali
---
hw/display/virtio-gpu.c
,devno=fe.0.0101
-vnc host_ip_addr:5900
Note, to actually see any display content the
guest kernel needs to support DRM layer, Virtio GPU driver,
the Virtual Terminal layer etc.
I would appreciate any feedback on these patches, specially the
first patch.
Thank you
Farhan
Farhan Ali (2
Wire up the virtio-gpu device for the CCW bus. The virtio-gpu
is a virtio-1 device, so disable revision 0.
Signed-off-by: Farhan Ali
Acked-by: Christian Borntraeger
---
hw/s390x/virtio-ccw.c | 54 +++
hw/s390x/virtio-ccw.h | 10 ++
2
On 09/13/2017 04:13 AM, Gerd Hoffmann wrote:
Please move this to a helper function, maybe by updating the
VIRTIO_GPU_FILL_CMD macro.
The header fields should be byteswapped too. As most structs have
32bit fields only (with the exception of hdr.fence_id) you should be
able to create a generic
On 09/13/2017 03:00 PM, Thomas Huth wrote:
On 12.09.2017 16:26, Farhan Ali wrote:
These patches wire up the virtio-gpu device for CCW bus for S390.
For the S390 architecture which does not natively support any
graphics device, virtio gpu in 2D mode could be used to emulate a
simple graphics
Virtio GPU code currently only supports litte endian format,
and so using the Virtio GPU device on a big endian machine
does not work.
Let's fix it by supporting the correct host cpu byte order.
Signed-off-by: Farhan Ali
---
hw/display/virtio-gpu.c
1 - 100 of 151 matches
Mail list logo
