qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: getting the console output for s390 cdrom-test?


From: Cornelia Huck
Subject: Re: getting the console output for s390 cdrom-test?
Date: Tue, 9 Feb 2021 18:24:00 +0100

On Tue, 9 Feb 2021 17:17:19 +0000
Peter Maydell <peter.maydell@linaro.org> wrote:

> On Tue, 9 Feb 2021 at 17:10, Cornelia Huck <cohuck@redhat.com> wrote:
> >
> > On Tue, 9 Feb 2021 14:58:53 +0000
> > Peter Maydell <peter.maydell@linaro.org> wrote:  
> > > This change significantly reduces the frequency with which I see
> > > the hang; but it doesn't get rid of it altogether. Also I couldn't
> > > really figure out from the virtio spec exactly where barriers
> > > were required: I think I would need to read the whole thing in
> > > more detail rather than trying to fish out the information by
> > > just reading small pieces of it.  
> >
> > The Linux virtio-ccw code uses 'weak barriers', i.e. the heavy bcr15
> > should not be needed. We might well miss other (lightweight) barriers
> > in other parts of the code part, though.  
> 
> Is that the version the Linux kernel has as
>   /* Fast-BCR without checkpoint synchronization */
>   #define __ASM_BARRIER "bcr 14,0\n"
> 
> ?

No, just a simple memory barrier in most places (bcr15 and bcr14 do
serialization).

> 
> > > But some of the ordering of
> > > operations the spec describes doesn't match how the s390-ccw
> > > BIOS code is doing it at all (eg the spec says that when feeding
> > > a batch of descriptors to the device the driver isn't supposed to
> > > update the flags on the first descriptor until it's finished
> > > writing all of the descriptors, but the code doesn't seem to
> > > try to do that). So I think the code could use an overhaul from
> > > somebody with a better understanding of virtio than me...  
> >
> > Yeah, the bios virtio code could probably use some love.
> >
> > I'm wondering how much memory ordering on the host platform influences
> > things. I doubt many people try to run an s390x guest on an aarch64
> > host...  
> 
> Yes, you won't see this bug unless you're running QEMU on a
> host that's pretty enthusiastic about reordering memory
> transactions (and you'd never have seen it at all back when
> we ran the iothread actions synchronously with the emulated
> CPU, which we probably did back in 2013 when the s390-ccw
> virtio code was written...) I haven't tested other aarch64
> hosts but I would be unsurprised to find that whether you
> could repro it and how frequently depended on the particular
> h/w implementation.

I guess that hardly any s390x guests run on hw that's not either s390x
or x86...




reply via email to

[Prev in Thread] Current Thread [Next in Thread]