All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cao jin <caoj.fnst@cn.fujitsu.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH RFC] vfio-pci: put device in INTx disable state in pre_reset
Date: Wed, 12 Oct 2016 12:02:39 +0800	[thread overview]
Message-ID: <57FDB5DF.2030809@cn.fujitsu.com> (raw)
In-Reply-To: <20161011202549.0af84928@t450s.home>



On 10/12/2016 10:25 AM, Alex Williamson wrote:
> On Mon, 10 Oct 2016 17:12:43 +0800
> Cao jin <caoj.fnst@cn.fujitsu.com> wrote:
>
>> Current code cleared the PCI_COMMAND_INTX_DISABLE, which indicates
>> device/function could asserts its INTx# signal.
>>
>> PCI local spec says:
>> A value of 0 enables the assertion of its INTx# signal.
>> A value of 1 disables the assertion of its INTx# signal.
>
> The PCI spec also says that this bit's state is zero after reset and
> we're about to perform a reset, so we expect it to be zero after
> reset.  I believe this is the reason a set it this way.  If we want to
> set it, we should OR it in, not AND it.  Are you actually seeing any
> issues with the current behavior or was this a code inspection
> discovery?  Thanks,
>
> Alex
>

Just code inspection discovery. I understand that the bit is 0 after 
reset. In pre reset, from what I understand, we disabled interrupts 
first, so I *guess*this bit maybe should indicate the current 
state(device can't assert to trigger INTx).

If this bit is set to 1 in pre-reset, then cleared to 0 in post-reset, 
it will be more logical to me. But just clear it to 0 in pre-set seems 
not quite wrong, because we eventually want it to be 0.

And yes, I made a mistake, we should OR it if want to set it.
-- 
Yours Sincerely,

Cao jin
>
>> Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com>
>> ---
>> I guess it is a mistake, clearing the bit to enable INTx violate
>> the intention of vfio_disable_interrupts above.
>>
>>   hw/vfio/pci.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
>> index a5a620a..cce3024 100644
>> --- a/hw/vfio/pci.c
>> +++ b/hw/vfio/pci.c
>> @@ -1898,8 +1898,8 @@ static void vfio_pci_pre_reset(VFIOPCIDevice *vdev)
>>        * Also put INTx Disable in known state.
>>        */
>>       cmd = vfio_pci_read_config(pdev, PCI_COMMAND, 2);
>> -    cmd &= ~(PCI_COMMAND_IO | PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER |
>> -             PCI_COMMAND_INTX_DISABLE);
>> +    cmd &= ~(PCI_COMMAND_IO | PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER) |
>> +             PCI_COMMAND_INTX_DISABLE;
>>       vfio_pci_write_config(pdev, PCI_COMMAND, cmd, 2);
>>   }
>>
>
>
>
>

      reply	other threads:[~2016-10-12  4:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-10  9:12 [Qemu-devel] [PATCH RFC] vfio-pci: put device in INTx disable state in pre_reset Cao jin
2016-10-12  2:25 ` Alex Williamson
2016-10-12  4:02   ` Cao jin [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=57FDB5DF.2030809@cn.fujitsu.com \
    --to=caoj.fnst@cn.fujitsu.com \
    --cc=alex.williamson@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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.