From: Jeuk Kim <jeuk20.kim@samsung.com>
To: Bart Van Assche <bvanassche@acm.org>,
Adrian Hunter <adrian.hunter@intel.com>
Cc: "jejb@linux.ibm.com" <jejb@linux.ibm.com>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
"avri.altman@wdc.com" <avri.altman@wdc.com>,
"dlunev@chromium.org" <dlunev@chromium.org>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] scsi: ufs: ufs-pci: Add support for QEMU
Date: Wed, 02 Aug 2023 10:20:35 +0900 [thread overview]
Message-ID: <20230802012035epcms2p4a6827b9192dc50b7ebd2d24de72f3fb5@epcms2p4> (raw)
In-Reply-To: <9bb7ac58-db99-238f-0d2c-450470f05c74@acm.org>
On 8/1/23, Bart Van Assche wrote:
> On 8/1/23 04:12, Adrian Hunter wrote:
> > I was really hoping for an explanation of "Why?" i.e.
> > why does anyone want a virtual UFS device? Why not use
> > any existing virtual block device?
>
> I hope this will enable testing of the UFS driver inside a virtual machine
> on systems without UFS host controller. Jeuk, is that correct?
>
> Thanks,
>
> Bart.
Hi Bart!
That's right.
I would say there are 3 main reasons why we need UFS virtualization.
1) As Bart said, it enables to test UFS drivers on virtual machines on
systems without UFS host controller.
2) It works as an emulation, so it's easier to reproduce and debug bug
situations on the device than on a real device.
3) It is easy to preemptively implement and test new features before the
real device is created.
Thanks,
Jeuk
prev parent reply other threads:[~2023-08-02 1:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20230801073750epcms2p121c08e452aaafdda301c5562f4ccff5b@epcms2p1>
2023-08-01 7:37 ` Jeuk Kim
2023-08-01 8:25 ` Adrian Hunter
[not found] ` <CGME20230801073750epcms2p121c08e452aaafdda301c5562f4ccff5b@epcms2p4>
2023-08-01 9:20 ` Jeuk Kim
2023-08-01 11:12 ` Adrian Hunter
2023-08-01 18:20 ` Bart Van Assche
2023-08-02 1:20 ` Jeuk Kim [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230802012035epcms2p4a6827b9192dc50b7ebd2d24de72f3fb5@epcms2p4 \
--to=jeuk20.kim@samsung.com \
--cc=adrian.hunter@intel.com \
--cc=avri.altman@wdc.com \
--cc=bvanassche@acm.org \
--cc=dlunev@chromium.org \
--cc=jejb@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®