From: John Snow <jsnow@redhat.com>
To: Thomas Huth <thuth@redhat.com>,
Alexey Kardashevskiy <aik@ozlabs.ru>,
qemu-devel@nongnu.org
Cc: "Hervé Poussineau" <hpoussin@reactos.org>,
"Markus Armbruster" <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH qemu] fdc: Exit if ISA controller does not support DMA
Date: Thu, 15 Mar 2018 17:08:48 -0400 [thread overview]
Message-ID: <429ca11e-b521-57cc-c35b-2fb61024867d@redhat.com> (raw)
In-Reply-To: <5ed185e2-c53a-0f82-a5f9-08e4918ad1b0@redhat.com>
On 03/05/2018 05:15 AM, Thomas Huth wrote:
> On 08.12.2017 22:29, John Snow wrote:
>>
>> On 11/21/2017 09:48 PM, Alexey Kardashevskiy wrote:
>>> On 07/11/17 11:58, John Snow wrote:
>>>>
>>>>
>>>> On 10/26/2017 02:46 AM, Alexey Kardashevskiy wrote:
>>>>> A "powernv" machine type defines an ISA bus but it does not add any DMA
>>>>> controller to it so it is possible to hit assert(fdctrl->dma) by
>>>>> adding "-machine powernv -device isa-fdc".
>>>>>
>>>>> This replaces assert() with an error message.
>>>>>
>>>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>>>> ---
> [...]
>>>>> diff --git a/hw/block/fdc.c b/hw/block/fdc.c
>>>>> index 67f78ac702..ed8b367572 100644
>>>>> --- a/hw/block/fdc.c
>>>>> +++ b/hw/block/fdc.c
>>>>> @@ -2700,7 +2700,10 @@ static void isabus_fdc_realize(DeviceState *dev, Error **errp)
>>>>> fdctrl->dma_chann = isa->dma;
>>>>> if (fdctrl->dma_chann != -1) {
>>>>> fdctrl->dma = isa_get_dma(isa_bus_from_device(isadev), isa->dma);
>>>>> - assert(fdctrl->dma);
>>>>> + if (!fdctrl->dma) {
>>>>> + error_setg(errp, "ISA controller does not support DMA, exiting");
>>>>> + return;
>>>>> + }
>>>>> }
>>>>>
>>>>> qdev_set_legacy_instance_id(dev, isa->iobase, 2);
>>>>>
>>>>
>>>> I've been MIA for a little while, so I'm out of the loop -- but I am not
>>>> sure this is entirely the right way to fix this problem. I think it is
>>>> more the case that certain boards should not be able to ask for certain
>>>> types of devices, and we should prohibit e.g. powernv from being able to
>>>> ask for an ISA floppy disk controller.
>>>>
>>>> (It doesn't seem to have an ISA DMA controller by default, but I have no
>>>> idea if that means it can't EVER have one...)
>>>>
>>>> Papering over this by making it a soft error when we fail to execute
>>>> isa_get_dma and then assuming in retrospect it's because the machine
>>>> type we're on cannot have an ISA DMA controller seems a little
>>>> wrong-headed. It also leaves side-effects from isa_register_portio_list
>>>> and isa_init_irq, so we can't just bail here -- it's only marginally
>>>> better than the assert() it's doing.
>>>>
>>>> That said, I am not really sure what the right thing to do is ... I
>>>> suspect the "right thing" is to express the dependency that isa-fdc
>>>> requires an ISA DMA controller -- and maybe that check happens here when
>>>> isa_get_dma fails and we have to unwind the realize function, but we
>>>> need to do it gracefully.
>>>>
>>>> Give me a day to think about it, but I do want to make sure this is in
>>>> the next release.
>>>
>>> The day has passed, any news? :)
>>
>> *cough* It turns out that understanding the intricacies of FDC and ISA
>> is nobody's favorite thing to do.
>>
>> OK, so ehabkost pointed me to this:
>>
>> https://www.mail-archive.com/qemu-devel@nongnu.org/msg496460.html
>>
>> Where we declare that DMA devices generally can't be created by the user
>> for the inverse of the reason we're seeing here: these devices need to
>> be created precisely once: not zero times, not twice, exactly once.
>>
>> So we made the ISA DMA devices themselves not user-creatable, so you are
>> indeed correct here that the absence of fdctrl->dma does more or less
>> mean that the current configuration "doesn't support DMA." ... but maybe
>> this won't always be true, and maybe some devices (TYPE_I82374?) are
>> user creatable, so let's make a "softer" error message:
>>
>> "No ISA DMA device present, can't create ISA FDC device."
>>
>> Then, on the other end, we need to unwind realize() gracefully, maybe we
>> can just shuffle up isa_get_dma() earlier so we don't have to unwind
>> anything if it comes back empty.
>>
>> Then I'll take the patch, because fixing this more properly I think will
>> take more time or effort than I have to spend on the FDC device.
>
> The problem still persists ... was there ever a follow-up to this patch
> / discussion?
>
> Thomas
>
No, I'll just stab at it during freeze. I can probably at least have it
fail gracefully, though what the "right" thing to do is still not
particularly clear to me as I don't really understand the platforms that
are failing.
prev parent reply other threads:[~2018-03-15 21:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-26 6:46 [Qemu-devel] [PATCH qemu] fdc: Exit if ISA controller does not support DMA Alexey Kardashevskiy
2017-11-07 0:58 ` John Snow
2017-11-22 2:48 ` Alexey Kardashevskiy
2017-12-08 21:29 ` John Snow
2017-12-13 6:19 ` Hervé Poussineau
2018-03-05 10:29 ` Philippe Mathieu-Daudé
2018-03-05 19:03 ` Philippe Mathieu-Daudé
2018-03-05 10:15 ` Thomas Huth
2018-03-15 21:08 ` John Snow [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=429ca11e-b521-57cc-c35b-2fb61024867d@redhat.com \
--to=jsnow@redhat.com \
--cc=aik@ozlabs.ru \
--cc=armbru@redhat.com \
--cc=hpoussin@reactos.org \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.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;
as well as URLs for NNTP newsgroup(s).