On Mon, 2022-05-02 at 09:48 +0200, Pierre Morel wrote:
>
> On 4/22/22 14:10, Matthew Rosato wrote:
> > On 4/22/22 5:39 AM, Pierre Morel wrote:
> > >
> > > On 4/4/22 20:17, Matthew Rosato wrote:
> > > > Use the associated kvm ioctl operation to enable adapter event
> > > > notification
> > > > an
On 7/23/20 5:13 PM, Matthew Rosato wrote:
> I noticed that after kernel commit abafbc55 'vfio-pci: Invalidate mmaps
> and block MMIO access on disabled memory' vfio-pci via qemu on s390x
> fails spectacularly, with errors in qemu like:
>
> qemu-system-s390x: vfio_region_read(0001:00:00.0:region
On 7/24/20 11:46 AM, Niklas Schnelle wrote:
>
>
> On 7/23/20 5:13 PM, Matthew Rosato wrote:
>> I noticed that after kernel commit abafbc55 'vfio-pci: Invalidate mmaps
>> and block MMIO access on disabled memory' vfio-pci via qemu on s390x
>> fails sp
On 7/24/20 11:46 AM, Niklas Schnelle wrote:
>
>
> On 7/23/20 5:13 PM, Matthew Rosato wrote:
>> I noticed that after kernel commit abafbc55 'vfio-pci: Invalidate mmaps
>> and block MMIO access on disabled memory' vfio-pci via qemu on s390x
>> fails sp
On 7/27/20 5:40 PM, Pierre Morel wrote:
>
>
> On 2020-07-23 18:29, Alex Williamson wrote:
>> On Thu, 23 Jul 2020 11:13:55 -0400
>> Matthew Rosato wrote:
>>
>>> I noticed that after kernel commit abafbc55 'vfio-pci: Invalidate mmaps
>>> and block MMIO access on disabled memory' vfio-pci via qe
On 7/27/20 6:47 PM, Alex Williamson wrote:
> On Mon, 27 Jul 2020 17:40:39 +0200
> Pierre Morel wrote:
>
>> On 2020-07-23 18:29, Alex Williamson wrote:
>>> On Thu, 23 Jul 2020 11:13:55 -0400
>>> Matthew Rosato wrote:
>>>
I noticed that after kernel commit abafbc55 'vfio-pci: Invalidate
On 7/28/20 2:52 PM, Alex Williamson wrote:
> On Tue, 28 Jul 2020 11:33:55 +0200
> Niklas Schnelle wrote:
>
>> On 7/27/20 6:47 PM, Alex Williamson wrote:
>>> On Mon, 27 Jul 2020 17:40:39 +0200
>>> Pierre Morel wrote:
>>>
>>>> On 2020-
On 10/15/20 3:34 PM, Christian Borntraeger wrote:
>
>
> On 15.10.20 15:32, Christian Borntraeger wrote:
>>
>>
>> On 15.10.20 15:16, Matthew Rosato wrote:
>>> Currently, a subsystem reset event leaves PCI devices enabled, causing
>>> issues post-reset in the guest (an example would be after a k
On 1/21/21 1:30 PM, Pierre Morel wrote:
>
>
> On 1/21/21 10:58 AM, Niklas Schnelle wrote:
>>
>>
>> On 1/21/21 9:27 AM, Pierre Morel wrote:
>>>
>>>
>>> On 1/20/21 9:29 PM, Matthew Rosato wrote:
>>>> On 1/20/21 2:18 PM, Pierre
On 1/21/21 3:46 PM, Pierre Morel wrote:
>
>
> On 1/21/21 2:37 PM, Niklas Schnelle wrote:
>>
>>
>> On 1/21/21 1:30 PM, Pierre Morel wrote:
>
>>>>
>>>> Just wanted to say that we've had a very similar discussion with
>>>&g
On 1/21/21 9:27 AM, Pierre Morel wrote:
>
>
> On 1/20/21 9:29 PM, Matthew Rosato wrote:
>> On 1/20/21 2:18 PM, Pierre Morel wrote:
>>>
>>>
> ...snip...
>
>>
>> So, I mean I can change the code to be more permissive in that way (allow
>> any device that doesn't have MSI-X capability to at lea
-158,6 +158,7 @@ typedef struct ClpRspQueryPciGrp {
> #define CLP_RSP_QPCIG_MASK_NOI 0xfff
> uint16_t i;
> uint8_t version;
> +#define CLP_RSP_QPCIG_MASK_RTR 0x20
> #define CLP_RSP_QPCIG_MASK_FRAME 0x2
> #define CLP_RSP_QPCIG_MASK_REFRESH 0x1
> uint8_t fr;
Looks good to me!
Tested-by: Niklas Schnelle
Reviewed-by: Niklas Schnelle
void);
> void s390_pci_sclp_configure(SCCB *sccb);
> void s390_pci_sclp_deconfigure(SCCB *sccb);
> void s390_pci_iommu_enable(S390PCIIOMMU *iommu);
> +void s390_pci_iommu_direct_map_enable(S390PCIIOMMU *iommu);
> void s390_pci_iommu_disable(S390PCIIOMMU *iommu);
> void s390_pci_generate_error_event(uint16_t pec, uint32_t fh, uint32_t fid,
> uint64_t faddr, uint32_t e);
I'm not too familiar with the existing code or QEMU in general, but the
changes makes sense to me. I'm assuming the braces around single
statement bodies are accepted style in QEMU?
I retested this version together with the v4 of the kernel version too.
So feel free to add:
Tested-by: Niklas Schnelle
Reviewed-by: Niklas Schnelle
On Fri, 2025-01-24 at 15:21 -0500, Matthew Rosato wrote:
> When receiving a guest mpcifc(4) or mpcifc(6) instruction without the T
> bit set, treat this as a request to perform direct mapping instead of
> address translation. In order to facilitate this, pin the entirety of
> guest memory into the
allback to using system calls to access
> > the PCI mapped resources.
> >
> > This patch adds helper functions for mmio reads
> > and writes for s390x.
> >
> > Reviewed-by: Stefan Hajnoczi
> > Reviewed-by: Niklas Schnelle
> > Signed-off-by:
On Fri, 2025-04-11 at 16:28 -0600, Alex Williamson wrote:
> > >
--- snip ---
> > > Cc: folks related to that commit.
> > >
> > > The original issue that brought us ram_device was a very obscure
> > > alignment of a memory region versus a device quirk only seen with
> > > assignment of specific RT
good to me.
Pretty much exactly matches what I did for rdma-core a while back.
> +
> +uint8_t s390x_pci_mmio_read_8(const void *ioaddr)
> +{
> +uint8_t val = 0;
> +
> +if (is_mio_supported) {
> +val = s390x_pcilgi(ioaddr, sizeof(val));
> +} else {
> +syscall(__NR_s390_pci_mmio_read, ioaddr, &val, sizeof(val));
> +}
> +return val;
> +}
> +
>
--- snip ---
> +
> +void s390x_pci_mmio_write_64(void *ioaddr, uint64_t val)
> +{
> +if (is_mio_supported) {
> +s390x_pcistgi(ioaddr, val, sizeof(val));
> +} else {
> +syscall(__NR_s390_pci_mmio_write, ioaddr, &val, sizeof(val));
> +}
> +}
> +
Thanks for the great work!
Reviewed-by: Niklas Schnelle
On Wed, 2025-04-02 at 11:51 -0400, Stefan Hajnoczi wrote:
> On Tue, Apr 01, 2025 at 10:22:43AM -0700, Farhan Ali wrote:
> > Hi,
> >
> > Recently on s390x we have enabled mmap support for vfio-pci devices [1].
>
> Hi Alex,
> I wanted to bring this to your attention. Feel free to merge it through
>
18 matches
Mail list logo
