[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled"
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table |
Date: |
Tue, 26 May 2015 17:08:22 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 |
On 26/05/2015 17:00, Alexey Kardashevskiy wrote:
>>>> Why do you need different regions? Why can't you have always the same
>>>> IOMMU regions, and either:
>>>
>>> They may change a size.
>>
>> That's not a problem, there's memory_region_set_size for that.
>
> It was not there when I started doing this DDW :) If so, I can keep the
> existing structure and just set size to zero instead of
> memory_region_del_subregion().
del/add_subregion is okay. It's just init/unparent that is wrong.
> I need windows appear and disappear on a bus dynamically, that's it. The
> actual sPAPRTCETable objects exist always.
Great.
> Aliases will do the job as far as I can tell.
Then you can choose between init_alias/add/del/unparent(alias) and
del/set_size/add which Michael has mentioned. The latter is probably
cleaner and faster.
> sPAPRTCETable stores the actual table and if I want it to migrate, the
> destination QEMU must have the object created-and-vmstate_register'ated.
> But the table (and class) may be absent or present on the source side so
> I need to start the destination with or without -device sPAPRTCETable,
> and if I need to create this object, I need to make it a child of a PHB
> and last time I checked - there is no command line interface for linking
> children.
Yup, understood now.
> But I started thinking that always having 2 sPAPRTCETable objects (some
> may be "disabled") it not better than a single sPAPRTCETable with
> multiple TCE tables...
Whatever works best for you. Either is okay.
Paolo
- Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table, (continued)
- Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table, Alexey Kardashevskiy, 2015/05/26
- Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table, Paolo Bonzini, 2015/05/26
- Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table, Alexey Kardashevskiy, 2015/05/26
- Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table, Paolo Bonzini, 2015/05/26
- Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table, Michael Roth, 2015/05/26
- Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table, Paolo Bonzini, 2015/05/26
- Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table, Alexey Kardashevskiy, 2015/05/26
- Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table, Paolo Bonzini, 2015/05/26
- Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table, Alexey Kardashevskiy, 2015/05/26
- Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table, Alexey Kardashevskiy, 2015/05/26
- Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table,
Paolo Bonzini <=
- Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table, Alexey Kardashevskiy, 2015/05/26
- Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table, Michael Roth, 2015/05/26
- Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table, David Gibson, 2015/05/26