Patchwork hw/vexpress: set default block type to SD

login
register
mail settings
Submitter Aurelien Jarno
Date March 5, 2013, 12:19 a.m.
Message ID <1362442784-22324-1-git-send-email-aurelien@aurel32.net>
Download mbox | patch
Permalink /patch/224860/
State New
Headers show

Comments

Aurelien Jarno - March 5, 2013, 12:19 a.m.
The versatile express has no SCSI card, but instead boot on an SD card.
Change block_default_type accordingly.

Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
---
 hw/vexpress.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
Peter Maydell - March 5, 2013, 12:22 a.m.
On 5 March 2013 08:19, Aurelien Jarno <aurelien@aurel32.net> wrote:
> The versatile express has no SCSI card, but instead boot on an SD card.
> Change block_default_type accordingly.

I notice that no other board has SD as the block_default_type...

What effect does this actually have on the user experience?
Also, won't vl.c now try to create a cdrom drive on the SD interface?

-- PMM
Aurelien Jarno - March 5, 2013, 12:44 a.m.
On Tue, Mar 05, 2013 at 08:22:57AM +0800, Peter Maydell wrote:
> On 5 March 2013 08:19, Aurelien Jarno <aurelien@aurel32.net> wrote:
> > The versatile express has no SCSI card, but instead boot on an SD card.
> > Change block_default_type accordingly.
> 
> I notice that no other board has SD as the block_default_type...
> 
> What effect does this actually have on the user experience?

The effect is that the user don't has to specify the interface type.
Basically:

  -drive file=/path/to/file,if=sd
can be replaced by
  -drive file=/path/to/file

It means the user doesn't have to know the details of the machine to
know how to attach a disk. Note that the user here can also be a script,
which then becomes a bit simpler.

> Also, won't vl.c now try to create a cdrom drive on the SD interface?
> 

It still creates a cdrom drive as before, but still doesn't try to
connect it to the SD interface. In short the behaviour on that side is
unchanged.
Markus Armbruster - March 6, 2013, 9:25 a.m.
Aurelien Jarno <aurelien@aurel32.net> writes:

> On Tue, Mar 05, 2013 at 08:22:57AM +0800, Peter Maydell wrote:
>> On 5 March 2013 08:19, Aurelien Jarno <aurelien@aurel32.net> wrote:
>> > The versatile express has no SCSI card, but instead boot on an SD card.
>> > Change block_default_type accordingly.
>> 
>> I notice that no other board has SD as the block_default_type...
>> 
>> What effect does this actually have on the user experience?
>
> The effect is that the user don't has to specify the interface type.
> Basically:
>
>   -drive file=/path/to/file,if=sd
> can be replaced by
>   -drive file=/path/to/file
>
> It means the user doesn't have to know the details of the machine to
> know how to attach a disk.

Correct.  Also affects monitor commands.

See commit 2d0d2837.

>                            Note that the user here can also be a script,
> which then becomes a bit simpler.
>
>> Also, won't vl.c now try to create a cdrom drive on the SD interface?
>> 
>
> It still creates a cdrom drive as before, but still doesn't try to
> connect it to the SD interface. In short the behaviour on that side is
> unchanged.

An if=sd CD-ROM is weird, but unused weirdness has no effect.

If it bothers you, set .no_cdrom along with .block_default_type.

See also my unsuccessful attempt at getting rid of unused default
drives[*], and observations made during review of Peter's followup
attempt to improve SD cards[**].

[*] http://lists.nongnu.org/archive/html/qemu-devel/2012-08/msg02993.html
[**] http://lists.nongnu.org/archive/html/qemu-devel/2012-08/msg03160.html
Peter Maydell - March 15, 2013, 3:35 p.m.
On 5 March 2013 00:44, Aurelien Jarno <aurelien@aurel32.net> wrote:
> On Tue, Mar 05, 2013 at 08:22:57AM +0800, Peter Maydell wrote:
>> What effect does this actually have on the user experience?
>
> The effect is that the user don't has to specify the interface type.
> Basically:
>
>   -drive file=/path/to/file,if=sd
> can be replaced by
>   -drive file=/path/to/file
>
> It means the user doesn't have to know the details of the machine to
> know how to attach a disk. Note that the user here can also be a script,
> which then becomes a bit simpler.

I'm not convinced this is a good thing -- I think you should have
to know that you're attaching an SD card and not a hard disk,
because the performance is much worse. In particular if you
don't specify 'cache=writeback' your performance will be
dreadful, so you need to do something different from hard
disks anyhow.

-- PMM
Aurelien Jarno - March 15, 2013, 3:42 p.m.
On Fri, Mar 15, 2013 at 03:35:48PM +0000, Peter Maydell wrote:
> On 5 March 2013 00:44, Aurelien Jarno <aurelien@aurel32.net> wrote:
> > On Tue, Mar 05, 2013 at 08:22:57AM +0800, Peter Maydell wrote:
> >> What effect does this actually have on the user experience?
> >
> > The effect is that the user don't has to specify the interface type.
> > Basically:
> >
> >   -drive file=/path/to/file,if=sd
> > can be replaced by
> >   -drive file=/path/to/file
> >
> > It means the user doesn't have to know the details of the machine to
> > know how to attach a disk. Note that the user here can also be a script,
> > which then becomes a bit simpler.
> 
> I'm not convinced this is a good thing -- I think you should have
> to know that you're attaching an SD card and not a hard disk,
> because the performance is much worse. In particular if you
> don't specify 'cache=writeback' your performance will be
> dreadful, so you need to do something different from hard
> disks anyhow.
> 

Being a good thing or not, the current code is wrong: the default
interface type is set to SCSI (I guess it has been copied from
versatilepb.c), while the vexpress machine has no SCSI 
interface.
Peter Maydell - March 15, 2013, 3:45 p.m.
On 15 March 2013 15:42, Aurelien Jarno <aurelien@aurel32.net> wrote:
> On Fri, Mar 15, 2013 at 03:35:48PM +0000, Peter Maydell wrote:
>> I'm not convinced this is a good thing -- I think you should have
>> to know that you're attaching an SD card and not a hard disk,
>> because the performance is much worse. In particular if you
>> don't specify 'cache=writeback' your performance will be
>> dreadful, so you need to do something different from hard
>> disks anyhow.

> Being a good thing or not, the current code is wrong: the default
> interface type is set to SCSI (I guess it has been copied from
> versatilepb.c), while the vexpress machine has no SCSI
> interface.

I agree we shouldn't be claiming to have a scsi interface, yes.

-- PMM
Aurelien Jarno - March 17, 2013, 12:04 a.m.
On Fri, Mar 15, 2013 at 03:45:11PM +0000, Peter Maydell wrote:
> On 15 March 2013 15:42, Aurelien Jarno <aurelien@aurel32.net> wrote:
> > On Fri, Mar 15, 2013 at 03:35:48PM +0000, Peter Maydell wrote:
> >> I'm not convinced this is a good thing -- I think you should have
> >> to know that you're attaching an SD card and not a hard disk,
> >> because the performance is much worse. In particular if you
> >> don't specify 'cache=writeback' your performance will be
> >> dreadful, so you need to do something different from hard
> >> disks anyhow.
> 
> > Being a good thing or not, the current code is wrong: the default
> > interface type is set to SCSI (I guess it has been copied from
> > versatilepb.c), while the vexpress machine has no SCSI
> > interface.
> 
> I agree we shouldn't be claiming to have a scsi interface, yes.
> 

Does it means you are going to accept the patch?

In anycase let me give you some more arguments in favor of it. Even if
you believe that users should always provide a cache= argument, I don't
think it should be done by setting a wrong default interfaces. Users are
likely to simply google for a command line and paste it without
understanding the consequences of cache=writeback. The way to go there
is to make the writeback argument mandatory for some machines if you
really believe it's need by all users.

That said I don't share this opinion. I have made some tests comparing
a versatile and a vexpress machine, running Debian Wheezy, armel for the
first one and armhf for the second one. This has been done on a Core i5
2500 machine with a ST2000DM001 hard drive. Here are the results:

                          | boot | install build-dep | build lm-sensors |
  ------------------------+------+-------------------+------------------+
  versatile               | 1:09 |             2:27  |             4:09 |
  versatile cache=wb      | 1:08 |             2:25  |             3:44 |
  vexpress                | 1:11 |             3:07  |             3:49 |
  vexpress cache=wb       | 1:07 |             3:07  |             3:47 |

  Note: the install build-dep time doesn't include the download time.

So even if the two systems are not directly comparable, it shows that
the SD card emulation is indeed slower than the hard disk one. That said
while cache=writeback makes a difference for the versatile platform, it
doesn't really change anything for the vexpress platform. Therefore
forcing the users to add this option doesn't seems to be a good idea.
Peter Maydell - March 17, 2013, 12:23 a.m.
On 17 March 2013 00:04, Aurelien Jarno <aurelien@aurel32.net> wrote:
> On Fri, Mar 15, 2013 at 03:45:11PM +0000, Peter Maydell wrote:
>> On 15 March 2013 15:42, Aurelien Jarno <aurelien@aurel32.net> wrote:
>> > On Fri, Mar 15, 2013 at 03:35:48PM +0000, Peter Maydell wrote:
>> >> I'm not convinced this is a good thing -- I think you should have
>> >> to know that you're attaching an SD card and not a hard disk,
>> >> because the performance is much worse. In particular if you
>> >> don't specify 'cache=writeback' your performance will be
>> >> dreadful, so you need to do something different from hard
>> >> disks anyhow.
>>
>> > Being a good thing or not, the current code is wrong: the default
>> > interface type is set to SCSI (I guess it has been copied from
>> > versatilepb.c), while the vexpress machine has no SCSI
>> > interface.
>>
>> I agree we shouldn't be claiming to have a scsi interface, yes.
>>
>
> Does it means you are going to accept the patch?

No, I meant I'd accept a patch which stops us reporting that
we have a SCSI interface when we don't.

> In anycase let me give you some more arguments in favor of it. Even if
> you believe that users should always provide a cache= argument, I don't
> think it should be done by setting a wrong default interfaces. Users are
> likely to simply google for a command line and paste it without
> understanding the consequences of cache=writeback. The way to go there
> is to make the writeback argument mandatory for some machines if you
> really believe it's need by all users.

writeback shouldn't be mandatory randomly for some machines and
interfaces and not others.

> That said I don't share this opinion. I have made some tests comparing
> a versatile and a vexpress machine, running Debian Wheezy, armel for the
> first one and armhf for the second one. This has been done on a Core i5
> 2500 machine with a ST2000DM001 hard drive. Here are the results:
>
>                           | boot | install build-dep | build lm-sensors |
>   ------------------------+------+-------------------+------------------+
>   versatile               | 1:09 |             2:27  |             4:09 |
>   versatile cache=wb      | 1:08 |             2:25  |             3:44 |
>   vexpress                | 1:11 |             3:07  |             3:49 |
>   vexpress cache=wb       | 1:07 |             3:07  |             3:47 |
>
>   Note: the install build-dep time doesn't include the download time.
>
> So even if the two systems are not directly comparable, it shows that
> the SD card emulation is indeed slower than the hard disk one. That said
> while cache=writeback makes a difference for the versatile platform, it
> doesn't really change anything for the vexpress platform. Therefore
> forcing the users to add this option doesn't seems to be a good idea.

Maybe the default has changed. Certainly it used to be the case that
sd card emulation was incredibly slow without some kind of caching
option, because it writes 512 bytes at a time, synchronously, and
the SD card interface has no way for the guest to say 'write; write;
write; ok now make sure that's all committed'.

-- PMM
Aurelien Jarno - March 17, 2013, 10:17 a.m.
On Sun, Mar 17, 2013 at 12:23:31AM +0000, Peter Maydell wrote:
> On 17 March 2013 00:04, Aurelien Jarno <aurelien@aurel32.net> wrote:
> > On Fri, Mar 15, 2013 at 03:45:11PM +0000, Peter Maydell wrote:
> >> On 15 March 2013 15:42, Aurelien Jarno <aurelien@aurel32.net> wrote:
> >> > On Fri, Mar 15, 2013 at 03:35:48PM +0000, Peter Maydell wrote:
> >> >> I'm not convinced this is a good thing -- I think you should have
> >> >> to know that you're attaching an SD card and not a hard disk,
> >> >> because the performance is much worse. In particular if you
> >> >> don't specify 'cache=writeback' your performance will be
> >> >> dreadful, so you need to do something different from hard
> >> >> disks anyhow.
> >>
> >> > Being a good thing or not, the current code is wrong: the default
> >> > interface type is set to SCSI (I guess it has been copied from
> >> > versatilepb.c), while the vexpress machine has no SCSI
> >> > interface.
> >>
> >> I agree we shouldn't be claiming to have a scsi interface, yes.
> >>
> >
> > Does it means you are going to accept the patch?
> 
> No, I meant I'd accept a patch which stops us reporting that
> we have a SCSI interface when we don't.

That's what the patch does, by correctly saying it's an SD interface and
not a SCSI one.

> > In anycase let me give you some more arguments in favor of it. Even if
> > you believe that users should always provide a cache= argument, I don't
> > think it should be done by setting a wrong default interfaces. Users are
> > likely to simply google for a command line and paste it without
> > understanding the consequences of cache=writeback. The way to go there
> > is to make the writeback argument mandatory for some machines if you
> > really believe it's need by all users.
> 
> writeback shouldn't be mandatory randomly for some machines and
> interfaces and not others.

I don't get your point there. You don't want to make it mandatory at the
QEMU level, but you want users to understand they have to specify it for
some machines, by making if= mandatory randomly for some machines and
not others?

> > That said I don't share this opinion. I have made some tests comparing
> > a versatile and a vexpress machine, running Debian Wheezy, armel for the
> > first one and armhf for the second one. This has been done on a Core i5
> > 2500 machine with a ST2000DM001 hard drive. Here are the results:
> >
> >                           | boot | install build-dep | build lm-sensors |
> >   ------------------------+------+-------------------+------------------+
> >   versatile               | 1:09 |             2:27  |             4:09 |
> >   versatile cache=wb      | 1:08 |             2:25  |             3:44 |
> >   vexpress                | 1:11 |             3:07  |             3:49 |
> >   vexpress cache=wb       | 1:07 |             3:07  |             3:47 |
> >
> >   Note: the install build-dep time doesn't include the download time.
> >
> > So even if the two systems are not directly comparable, it shows that
> > the SD card emulation is indeed slower than the hard disk one. That said
> > while cache=writeback makes a difference for the versatile platform, it
> > doesn't really change anything for the vexpress platform. Therefore
> > forcing the users to add this option doesn't seems to be a good idea.
> 
> Maybe the default has changed. Certainly it used to be the case that
> sd card emulation was incredibly slow without some kind of caching
> option, because it writes 512 bytes at a time, synchronously, and
> the SD card interface has no way for the guest to say 'write; write;
> write; ok now make sure that's all committed'.
> 

I don't know what has changed, but with the current code the argument
saying that the vexpress machine without cache=writeback has dreadful
performance is wrong.
Peter Maydell - March 17, 2013, 10:56 a.m.
On 17 March 2013 10:17, Aurelien Jarno <aurelien@aurel32.net> wrote:
> On Sun, Mar 17, 2013 at 12:23:31AM +0000, Peter Maydell wrote:
>> On 17 March 2013 00:04, Aurelien Jarno <aurelien@aurel32.net> wrote:
>> > On Fri, Mar 15, 2013 at 03:45:11PM +0000, Peter Maydell wrote:
>> >> I agree we shouldn't be claiming to have a scsi interface, yes.
>> >>
>> >
>> > Does it means you are going to accept the patch?
>>
>> No, I meant I'd accept a patch which stops us reporting that
>> we have a SCSI interface when we don't.
>
> That's what the patch does, by correctly saying it's an SD interface and
> not a SCSI one.

The patch does two things:
 * stops claiming a default SCSI interface [obviously right]
 * starts claiming a default SD interface [what we're arguing about]

>> > In anycase let me give you some more arguments in favor of it. Even if
>> > you believe that users should always provide a cache= argument, I don't
>> > think it should be done by setting a wrong default interfaces. Users are
>> > likely to simply google for a command line and paste it without
>> > understanding the consequences of cache=writeback. The way to go there
>> > is to make the writeback argument mandatory for some machines if you
>> > really believe it's need by all users.
>>
>> writeback shouldn't be mandatory randomly for some machines and
>> interfaces and not others.
>
> I don't get your point there. You don't want to make it mandatory at the
> QEMU level, but you want users to understand they have to specify it for
> some machines, by making if= mandatory randomly for some machines and
> not others?

My point is that I don't think there's a good solution to "modelled SD
cards aren't a good substitute for modelled hard disks".

That said, I want to postpone the rest of this conversation until I've
had a chance to look into what has changed regarding performance of
SD with the default cache settings.

-- PMM
Paolo Bonzini - March 17, 2013, 6:28 p.m.
Il 15/03/2013 16:35, Peter Maydell ha scritto:
> On 5 March 2013 00:44, Aurelien Jarno <aurelien@aurel32.net> wrote:
>> On Tue, Mar 05, 2013 at 08:22:57AM +0800, Peter Maydell wrote:
>>> What effect does this actually have on the user experience?
>>
>> The effect is that the user don't has to specify the interface type.
>> Basically:
>>
>>   -drive file=/path/to/file,if=sd
>> can be replaced by
>>   -drive file=/path/to/file
>>
>> It means the user doesn't have to know the details of the machine to
>> know how to attach a disk. Note that the user here can also be a script,
>> which then becomes a bit simpler.
> 
> I'm not convinced this is a good thing -- I think you should have
> to know that you're attaching an SD card and not a hard disk,
> because the performance is much worse. In particular if you
> don't specify 'cache=writeback' your performance will be
> dreadful, so you need to do something different from hard
> disks anyhow.

cache=writeback has been the default for a few releases.

Paolo
Paolo Bonzini - March 17, 2013, 6:51 p.m.
Il 17/03/2013 01:04, Aurelien Jarno ha scritto:
>                           | boot | install build-dep | build lm-sensors |
>   ------------------------+------+-------------------+------------------+
>   versatile               | 1:09 |             2:27  |             4:09 |
>   versatile cache=wb      | 1:08 |             2:25  |             3:44 |

Strange, cache=wb should be the default.

The real problem with SD is that it doesn't have a flush command, hence
it cannot be made safe against power losses.  But the solution is to add
support for virtio-mmio in those boards.

Paolo

>   vexpress                | 1:11 |             3:07  |             3:49 |
>   vexpress cache=wb       | 1:07 |             3:07  |             3:47 |
> 
>   Note: the install build-dep time doesn't include the download time.
> 
> So even if the two systems are not directly comparable, it shows that
> the SD card emulation is indeed slower than the hard disk one. That said
> while cache=writeback makes a difference for the versatile platform, it
> doesn't really change anything for the vexpress platform. Therefore
> forcing the users to add this option doesn't seems to be a good idea.
Peter Maydell - March 17, 2013, 6:54 p.m.
On 17 March 2013 18:51, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 17/03/2013 01:04, Aurelien Jarno ha scritto:
>>                           | boot | install build-dep | build lm-sensors |
>>   ------------------------+------+-------------------+------------------+
>>   versatile               | 1:09 |             2:27  |             4:09 |
>>   versatile cache=wb      | 1:08 |             2:25  |             3:44 |
>
> Strange, cache=wb should be the default.
>
> The real problem with SD is that it doesn't have a flush command, hence
> it cannot be made safe against power losses.

So, two things here:
(a) the way to make it safe against power loss is that when the
guest writes a block of data it has to really hit the emulated
disk, because this is how the hardware works
(b) I thought this was the reason cache=wb wasn't the default (ie
that we weren't defaulting to 'may lose data on powerloss'). At the
time I last looked into command line options for these boards I'm
pretty sure it wasn't the default, because the performance improvement
from turning on caching was huge.

-- PMM
Aurelien Jarno - March 17, 2013, 7:20 p.m.
On Sun, Mar 17, 2013 at 07:51:00PM +0100, Paolo Bonzini wrote:
> Il 17/03/2013 01:04, Aurelien Jarno ha scritto:
> >                           | boot | install build-dep | build lm-sensors |
> >   ------------------------+------+-------------------+------------------+
> >   versatile               | 1:09 |             2:27  |             4:09 |
> >   versatile cache=wb      | 1:08 |             2:25  |             3:44 |
> 
> Strange, cache=wb should be the default.

I agree it's strange, maybe there were other effects, but I am sure when
I did the tests cache=wb the build time was clearly shorter.

> The real problem with SD is that it doesn't have a flush command, hence
> it cannot be made safe against power losses.  But the solution is to add
> support for virtio-mmio in those boards.
> 
> Paolo
> 
> >   vexpress                | 1:11 |             3:07  |             3:49 |
> >   vexpress cache=wb       | 1:07 |             3:07  |             3:47 |
> > 

Here the results are more consistent with the default being cache=wb.

I'll try to do the same tests on another machine to see if the results
are still the same.
Aurelien Jarno - March 17, 2013, 7:22 p.m.
On Sun, Mar 17, 2013 at 06:54:47PM +0000, Peter Maydell wrote:
> On 17 March 2013 18:51, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > Il 17/03/2013 01:04, Aurelien Jarno ha scritto:
> >>                           | boot | install build-dep | build lm-sensors |
> >>   ------------------------+------+-------------------+------------------+
> >>   versatile               | 1:09 |             2:27  |             4:09 |
> >>   versatile cache=wb      | 1:08 |             2:25  |             3:44 |
> >
> > Strange, cache=wb should be the default.
> >
> > The real problem with SD is that it doesn't have a flush command, hence
> > it cannot be made safe against power losses.
> 
> So, two things here:
> (a) the way to make it safe against power loss is that when the
> guest writes a block of data it has to really hit the emulated
> disk, because this is how the hardware works
> (b) I thought this was the reason cache=wb wasn't the default (ie
> that we weren't defaulting to 'may lose data on powerloss'). At the
> time I last looked into command line options for these boards I'm
> pretty sure it wasn't the default, because the performance improvement
> from turning on caching was huge.
> 

For the record, this has been changed in this commit:

commit 1f212b9d3edd8679bafd3bcf0301795206438724
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Thu Aug 9 16:07:21 2012 +0200

    blockdev: flip default cache mode from writethrough to writeback
    
    Now all major device models (IDE, SCSI, virtio) can choose between
    writethrough and writeback at run-time, and virtio will even revert
    to writethrough if the guest is not capable of sending flushes.  So
    we can change the default to writeback at last.
    
    Tested, for lack of a better idea, with a breakpoint on bdrv_open
    and all cache choices one by one.
    
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Paolo Bonzini - March 18, 2013, 8:31 a.m.
Il 17/03/2013 19:54, Peter Maydell ha scritto:
> On 17 March 2013 18:51, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> Il 17/03/2013 01:04, Aurelien Jarno ha scritto:
>>>                           | boot | install build-dep | build lm-sensors |
>>>   ------------------------+------+-------------------+------------------+
>>>   versatile               | 1:09 |             2:27  |             4:09 |
>>>   versatile cache=wb      | 1:08 |             2:25  |             3:44 |
>>
>> Strange, cache=wb should be the default.
>>
>> The real problem with SD is that it doesn't have a flush command, hence
>> it cannot be made safe against power losses.
> 
> So, two things here:
> (a) the way to make it safe against power loss is that when the
> guest writes a block of data it has to really hit the emulated
> disk, because this is how the hardware works
> (b) I thought this was the reason cache=wb wasn't the default (ie
> that we weren't defaulting to 'may lose data on powerloss').

See the commit message that Aurelien posted.  The combination of
"virtio-blk will auto-toggle to writethrough on very old kernels",
"guests can toggle it for all of IDE/SCSI/virtio", "memory cards are
anyway unusable with writethrough" finally made the balance tilt in
favor of cache=wb.

Paolo

Patch

diff --git a/hw/vexpress.c b/hw/vexpress.c
index 741b044..969aae6 100644
--- a/hw/vexpress.c
+++ b/hw/vexpress.c
@@ -477,7 +477,7 @@  static QEMUMachine vexpress_a9_machine = {
     .name = "vexpress-a9",
     .desc = "ARM Versatile Express for Cortex-A9",
     .init = vexpress_a9_init,
-    .block_default_type = IF_SCSI,
+    .block_default_type = IF_SD,
     .max_cpus = 4,
     DEFAULT_MACHINE_OPTIONS,
 };
@@ -486,7 +486,7 @@  static QEMUMachine vexpress_a15_machine = {
     .name = "vexpress-a15",
     .desc = "ARM Versatile Express for Cortex-A15",
     .init = vexpress_a15_init,
-    .block_default_type = IF_SCSI,
+    .block_default_type = IF_SD,
     .max_cpus = 4,
     DEFAULT_MACHINE_OPTIONS,
 };