lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c71684b8-ce9a-ad05-89e5-a2955bd666b2@amd.com>
Date:   Wed, 7 Dec 2022 15:34:46 -0800
From:   Brett Creeley <bcreeley@....com>
To:     Jason Gunthorpe <jgg@...pe.ca>
Cc:     kvm@...r.kernel.org, netdev@...r.kernel.org,
        alex.williamson@...hat.com, cohuck@...hat.com, yishaih@...dia.com,
        shameerali.kolothum.thodi@...wei.com, kevin.tian@...el.com,
        shannon.nelson@....com, drivers@...sando.io
Subject: Re: [RFC PATCH vfio 3/7] vfio/pds: Add VFIO live migration support


On 12/7/2022 3:29 PM, Jason Gunthorpe wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
> 
> 
> On Wed, Dec 07, 2022 at 01:32:34PM -0800, Brett Creeley wrote:
> 
>>> Please implement the P2P states in your device. After long discussions
>>> we really want to see all VFIO migrations implementations support
>>> this.
>>>
>>> It is still not clear what qemu will do when it sees devices that do
>>> not support P2P, but it will not be nice.
>>
>> Does that mean VFIO_MIGRATION_P2P is going to be required going forward or
>> do we just need to handle the P2P transitions? Can you point me to where
>> this is being discussed?
> 
> It means the device has to support a state where it is not issuing any
> outgoing DMA but continuing to process incoming DMA.
> 
> This is mandatory to properly support multiple VFIO devices in the
> same VM, which is why we want to see all devices implementing it. If
> the devices don't support it we may assume it means the device is
> broken and qemu will have to actively block P2P at the IOMMU.
> 
> There was lots of long threads in around Dec 2021 if I recall, lore
> could probably find them. Somewhere around here based on the search
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fkvm%2F20220215155602.GB1046125%40nvidia.com%2F&amp;data=05%7C01%7Cbrett.creeley%40amd.com%7C5b6b2f8d92d34c0deaed08dad8aae13e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638060525686868907%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=Qd0VLPAL5LTYBXi40N3OfWlIecgIhJW70FIAwL9O1lQ%3D&amp;reserved=0

Thanks for the info and link.

Brett

> 
> Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ