[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v4] Add optionrom compatible with fw_cfg DMA ver
From: |
Laszlo Ersek |
Subject: |
Re: [Qemu-devel] [PATCH v4] Add optionrom compatible with fw_cfg DMA version |
Date: |
Wed, 3 Feb 2016 12:48:59 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 |
On 02/03/16 09:44, Gerd Hoffmann wrote:
> Hi,
>
>> I think the "dma_enabled" property is not exposed to the user.
>
> It is: "-global fw_cfg.dma_enabled=off" works (as in: doesn't throw an
> error). Has no effect through as it gets overridden later on.
>
>> The default value of "dma_enabled" in both fw_cfg_io_properties and
>> fw_cfg_mem_properties is irrelevant; the actual property value is always
>> overwritten in fw_cfg_init_io_dma() and fw_cfg_init_mem_wide(), which
>> all of the init paths go through.
>
> And IMHO we should not do that, so setting the property actually has an
> effect.
Fair point.
>> I agree that DMA capability should be filtered with machine type.
>> However, that distinction should not be made using the current
>> "dma_enabled" properties (i.e., of "fw_cfg_io_properties" and
>> "fw_cfg_mem_properties". Instead, it should be made in the
>> board-specific callers of fw_cfg_init_(io_dma|mem_wide).
>
> Why?
That's how "has_reserved_memory" works as well, for example.
But, if the property is made work, I guess PC_COMPAT_2_4 can be used
too. (Or should it be HW_COMPAT_2_4?)
Is that your point?
Thanks
Laszlo
Re: [Qemu-devel] [PATCH v4] Add optionrom compatible with fw_cfg DMA version, Marc MarĂ, 2016/02/02