All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@web.de>
To: Peter Xu <peterx@redhat.com>, David Kiarie <davidkiarie4@gmail.com>
Cc: Valentine Sinitsyn <valentine.sinitsyn@gmail.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Marcel Apfelbaum <marcel@redhat.com>
Subject: Re: [Qemu-devel] [V11 2/4] hw/i386: ACPI IVRS table
Date: Sat, 18 Jun 2016 14:34:26 +0200	[thread overview]
Message-ID: <57653FD2.4040303@web.de> (raw)
In-Reply-To: <20160618123244.GL27635@pxdev.xzpeter.org>

[-- Attachment #1: Type: text/plain, Size: 5326 bytes --]

On 2016-06-18 14:32, Peter Xu wrote:
> On Sat, Jun 18, 2016 at 11:18:29AM +0300, David Kiarie wrote:
>> On Tue, May 24, 2016 at 10:06 AM, Valentine Sinitsyn
>> <valentine.sinitsyn@gmail.com> wrote:
>>> Hi all,
>>>
>>>
>>> On 24.05.2016 11:54, Peter Xu wrote:
>>>>
>>>> On Sun, May 22, 2016 at 01:21:52PM +0300, David Kiarie wrote:
>>>> [...]
>>>>>
>>>>> +static void
>>>>> +build_amd_iommu(GArray *table_data, GArray *linker)
>>>>> +{
>>>>> +    int iommu_start = table_data->len;
>>>>> +    bool iommu_ambig;
>>>>> +
>>>>> +    /* IVRS definition  - table header has an extra 2-byte field */
>>>>> +    acpi_data_push(table_data, (sizeof(AcpiTableHeader)));
>>>>> +    /* common virtualization information */
>>>>> +    build_append_int_noprefix(table_data, AMD_IOMMU_HOST_ADDRESS_WIDTH
>>>>> << 8, 4);
>>>>> +    /* reserved */
>>>>> +    build_append_int_noprefix(table_data, 0, 8);
>>>>> +
>>>>> +    AMDVIState *s = (AMDVIState *)object_resolve_path_type("",
>>>>> +                        TYPE_AMD_IOMMU_DEVICE, &iommu_ambig);
>>>>> +
>>>>> +    /* IVDB definition - type 10h */
>>>>> +    if (!iommu_ambig) {
>>>>> +        /* IVHD definition - type 10h */
>>>>> +        build_append_int_noprefix(table_data, 0x10, 1);
>>>>> +        /* virtualization flags */
>>>>> +        build_append_int_noprefix(table_data, (IVHD_HT_TUNEN |
>>>>> +                     IVHD_PPRSUP | IVHD_IOTLBSUP | IVHD_PREFSUP), 1);
>>>>> +        /* ivhd length */
>>>>> +        build_append_int_noprefix(table_data, 0x20, 2);
>>>>> +        /* iommu device id */
>>>>> +        build_append_int_noprefix(table_data, PCI_DEVICE_ID_RD890_IOMMU,
>>>>> 2);
>>>>> +        /* offset of capability registers */
>>>>> +        build_append_int_noprefix(table_data, s->capab_offset, 2);
>>>>> +        /* mmio base register */
>>>>> +        build_append_int_noprefix(table_data, s->mmio.addr, 8);
>>>>> +        /* pci segment */
>>>>> +        build_append_int_noprefix(table_data, 0, 2);
>>>>> +        /* interrupt numbers */
>>>>> +        build_append_int_noprefix(table_data, 0, 2);
>>>>> +        /* feature reporting */
>>>>> +        build_append_int_noprefix(table_data, (IVHD_EFR_GTSUP |
>>>>> +                    IVHD_EFR_HATS | IVHD_EFR_GATS), 4);
>>>>> +        /* Add device flags here
>>>>> +         *   These are 4-byte device entries currently reporting the
>>>>> range of
>>>>> +         *   devices 00h - ffffh; all devices
>>>>> +         *   Device setting affecting all devices should be made here
>>>>> +         *
>>>>> +         *   Refer to
>>>>> +         *
>>>>> (http://developer.amd.com/wordpress/media/2012/10/488821.pdf)
>>>>> +         *   Table 95
>>>>
>>>>
>>>> I failed to find Table 95 in the document. Is that typo?
>>>
>>> I guess it should be "Table 75". David, am I right?
>>> On a side note, 2.0 specification you mention is rather outdated.
>>> Please consider referencing something newer, like 2.6.
>>>
>>>
>>>>
>>>> [...]
>>>>
>>>>>   static
>>>>>   void acpi_build(AcpiBuildTables *tables, MachineState *machine)
>>>>>   {
>>>>> @@ -2657,6 +2721,7 @@ void acpi_build(AcpiBuildTables *tables,
>>>>> MachineState *machine)
>>>>>       AcpiMcfgInfo mcfg;
>>>>>       PcPciInfo pci;
>>>>>       uint8_t *u;
>>>>> +    IommuType IOMMUType = has_iommu();
>>>>>       size_t aml_len = 0;
>>>>>       GArray *tables_blob = tables->table_data;
>>>>>       AcpiSlicOem slic_oem = { .id = NULL, .table_id = NULL };
>>>>> @@ -2722,7 +2787,13 @@ void acpi_build(AcpiBuildTables *tables,
>>>>> MachineState *machine)
>>>>>           acpi_add_table(table_offsets, tables_blob);
>>>>>           build_mcfg_q35(tables_blob, tables->linker, &mcfg);
>>>>>       }
>>>>> -    if (acpi_has_iommu()) {
>>>>> +
>>>>> +    if (IOMMUType == TYPE_AMD) {
>>>>> +        acpi_add_table(table_offsets, tables_blob);
>>>>> +        build_amd_iommu(tables_blob, tables->linker);
>>>>> +    }
>>>>> +
>>>>> +    if (IOMMUType == TYPE_INTEL) {
>>>>>           acpi_add_table(table_offsets, tables_blob);
>>>>>           build_dmar_q35(tables_blob, tables->linker);
>>>>>       }
>>>>
>>>>
>>>> Nit: I'd prefer:
>>>>
>>>>      if (type == Intel) {
>>>>      ...
>>>>      } else if (type == AMD) {
>>>>      ...
>>>>      }
>>>>
>>
>> I missed this is the last version of the patch I should fix it in next version.
>>
>> On taking a closer look at this there might be larger problem where
>> with the advent of -device <iommu-type> users can possibly emulate two
>> IOMMUs at the same time ? A proposed solution was to have
>> pci_setup_iommu check that DMA hook as not been setup yet and fail if
>> yes. I should send a fix for that too.
> 
> Currently we should only support single vIOMMU.  If you are going to
> rebase to x86-iommu codes, there is a patch that includes the check:
> 
>   "[PATCH v9 02/25] x86-iommu: provide x86_iommu_get_default"
> 
> by:
> 
>   assert(x86_iommu_default == NULL);
> 
> Maybe we should print something more readable, like "multiple vIOMMUs
> are not supported yet", rather than an assertion fail.

You need proper error handling and a readable error message because
nothing else will stop the user from doing -device intel-iommu -device
amd-iommu.

Jan



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  reply	other threads:[~2016-06-18 12:34 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-22 10:21 [Qemu-devel] [V11 0/4] AMD IOMMU David Kiarie
2016-05-22 10:21 ` [Qemu-devel] [V11 1/4] hw/i386: Introduce " David Kiarie
2016-05-22 17:47   ` Jan Kiszka
2016-05-22 18:12   ` Jan Kiszka
2016-05-22 18:17     ` Jan Kiszka
2016-05-22 18:48   ` Alex Bennée
2016-05-24 12:35   ` Peter Xu
2016-05-24 13:11     ` David Kiarie
2016-06-07 20:36   ` Alex Williamson
2016-06-08  5:18     ` Jan Kiszka
2016-05-22 10:21 ` [Qemu-devel] [V11 2/4] hw/i386: ACPI IVRS table David Kiarie
2016-05-24  6:54   ` Peter Xu
2016-05-24  7:06     ` Valentine Sinitsyn
2016-06-18  8:18       ` David Kiarie
2016-06-18 12:32         ` Peter Xu
2016-06-18 12:34           ` Jan Kiszka [this message]
2016-06-20  3:36             ` Peter Xu
2016-05-22 10:21 ` [Qemu-devel] [V11 3/4] hw/core: provision for overriding emulated IOMMU David Kiarie
2016-05-24  6:51   ` Peter Xu
2016-05-24 11:49   ` Michael S. Tsirkin
2016-05-24 13:01     ` Jan Kiszka
2016-05-24 14:23       ` Marcel Apfelbaum
2016-05-22 10:21 ` [Qemu-devel] [V11 4/4] hw/pci-host: Emulate AMD IOMMU David Kiarie

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=57653FD2.4040303@web.de \
    --to=jan.kiszka@web.de \
    --cc=davidkiarie4@gmail.com \
    --cc=marcel@redhat.com \
    --cc=mst@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=valentine.sinitsyn@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.