VIRTIO iface in mtd

VIRTIO iface in mtd

[Marcin Krzemiński]

Hello,

recently I have spoken with Boris regarding new MTD driver
that will use VIRTIO interface to communicate with Qemu.
To specify how should this look like exactly I am bringing the topic
on ML.
My understanding is that this driver will use VIRTIO to communicate
with Qemu. From Qemu side at the end there will be a file that will
simulate NAND/NOR. Is it correct?
What use cases do you have in mind for this?

Bast regards,
Marcin

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: VIRTIO iface in mtd

[Boris Brezillon]

+Richard and Miquel

Hi Marcin,

On Thu, 17 Jan 2019 21:16:19 +0100
Marcin Krzemiński <mar.krzeminski@gmail.com> wrote:

> Hello,
> 
> recently I have spoken with Boris regarding new MTD driver
> that will use VIRTIO interface to communicate with Qemu.
> To specify how should this look like exactly I am bringing the topic
> on ML.

Thanks for starting this discussion.

> My understanding is that this driver will use VIRTIO to communicate
> with Qemu. From Qemu side at the end there will be a file that will
> simulate NAND/NOR. Is it correct?

That's my understanding, but I'm not really a virtio or qemu expert so
I might be wrong.

> What use cases do you have in mind for this?

I have one in mind: simulate NAND (in particular MLC NAND) behavior in
a pseudo-realistic way to validate UBI/UBIFS code (or any other
FS/wear-leveling/FTL code) we might want to use on top of such devices

I'd also like to replace nandsim by this emulation approach. Indeed,
nandsim is emulating the parallel NAND protocol more than anything
else, which we don't really care about unless we need to test the raw
NAND framework (and I think there are better solutions to do that). On
the other hand, because nandsim tries to use the full raw NAND stack,
it's often hard to emulate real devices (ID-based detection does not
work for ONFI/JEDEC compatible devices). All of this makes nandsim a
poor choice when the user wants to emulate a NAND device to do
post-mortem analysis using a NAND dump.

Richard probably a few more use cases ;-).

Regards,

Boris

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: VIRTIO iface in mtd

[Marcin Krzemiński]

On 17.01.2019 21:46, Boris Brezillon wrote:
> +Richard and Miquel
>
> Hi Marcin,
>
> On Thu, 17 Jan 2019 21:16:19 +0100
> Marcin Krzemiński <mar.krzeminski@gmail.com> wrote:
>
>> Hello,
>>
>> recently I have spoken with Boris regarding new MTD driver
>> that will use VIRTIO interface to communicate with Qemu.
>> To specify how should this look like exactly I am bringing the topic
>> on ML.
> Thanks for starting this discussion.
Np :)
>
>> My understanding is that this driver will use VIRTIO to communicate
>> with Qemu. From Qemu side at the end there will be a file that will
>> simulate NAND/NOR. Is it correct?
> That's my understanding, but I'm not really a virtio or qemu expert so
> I might be wrong.
>
>> What use cases do you have in mind for this?
> I have one in mind: simulate NAND (in particular MLC NAND) behavior in
> a pseudo-realistic way to validate UBI/UBIFS code (or any other
> FS/wear-leveling/FTL code) we might want to use on top of such devices
In this place my question is what we remove from emulation?
I understand that communication layer is removed, however communication 
protocol
need t o stay? Eg. because NAND and OOB.

>
> I'd also like to replace nandsim by this emulation approach. Indeed,
> nandsim is emulating the parallel NAND protocol more than anything
> else, which we don't really care about unless we need to test the raw
> NAND framework (and I think there are better solutions to do that). On
> the other hand, because nandsim tries to use the full raw NAND stack,
> it's often hard to emulate real devices (ID-based detection does not
> work for ONFI/JEDEC compatible devices). All of this makes nandsim a
> poor choice when the user wants to emulate a NAND device to do
> post-mortem analysis using a NAND dump.
This I need to understand better. If we eg. have NAND dump, do we care 
with OOB or ECC,
or not?

At the end I also need to add, that I understand NOR devices, but 
unfortunately
I have low experience with NANDs. This could lead to some misunderstands :(

Thanks,
Marcin
>
> Richard probably a few more use cases ;-).
>
> Regards,
>
> Boris


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: VIRTIO iface in mtd

[Boris Brezillon]

On Fri, 18 Jan 2019 21:03:17 +0100
Marcin Krzemiński <mar.krzeminski@gmail.com> wrote:

> >  
> >> My understanding is that this driver will use VIRTIO to communicate
> >> with Qemu. From Qemu side at the end there will be a file that will
> >> simulate NAND/NOR. Is it correct?  
> > That's my understanding, but I'm not really a virtio or qemu expert so
> > I might be wrong.
> >  
> >> What use cases do you have in mind for this?  
> > I have one in mind: simulate NAND (in particular MLC NAND) behavior in
> > a pseudo-realistic way to validate UBI/UBIFS code (or any other
> > FS/wear-leveling/FTL code) we might want to use on top of such devices  
> In this place my question is what we remove from emulation?
> I understand that communication layer is removed, however communication 
> protocol
> need t o stay? Eg. because NAND and OOB.

If by protocol you mean the fact that a NAND has an out-of-band and an
in-band area, then yes, we want to emulate that. What I meant by
"protocol" was the how you interact with a parallel or SPI NAND ("send
this opcode to do this or that"), and we definitely don't want to
emulate that part.

> 
> >
> > I'd also like to replace nandsim by this emulation approach. Indeed,
> > nandsim is emulating the parallel NAND protocol more than anything
> > else, which we don't really care about unless we need to test the raw
> > NAND framework (and I think there are better solutions to do that). On
> > the other hand, because nandsim tries to use the full raw NAND stack,
> > it's often hard to emulate real devices (ID-based detection does not
> > work for ONFI/JEDEC compatible devices). All of this makes nandsim a
> > poor choice when the user wants to emulate a NAND device to do
> > post-mortem analysis using a NAND dump.  
> This I need to understand better. If we eg. have NAND dump, do we care 
> with OOB or ECC,
> or not?

Yes we should. For the ECC part, it will be hard to emulate HW ECC
engine, but we can at least specify the layout in use on the board
(which OOB portions are used to store ECC bytes and which ones are
containing user data or bad block markers).

> 
> At the end I also need to add, that I understand NOR devices, but 
> unfortunately
> I have low experience with NANDs. This could lead to some misunderstands :(

We can help with that.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: VIRTIO iface in mtd

[Richard Weinberger]

Hi!

Sorry for joining this discussion so late.
I didn't notice the private mails. ;-\

Am Freitag, 18. Januar 2019, 21:44:55 CET schrieb Boris Brezillon:
> On Fri, 18 Jan 2019 21:03:17 +0100
> Marcin Krzemiński <mar.krzeminski@gmail.com> wrote:
> 
> > >  
> > >> My understanding is that this driver will use VIRTIO to communicate
> > >> with Qemu. From Qemu side at the end there will be a file that will
> > >> simulate NAND/NOR. Is it correct?  
> > > That's my understanding, but I'm not really a virtio or qemu expert so
> > > I might be wrong.
> > >  
> > >> What use cases do you have in mind for this?  
> > > I have one in mind: simulate NAND (in particular MLC NAND) behavior in
> > > a pseudo-realistic way to validate UBI/UBIFS code (or any other
> > > FS/wear-leveling/FTL code) we might want to use on top of such devices  
> > In this place my question is what we remove from emulation?
> > I understand that communication layer is removed, however communication 
> > protocol
> > need t o stay? Eg. because NAND and OOB.
> 
> If by protocol you mean the fact that a NAND has an out-of-band and an
> in-band area, then yes, we want to emulate that. What I meant by
> "protocol" was the how you interact with a parallel or SPI NAND ("send
> this opcode to do this or that"), and we definitely don't want to
> emulate that part.
> 
> > 
> > >
> > > I'd also like to replace nandsim by this emulation approach. Indeed,
> > > nandsim is emulating the parallel NAND protocol more than anything
> > > else, which we don't really care about unless we need to test the raw
> > > NAND framework (and I think there are better solutions to do that). On
> > > the other hand, because nandsim tries to use the full raw NAND stack,
> > > it's often hard to emulate real devices (ID-based detection does not
> > > work for ONFI/JEDEC compatible devices). All of this makes nandsim a
> > > poor choice when the user wants to emulate a NAND device to do
> > > post-mortem analysis using a NAND dump.  
> > This I need to understand better. If we eg. have NAND dump, do we care 
> > with OOB or ECC,
> > or not?
> 
> Yes we should. For the ECC part, it will be hard to emulate HW ECC
> engine, but we can at least specify the layout in use on the board
> (which OOB portions are used to store ECC bytes and which ones are
> containing user data or bad block markers).
> 
> > 
> > At the end I also need to add, that I understand NOR devices, but 
> > unfortunately
> > I have low experience with NANDs. This could lead to some misunderstands :(
> 
> We can help with that.

Yes, I'll happily help.

I'm unhappy with nandsim mostly because it emulates the chip itself, which is
these days almost useless and inefficient.
To find bugs in nand_base.c it helps only in theory, in reality we trigger
bugs in nandsim's NAND emulation.

I tried to overhaul nandsim some time ago:
https://lkml.org/lkml/2016/8/31/67
But Boris convinced me that I should not ride a dead horse. ;-)

So, the basic idea is having a simple and stupid kernel-driver which implements
the MTD interface and can act like whatever we want.
The logic shall happen in an emulator like qemu.
Think of virtio-blk or virtio-scsi.

Beside of emulating various flashes, I have mostly testing in mind.
Testing like power-cut emulation, io logging and replay, simulation of
MLC issues (paired-pages), ...

Thanks,
//richard



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: VIRTIO iface in mtd

[Marcin Krzemiński]

On 18.01.2019 22:25, Richard Weinberger wrote:
> Hi!
>
> Sorry for joining this discussion so late.
> I didn't notice the private mails. ;-\
No problem :)
>
> Am Freitag, 18. Januar 2019, 21:44:55 CET schrieb Boris Brezillon:
>> On Fri, 18 Jan 2019 21:03:17 +0100
>> Marcin Krzemiński <mar.krzeminski@gmail.com> wrote:
>>
>>>>   
>>>>> My understanding is that this driver will use VIRTIO to communicate
>>>>> with Qemu. From Qemu side at the end there will be a file that will
>>>>> simulate NAND/NOR. Is it correct?
>>>> That's my understanding, but I'm not really a virtio or qemu expert so
>>>> I might be wrong.
>>>>   
>>>>> What use cases do you have in mind for this?
>>>> I have one in mind: simulate NAND (in particular MLC NAND) behavior in
>>>> a pseudo-realistic way to validate UBI/UBIFS code (or any other
>>>> FS/wear-leveling/FTL code) we might want to use on top of such devices
>>> In this place my question is what we remove from emulation?
>>> I understand that communication layer is removed, however communication
>>> protocol
>>> need t o stay? Eg. because NAND and OOB.
>> If by protocol you mean the fact that a NAND has an out-of-band and an
>> in-band area, then yes, we want to emulate that. What I meant by
>> "protocol" was the how you interact with a parallel or SPI NAND ("send
>> this opcode to do this or that"), and we definitely don't want to
>> emulate that part.
>>
>>>> I'd also like to replace nandsim by this emulation approach. Indeed,
>>>> nandsim is emulating the parallel NAND protocol more than anything
>>>> else, which we don't really care about unless we need to test the raw
>>>> NAND framework (and I think there are better solutions to do that). On
>>>> the other hand, because nandsim tries to use the full raw NAND stack,
>>>> it's often hard to emulate real devices (ID-based detection does not
>>>> work for ONFI/JEDEC compatible devices). All of this makes nandsim a
>>>> poor choice when the user wants to emulate a NAND device to do
>>>> post-mortem analysis using a NAND dump.
>>> This I need to understand better. If we eg. have NAND dump, do we care
>>> with OOB or ECC,
>>> or not?
>> Yes we should. For the ECC part, it will be hard to emulate HW ECC
>> engine, but we can at least specify the layout in use on the board
>> (which OOB portions are used to store ECC bytes and which ones are
>> containing user data or bad block markers).
>>
>>> At the end I also need to add, that I understand NOR devices, but
>>> unfortunately
>>> I have low experience with NANDs. This could lead to some misunderstands :(
>> We can help with that.
> Yes, I'll happily help.
>
> I'm unhappy with nandsim mostly because it emulates the chip itself, which is
> these days almost useless and inefficient.
> To find bugs in nand_base.c it helps only in theory, in reality we trigger
> bugs in nandsim's NAND emulation.
I guess it could help to catch regression...
>
> I tried to overhaul nandsim some time ago:
> https://lkml.org/lkml/2016/8/31/67
> But Boris convinced me that I should not ride a dead horse. ;-)
>
> So, the basic idea is having a simple and stupid kernel-driver which implements
> the MTD interface and can act like whatever we want.
> The logic shall happen in an emulator like qemu.
> Think of virtio-blk or virtio-scsi.
That seem to be reasonable and mach my understand of the topic.
MTD driver would be nothing more that translator between MTD and Qemu 
(over virtio).
As Boris suggested and additional channel to modify Qemus behavior from 
guest (eg. inserting ECC errors)?
Eg. from sysf?

Real unknown for me is Qemu part. Eg. basic question how does NAND dumps 
should look like?
It should consist only real data or sectors images(with OOB). Or both?
>
> Beside of emulating various flashes, I have mostly testing in mind.
> Testing like power-cut emulation, io logging and replay, simulation of
> MLC issues (paired-pages), ...
Thanks,
Marcin

>
> Thanks,
> //richard
>
>


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: VIRTIO iface in mtd

[Boris Brezillon]

Hi Marcin,

On Sun, 20 Jan 2019 20:49:46 +0100
Marcin Krzemiński <mar.krzeminski@gmail.com> wrote:

> On 18.01.2019 22:25, Richard Weinberger wrote:
> > Hi!
> >
> > Sorry for joining this discussion so late.
> > I didn't notice the private mails. ;-\  
> No problem :)
> >
> > Am Freitag, 18. Januar 2019, 21:44:55 CET schrieb Boris Brezillon:  
> >> On Fri, 18 Jan 2019 21:03:17 +0100
> >> Marcin Krzemiński <mar.krzeminski@gmail.com> wrote:
> >>  
> >>>>     
> >>>>> My understanding is that this driver will use VIRTIO to communicate
> >>>>> with Qemu. From Qemu side at the end there will be a file that will
> >>>>> simulate NAND/NOR. Is it correct?  
> >>>> That's my understanding, but I'm not really a virtio or qemu expert so
> >>>> I might be wrong.
> >>>>     
> >>>>> What use cases do you have in mind for this?  
> >>>> I have one in mind: simulate NAND (in particular MLC NAND) behavior in
> >>>> a pseudo-realistic way to validate UBI/UBIFS code (or any other
> >>>> FS/wear-leveling/FTL code) we might want to use on top of such devices  
> >>> In this place my question is what we remove from emulation?
> >>> I understand that communication layer is removed, however communication
> >>> protocol
> >>> need t o stay? Eg. because NAND and OOB.  
> >> If by protocol you mean the fact that a NAND has an out-of-band and an
> >> in-band area, then yes, we want to emulate that. What I meant by
> >> "protocol" was the how you interact with a parallel or SPI NAND ("send
> >> this opcode to do this or that"), and we definitely don't want to
> >> emulate that part.
> >>  
> >>>> I'd also like to replace nandsim by this emulation approach. Indeed,
> >>>> nandsim is emulating the parallel NAND protocol more than anything
> >>>> else, which we don't really care about unless we need to test the raw
> >>>> NAND framework (and I think there are better solutions to do that). On
> >>>> the other hand, because nandsim tries to use the full raw NAND stack,
> >>>> it's often hard to emulate real devices (ID-based detection does not
> >>>> work for ONFI/JEDEC compatible devices). All of this makes nandsim a
> >>>> poor choice when the user wants to emulate a NAND device to do
> >>>> post-mortem analysis using a NAND dump.  
> >>> This I need to understand better. If we eg. have NAND dump, do we care
> >>> with OOB or ECC,
> >>> or not?  
> >> Yes we should. For the ECC part, it will be hard to emulate HW ECC
> >> engine, but we can at least specify the layout in use on the board
> >> (which OOB portions are used to store ECC bytes and which ones are
> >> containing user data or bad block markers).
> >>  
> >>> At the end I also need to add, that I understand NOR devices, but
> >>> unfortunately
> >>> I have low experience with NANDs. This could lead to some misunderstands :(  
> >> We can help with that.  
> > Yes, I'll happily help.
> >
> > I'm unhappy with nandsim mostly because it emulates the chip itself, which is
> > these days almost useless and inefficient.
> > To find bugs in nand_base.c it helps only in theory, in reality we trigger
> > bugs in nandsim's NAND emulation.  
> I guess it could help to catch regression...

In practice nandsim does not catch most regressions, simply because
it's only using a small part of the raw NAND code base.

> >
> > I tried to overhaul nandsim some time ago:
> > https://lkml.org/lkml/2016/8/31/67
> > But Boris convinced me that I should not ride a dead horse. ;-)
> >
> > So, the basic idea is having a simple and stupid kernel-driver which implements
> > the MTD interface and can act like whatever we want.
> > The logic shall happen in an emulator like qemu.
> > Think of virtio-blk or virtio-scsi.  
> That seem to be reasonable and mach my understand of the topic.
> MTD driver would be nothing more that translator between MTD and Qemu 
> (over virtio).
> As Boris suggested and additional channel to modify Qemus behavior from 
> guest (eg. inserting ECC errors)?

Actually, I was expecting to insert bitflips, erase/program errors,
badblock, ... on the host side. The side channel would allow us to
inform the guest about those errors.

> Eg. from sysf?
> 
> Real unknown for me is Qemu part. Eg. basic question how does NAND dumps 
> should look like?
> It should consist only real data or sectors images(with OOB). Or both?

Not sure what you mean by "real data" and "sectors images", but qemu
NAND images should definitely contain OOB when applicable (IOW,
when emulating NAND devices). How you store it is up to you (can be
interleaved with in-band data like of a real device or stored in a
separate section of the qemu NAND image file, or even stored in a
separate file). Oh, and you'll have to store metadata too, like which
block is bad, the position of the emulated bitflips in each page, the
pages/blocks you want to generate errors on when a write/erase it
executed, ...

Also, I think one feature Richard would love is a way to record each
write/erase operation in order so than you can easily replay a
sequence step by step and see if FS/Wear-leveling layer is about to
mount/recover from errors in between each of those intermediate
states. This would require having a extra file where you store
operation and associated metadata (like the data written in case of a
write) in a separate file.

Anyway, this is already an advanced feature, and I think we should
start small: emulate NOR/NAND devices without any way to emulate
bitflips or erase/program errors. Once we have that in place, we can
start adding fancy features on top.

Regards,

Boris

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: VIRTIO iface in mtd

[Marcin Krzemiński]

Hi Boris,


On 21.01.2019 09:07, Boris Brezillon wrote:
> Hi Marcin,
>
> On Sun, 20 Jan 2019 20:49:46 +0100
> Marcin Krzemiński <mar.krzeminski@gmail.com> wrote:
>
>> On 18.01.2019 22:25, Richard Weinberger wrote:
>>> Hi!
>>>
>>> Sorry for joining this discussion so late.
>>> I didn't notice the private mails. ;-\
>> No problem :)
>>> Am Freitag, 18. Januar 2019, 21:44:55 CET schrieb Boris Brezillon:
>>>> On Fri, 18 Jan 2019 21:03:17 +0100
>>>> Marcin Krzemiński <mar.krzeminski@gmail.com> wrote:
>>>>   
>>>>>>      
>>>>>>> My understanding is that this driver will use VIRTIO to communicate
>>>>>>> with Qemu. From Qemu side at the end there will be a file that will
>>>>>>> simulate NAND/NOR. Is it correct?
>>>>>> That's my understanding, but I'm not really a virtio or qemu expert so
>>>>>> I might be wrong.
>>>>>>      
>>>>>>> What use cases do you have in mind for this?
>>>>>> I have one in mind: simulate NAND (in particular MLC NAND) behavior in
>>>>>> a pseudo-realistic way to validate UBI/UBIFS code (or any other
>>>>>> FS/wear-leveling/FTL code) we might want to use on top of such devices
>>>>> In this place my question is what we remove from emulation?
>>>>> I understand that communication layer is removed, however communication
>>>>> protocol
>>>>> need t o stay? Eg. because NAND and OOB.
>>>> If by protocol you mean the fact that a NAND has an out-of-band and an
>>>> in-band area, then yes, we want to emulate that. What I meant by
>>>> "protocol" was the how you interact with a parallel or SPI NAND ("send
>>>> this opcode to do this or that"), and we definitely don't want to
>>>> emulate that part.
>>>>   
>>>>>> I'd also like to replace nandsim by this emulation approach. Indeed,
>>>>>> nandsim is emulating the parallel NAND protocol more than anything
>>>>>> else, which we don't really care about unless we need to test the raw
>>>>>> NAND framework (and I think there are better solutions to do that). On
>>>>>> the other hand, because nandsim tries to use the full raw NAND stack,
>>>>>> it's often hard to emulate real devices (ID-based detection does not
>>>>>> work for ONFI/JEDEC compatible devices). All of this makes nandsim a
>>>>>> poor choice when the user wants to emulate a NAND device to do
>>>>>> post-mortem analysis using a NAND dump.
>>>>> This I need to understand better. If we eg. have NAND dump, do we care
>>>>> with OOB or ECC,
>>>>> or not?
>>>> Yes we should. For the ECC part, it will be hard to emulate HW ECC
>>>> engine, but we can at least specify the layout in use on the board
>>>> (which OOB portions are used to store ECC bytes and which ones are
>>>> containing user data or bad block markers).
>>>>   
>>>>> At the end I also need to add, that I understand NOR devices, but
>>>>> unfortunately
>>>>> I have low experience with NANDs. This could lead to some misunderstands :(
>>>> We can help with that.
>>> Yes, I'll happily help.
>>>
>>> I'm unhappy with nandsim mostly because it emulates the chip itself, which is
>>> these days almost useless and inefficient.
>>> To find bugs in nand_base.c it helps only in theory, in reality we trigger
>>> bugs in nandsim's NAND emulation.
>> I guess it could help to catch regression...
> In practice nandsim does not catch most regressions, simply because
> it's only using a small part of the raw NAND code base.
>
>>> I tried to overhaul nandsim some time ago:
>>> https://lkml.org/lkml/2016/8/31/67
>>> But Boris convinced me that I should not ride a dead horse. ;-)
>>>
>>> So, the basic idea is having a simple and stupid kernel-driver which implements
>>> the MTD interface and can act like whatever we want.
>>> The logic shall happen in an emulator like qemu.
>>> Think of virtio-blk or virtio-scsi.
>> That seem to be reasonable and mach my understand of the topic.
>> MTD driver would be nothing more that translator between MTD and Qemu
>> (over virtio).
>> As Boris suggested and additional channel to modify Qemus behavior from
>> guest (eg. inserting ECC errors)?
> Actually, I was expecting to insert bitflips, erase/program errors,
> badblock, ... on the host side. The side channel would allow us to
> inform the guest about those errors.
I am proposing guest to allow inserting errors in the given moment of time.
 From the other side this can be done in a different way. We could skip this
topic at the moment/
>
>> Eg. from sysf?
>>
>> Real unknown for me is Qemu part. Eg. basic question how does NAND dumps
>> should look like?
>> It should consist only real data or sectors images(with OOB). Or both?
> Not sure what you mean by "real data" and "sectors images", but qemu
> NAND images should definitely contain OOB when applicable (IOW,
> when emulating NAND devices). How you store it is up to you (can be
> interleaved with in-band data like of a real device or stored in a
> separate section of the qemu NAND image file, or even stored in a
> separate file). Oh, and you'll have to store metadata too, like which
> block is bad, the position of the emulated bitflips in each page, the
> pages/blocks you want to generate errors on when a write/erase it
> executed, ...
I narrowed down the problem to one real file. You are right, beside 
actual data,
many metadata needs to be emulated.
>
> Also, I think one feature Richard would love is a way to record each
> write/erase operation in order so than you can easily replay a
> sequence step by step and see if FS/Wear-leveling layer is about to
> mount/recover from errors in between each of those intermediate
> states. This would require having a extra file where you store
> operation and associated metadata (like the data written in case of a
> write) in a separate file.
Actually this look to be pretty simple :)
>
> Anyway, this is already an advanced feature, and I think we should
> start small: emulate NOR/NAND devices without any way to emulate
> bitflips or erase/program errors. Once we have that in place, we can
> start adding fancy features on top.
That is exactly what I wanted to propose. Simple kernel driver and Qemu 
implementation.
Can you tell me which MTD driver would be the best starting point?

Thanks,
Marcin
>
> Regards,
>
> Boris


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: VIRTIO iface in mtd

[Boris Brezillon]

On Mon, 21 Jan 2019 19:14:35 +0100
Marcin Krzemiński <mar.krzeminski@gmail.com> wrote:

> >> As Boris suggested and additional channel to modify Qemus behavior from
> >> guest (eg. inserting ECC errors)?  
> > Actually, I was expecting to insert bitflips, erase/program errors,
> > badblock, ... on the host side. The side channel would allow us to
> > inform the guest about those errors.  
> I am proposing guest to allow inserting errors in the given moment of time.
>  From the other side this can be done in a different way. We could skip this
> topic at the moment/

Agreed.

> > Anyway, this is already an advanced feature, and I think we should
> > start small: emulate NOR/NAND devices without any way to emulate
> > bitflips or erase/program errors. Once we have that in place, we can
> > start adding fancy features on top.  
> That is exactly what I wanted to propose. Simple kernel driver and Qemu 
> implementation.
> Can you tell me which MTD driver would be the best starting point?

Not sure an MTD driver can help. The MTD interface is pretty
straightforward and the most complicated part is probably the virtio
aspect. For a NAND device, you'll have to populate ->_read_oob(),
->_write_oob(), ->_erase(), ->block_isreserved(), ->block_isbad(),
->_block_markbad(), ->erasesize, ->writesize, ->writebufsize, ->type,
->flags (see [1]).

[1]https://elixir.bootlin.com/linux/v5.0-rc3/source/drivers/mtd/nand/raw/nand_base.c



> 
> Thanks,
> Marcin
> >
> > Regards,
> >
> > Boris  
> 


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/