[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 08/13] vt82c686: Move creation of ISA devices to the ISA b
From: |
Philippe Mathieu-Daudé |
Subject: |
Re: [PATCH v2 08/13] vt82c686: Move creation of ISA devices to the ISA bridge |
Date: |
Mon, 25 Jan 2021 18:57:10 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 |
On 1/11/21 11:28 AM, BALATON Zoltan wrote:
> On Mon, 11 Jan 2021, Jiaxun Yang wrote:
>> On Mon, Jan 11, 2021, at 3:25 AM, BALATON Zoltan wrote:
>>> On Sun, 10 Jan 2021, Philippe Mathieu-Daudé wrote:
>>>> +PCI experts
>>>>
>>>> On 1/10/21 1:43 AM, BALATON Zoltan wrote:
>>>>> On Sun, 10 Jan 2021, Philippe Mathieu-Daudé wrote:
>>
>> [...]
>>
>>>> I'm not a PCI expert but my understanding is PCI device functions are
>>>> restricted to the PCI bus address space. The host bridge may map this
>>>> space within the host.
>>>>
>>>> QEMU might be using get_system_memory() because for some host bridge
>>>> the mapping is not implemented so it was easier this way?
>>>
>>> Maybe, also one less indirection which if not really needed is a good
>>> thing for performance so unless it's found to be needed to use another
>>> address space here I'm happy with this as it matches what other similar
>>> devices do and it seems to work. Maybe a separate address space is only
>>> really needed if we have an iommu?
>>
>> Hi Zoltan,
>>
>> It is possible for bonito to remap PCI address space so maybe it's
>> essential for bonito.
>
> I'm still not sure it's needed or how that would work. Maybe while it's
> possible to remap these, all guests just map these one-to-one (otherwise
> they may need to do some address translation which is much better
> avoided) so in practice we don't need to emulate this. If we use a
> different memory region maybe we also need some additional iommu code
> somewhere to connect the two but I'm not sure, I haven't tried since
> most other isa bridges do the same way using system_memory and this
> seems to work. I'm also a bit concerned about additional overhead which
> we could avoid if possible. Just to model something that's not really
> used I don't think it's worth the additional complexity and possible
> performance loss unless it's found to be needed to get some guests work.
Fine.
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
- Re: [PATCH v2 05/13] vt82c686: Set user_creatable=false for VT82C686B_PM, (continued)
- [PATCH v2 13/13] vt82c686: Add emulation of VT8231 south bridge, BALATON Zoltan, 2021/01/09
- [PATCH v2 08/13] vt82c686: Move creation of ISA devices to the ISA bridge, BALATON Zoltan, 2021/01/09
- Re: [PATCH v2 08/13] vt82c686: Move creation of ISA devices to the ISA bridge, Philippe Mathieu-Daudé, 2021/01/09
- Re: [PATCH v2 08/13] vt82c686: Move creation of ISA devices to the ISA bridge, BALATON Zoltan, 2021/01/09
- Re: [PATCH v2 08/13] vt82c686: Move creation of ISA devices to the ISA bridge, Philippe Mathieu-Daudé, 2021/01/10
- Re: [PATCH v2 08/13] vt82c686: Move creation of ISA devices to the ISA bridge, BALATON Zoltan, 2021/01/10
- Re: [PATCH v2 08/13] vt82c686: Move creation of ISA devices to the ISA bridge, Jiaxun Yang, 2021/01/10
- Re: [PATCH v2 08/13] vt82c686: Move creation of ISA devices to the ISA bridge, BALATON Zoltan, 2021/01/11
- Re: [PATCH v2 08/13] vt82c686: Move creation of ISA devices to the ISA bridge,
Philippe Mathieu-Daudé <=
[PATCH v2 06/13] vt82c686: Make vt82c686b-pm an abstract base class and add vt8231-pm based on it, BALATON Zoltan, 2021/01/09
[PATCH v2 10/13] vt82c686: Implement control of serial port io ranges via config regs, BALATON Zoltan, 2021/01/09
[PATCH v2 09/13] vt82c686: Fix superio_cfg_{read,write}() functions, BALATON Zoltan, 2021/01/09
[PATCH v2 11/13] vt82c686: QOM-ify superio related functionality, BALATON Zoltan, 2021/01/09