Hi Miroslav

I will try to get you logs. I will rerun the test with the libvirt files I have if need be but if there is a different rpm now available perhaps it would be better if I used that. When you say the previous patches you did may not be necessary do you mean the ones to the file test_pci_passthrough.bash?  I am going to need to reload my xseries system at this point anyhow. Should I re-try the pci PT tests without those patches and only the modified libvirt?

Thanks
Jim

James Czyzak
Linux Security Team
Linux Technology Center
(830) 839-4826
czyzak@us.ibm.com




From:        Miroslav Vadkerti <mvadkert@redhat.com>
To:        James Czyzak/Beaverton/IBM@IBMUS
Cc:        audit-test-developer@lists.sourceforge.net
Date:        01/30/2012 06:00 AM
Subject:        Re: [Audit-test-developer] [PATCH 1/1] kvm-iommu PCI PT rom and        reset files not required





-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Jim,

I cannot reproduce the problem that you have seen with not-existent
rom/reset
files in /sys/bus/pci/devices/$pci_device/. I also found out that this
patch I'm replying
on should not be needed and should not cause the test to fail. Could you
maybe
send me your logs or a patch so the pci pt tests are passing for you? On
my testing
machine with BCM5709 all tests are currently passing with the patched
libvirt 0.9.9.

Thanks and regards,
/M

On 01/13/2012 10:38 PM, Miroslav Vadkerti wrote:
> Good news regarding this issue, looks like there is already a patch
that should
> fix the issue. We are waiting for a scratch package to land in our hands,
> should happen soon.
>
> Anyway the patch I submitted for the PCI PT tests seems to be insufficient
> according to Jim. I will try to retest on our testing machine with bnx2
> and submit a new one soon.
>
> Regards,
> /M
>
> ----- Original Message -----
>> James Czyzak wrote:
>>> Hi Miroslav
>>>
>>> I had to apply the patch by hand because my email system always
>>> screws up
>>> the in-line patches. Not sure why but no matter. The patches got me
>>> further but then I ran into the problem where the hard coded
>>> restorecon
>>> instructions of those files got me. So just for a quick test I
>>> removed
>>> those on my test machine for the reset and rom file since it
>>> doesn't
>>> affect my system. That got me considerable further. The problem now
>>> appears that the attach itself fails and it seems that the system
>>> is
>>> claiming an internal error not wanting to do the bus reset because
>>> the
>>> device I specified (eth1 at 0000:04:00.1) shares the bus with eth0
>>> (at
>>> 0000:04:00.0) which of course is my primary ethernet device which I
>>> am
>>> logged in through .
>>
>> I get the same error if I try to configure the test to use one port
>> of
>> my 4-port NIC.
>>
>> 03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II
>> BCM5709 Gigabit Ethernet
>> (rev 20)
>> 03:00.1 Ethernet controller: Broadcom Corporation NetXtreme II
>> BCM5709 Gigabit Ethernet
>> (rev 20)
>> 04:00.0 Ethernet controller: Broadcom Corporation NetXtreme II
>> BCM5709 Gigabit Ethernet
>> (rev 20)
>> 04:00.1 Ethernet controller: Broadcom Corporation NetXtreme II
>> BCM5709 Gigabit Ethernet
>> (rev 20)
>>
>> I tried using 04.00.0, which is unused on my system, and based on the
>> error messages
>> I assume I'm just out of luck because 04.00.1 exists, even though it
>> is also unused.
>>
>> What's interesting is that I'm able to get the tests to work on a
>> different system
>> using a Qlogic adapter, that looks like this:
>>
>> 07:00.0 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel
>> to PCI Express HBA
>> (rev 02)
>> 07:00.1 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel
>> to PCI Express HBA
>> (rev 02)
>>
>> The tests pass if pci_device="0000:07:00.0". In this case it doesn't
>> seem to have
>> a problem with assigning a PCI device, even though there is another
>> device on the
>> same bus?
>>
>> Maybe the problem is that 04:00.1 isn't really unused?
>>
>> -- ljk
>>
>>> So I guess my question now is should the tests be run
>>> on devices attached to a bus that are not active? I believe I have
>>> additional ethernet devices on this target machine but I don't on
>>> my 2nd
>>> target machine the 3620M3 (However it runs an intel chipset so it
>>> may be
>>> different in operation anyway). Here is the section of messages in
>>> the
>>> run.log from the first test that include the error message. I can
>>> send the
>>> entire run.log if necessary. I guess what I'm curious about now is
>>> whether
>>> not having those 2 files is detrimental to doing this operation?
>>>
>>> Here are the messages surrounding the error that occurs (notice it
>>> no
>>> longer tries to restorecon on the files reset or rom because I
>>> commented
>>> out those commands)
>>>
>>> " restorecon -RvvvF /sys/bus/pci/devices/0000:04:00.1/config;
>>> restorecon -RvvvF /sys/bus/pci/devices/0000:04:00.1/resource*;
>>> /bin/rm -f guest1.xml;
>>> /usr/bin/virsh nodedev-reattach pci_0000_04_00_1
>>> /sbin/restorecon -RvvvF
>>> /sys/bus/pci/devices/0000:04:00.1/config
>>> /sys/bus/pci/devices/0000:04:00.1/resource
>>> /sys/bus/pci/devices/0000:04:00.1/resource0
>>> }'
>>> + attach_pci_device 1 guest1 guest1 guest2
>>> + local rc=0
>>> + case $1 in
>>> + /usr/bin/virsh attach-device guest1 pci_dev.xml
>>> error: Failed to attach device from pci_dev.xml
>>> error: internal error Unable to reset PCI device 0000:04:00.1:
>>> internal
>>> error Active 0000:04:00.0 devices on bus with 0000:04:00.1, not
>>> doing bus
>>> reset
>>>
>>> + (( rc+=1 ))
>>> + sleep 3
>>> + check_device_driver pci-stub"
>>>
>>> Shortly after this (although there are a number more operations and
>>> messages) it goes to exit_fail 'Attach failed'
>>>
>>> I may try this with the ethernet devices on the card that has
>>> nothing
>>> attached to it, or maybe even get off eth0 and run the test from
>>> the
>>> console. My question on either of those options is "If I do that am
>>> I
>>> defeating the purpose of the test?"
>>>
>>> Thanks
>>> Jim
>>>
>>> James Czyzak
>>> Linux Security Team
>>> Linux Technology Center
>>> (830) 839-4826
>>> czyzak@us.ibm.com
>>>
>>>
>>>
>>>
>>> From: Miroslav Vadkerti <mvadkert@redhat.com>
>>> To: James Czyzak/Beaverton/IBM@IBMUS
>>> Cc: audit-test-developer@lists.sourceforge.net
>>> Date: 01/09/2012 06:53 AM
>>> Subject: Re: [PATCH 1/1] kvm-iommu PCI PT rom and reset
>>> files not
>>> required
>>>
>>>
>>>
>>>
> Hi James,
>
> could you try out this patch if it fixes your issues with KVM PCI
> PT tests
> please? We currently do not have a installed machine to try it out.
>
> Thanks,
> /M
>
> On 01/09/2012 01:50 PM, mvadkert@redhat.com wrote:
> >>>> From: Miroslav Vadkerti <mvadkert@redhat.com>
> >>>>
> >>>>
> >>>> Signed-off-by: Miroslav Vadkerti <mvadkert@redhat.com>
> >>>> ---
> >>>> audit/kvm-iommu/test_pci_passthrough.bash | 16 ++++++++++++++++
> >>>> 1 files changed, 16 insertions(+), 0 deletions(-)
> >>>>
> >>>> diff --git a/audit/kvm-iommu/test_pci_passthrough.bash
> b/audit/kvm-iommu/test_pci_passthrough.bash
> >>>> index d324dee..40e52b0 100755
> >>>> --- a/audit/kvm-iommu/test_pci_passthrough.bash
> >>>> +++ b/audit/kvm-iommu/test_pci_passthrough.bash
> >>>> @@ -263,6 +263,14 @@ check_pci_device_dynamic() {
> >>>> # go through all required pci device files
> >>>> for dfile in $(ls
> /sys/bus/pci/devices/$pci_device/{config,resource*,rom,reset});
> >>>> do
> >>>> + # rom and reset files may not exist, if so skip them and log to
> run.log
> >>>> + #
> >>>>
http://www.kernel.org/doc/Documentation/filesystems/sysfs-pci.txt
> >>>> + #
> >>>>
http://www.kernel.org/doc/Documentation//ABI/testing/sysfs-bus-pci
> >>>> + if [ ! -e $dfile ]; then
> >>>> + echo "$FUNCNAME: ### INFO ### - skipping not existing file
> >>>> $dfile"
> >>>> + continue
> >>>> + fi
> >>>> +
> >>>> owner=$(stat -c "%U:%G" $dfile)
> >>>> label=$(stat -c "%C" $dfile)
> >>>>
> >>>> @@ -275,6 +283,14 @@ check_pci_device_dynamic() {
> >>>> # go through all required pci device files
> >>>> for dfile in $(ls
> /sys/bus/pci/devices/$pci_device/{config,resource*,rom,reset});
> >>>> do
> >>>> + # rom and reset files may not exist, if so skip them and log to
> run.log
> >>>> + #
> >>>>
http://www.kernel.org/doc/Documentation/filesystems/sysfs-pci.txt
> >>>> + #
> >>>>
http://www.kernel.org/doc/Documentation//ABI/testing/sysfs-bus-pci
> >>>> + if [ ! -e $dfile ]; then
> >>>> + echo "$FUNCNAME: ### INFO ### - skipping not existing file
> >>>> $dfile"
> >>>> + continue
> >>>> + fi
> >>>> +
> >>>> owner=$(stat -c "%U:%G" $dfile)
> >>>> label=$(stat -c "%C" $dfile)
> >>>>
>
>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
------------------------------------------------------------------------------
>>> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a
>>> complex
>>> infrastructure or vast IT resources to deliver seamless, secure
>>> access to
>>> virtual desktops. With this all-in-one solution, easily deploy
>>> virtual
>>> desktops for less than the cost of PCs and save 60% on VDI
>>> infrastructure
>>> costs. Try it free!
http://p.sf.net/sfu/Citrix-VDIinabox
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Audit-test-developer mailing list
>>> Audit-test-developer@lists.sourceforge.net
>>>
https://lists.sourceforge.net/lists/listinfo/audit-test-developer
>>
>>
>

- --
Miroslav Vadkerti :: QA Engineer / RHCE :: BaseOS QE - Security
IRC mvadkert at #qe #urt #rpmdiff :: GnuPG ID 0x25881087 at pgp.mit.edu
Phone +420 532 294 129 :: CZ +420 775 039 842 :: SK +421 904 135 440
Red Hat s.r.o, Purky˛ova 99/71, 612 45, Brno, Czech Republic
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla -
http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPJoX+AAoJEBliWhMliBCHR60H/A1BydwxgGhqsc8iPGRv+NHs
Qw3BK/qU3kFnReFGyLobrksr5vNanaWVgpiNenS9XhvX5j1vq7s1rJJ9ruSyuh/W
NaILfWFlA3gDqcTlaWgJpm3VO6ZCAugpg3sy8MJ/AZV3blGvuq0WGhEj+QJfkazX
WmgVZnp75LvfHmrdnFyVKfyV+Qdu29YvijbgKjKItP1s8P3C9Y+0YdJhpr19bAwf
8A7zUmqKUgYXayEJwyoBG6tyScqMIm8sINFslv+ugEkehfTl+neHnrWozOJ0kovc
L0RQKNRj7YwYq5rz85lve9s3QBZeOdhYymP5z85bWIvfFXuky1AK8IeptP3NWcw=
=WmBW
-----END PGP SIGNATURE-----