Displaying 11 results from an estimated 11 matches for "addr_lo".
Did you mean:
addr_len
2008 Feb 28
5
[amd iommu] [patch 2/2]Add APCI tables support for AMD IOMMU
Signed-off-by: Wei Wang <wei.wang2@amd.com>
--
AMD Saxony, Dresden, Germany
Operating System Research Center
Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
2011 Nov 18
5
[PATCH 0 of 4] amd iommu: IOMMUv2 support
This patch set adds basic supports for amd next generation iommu (IOMMUv2)
hardware. IOMMUv2 supports various new features advertised by iommu
extended feature register. It introduces guest level IO translation and
supports state-of-the-art ATS/ATC devices with demand paging capability.
Please refer to AMD IOMMU Architectural Specification [1] for more details.
Thanks,
Wei
[1]
2013 May 28
2
[RFC 7/11] virtio_pci: new, capability-aware driver.
...> +static void iowrite64(u64 val, const __le64 *addr)
> > > > +{
> > > > + iowrite32((u32)val, (__le32 *)addr);
> > > > + iowrite32(val >> 32, (__le32 *)addr + 1);
> > > > +}
> > > > +
> > >
> > > Let's put addr_lo/addr_hi in the structure then,
> > > to make the fact this field is not atomic explicit?
> >
> > Good point, assuming I haven't missed something.
> >
> > Are 64-bit accesses actually unknown in PCI-land? Or is this a limited
> > availability thing?
>...
2013 May 29
1
[RFC 7/11] virtio_pci: new, capability-aware driver.
...>> > > > +{
> >> > > > + iowrite32((u32)val, (__le32 *)addr);
> >> > > > + iowrite32(val >> 32, (__le32 *)addr + 1);
> >> > > > +}
> >> > > > +
> >> > >
> >> > > Let's put addr_lo/addr_hi in the structure then,
> >> > > to make the fact this field is not atomic explicit?
> >> >
> >> > Good point, assuming I haven't missed something.
> >> >
> >> > Are 64-bit accesses actually unknown in PCI-land? Or is this...
2013 May 08
11
[PATCH 1/2] xen, libxc: init msix addr/data with value from qemu via hypercall
Accelerated msix entry is initialized to zero when msixtbl_pt_register is
called. This doesn''t match the value from qemu side, although pirq may already
be mapped and binded in qemu side. Kernel will get wrong value when reading
msix info.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Tested-by: Yuval Shaia <yuval.shaia@oracle.com>
---
tools/libxc/xc_domain.c
2013 May 29
0
[RFC 7/11] virtio_pci: new, capability-aware driver.
...(u64 val, const __le64 *addr)
>> > > > +{
>> > > > + iowrite32((u32)val, (__le32 *)addr);
>> > > > + iowrite32(val >> 32, (__le32 *)addr + 1);
>> > > > +}
>> > > > +
>> > >
>> > > Let's put addr_lo/addr_hi in the structure then,
>> > > to make the fact this field is not atomic explicit?
>> >
>> > Good point, assuming I haven't missed something.
>> >
>> > Are 64-bit accesses actually unknown in PCI-land? Or is this a limited
>> >...
2009 May 20
0
[PATCHv2-RFC 2/2] qemu-kvm: use common code for assigned msix
..._ROUTING_MSI;
- adev->entry[entries_nr].flags = 0;
- adev->entry[entries_nr].u.msi.address_lo = msg_addr;
- adev->entry[entries_nr].u.msi.address_hi = msg_upper_addr;
- adev->entry[entries_nr].u.msi.data = msg_data;
- DEBUG("MSI-X data 0x%x, MSI-X addr_lo 0x%x\n!", msg_data, msg_addr);
- kvm_add_routing_entry(kvm_context, &adev->entry[entries_nr]);
-
- msix_entry.gsi = adev->entry[entries_nr].gsi;
+ msix_entry.gsi = pci_dev->msix_irq_entries[i].gsi;
msix_entry.entry = i;
r = kvm_assign_set_msix_entry...
2009 May 20
0
[PATCHv2-RFC 2/2] qemu-kvm: use common code for assigned msix
..._ROUTING_MSI;
- adev->entry[entries_nr].flags = 0;
- adev->entry[entries_nr].u.msi.address_lo = msg_addr;
- adev->entry[entries_nr].u.msi.address_hi = msg_upper_addr;
- adev->entry[entries_nr].u.msi.data = msg_data;
- DEBUG("MSI-X data 0x%x, MSI-X addr_lo 0x%x\n!", msg_data, msg_addr);
- kvm_add_routing_entry(kvm_context, &adev->entry[entries_nr]);
-
- msix_entry.gsi = adev->entry[entries_nr].gsi;
+ msix_entry.gsi = pci_dev->msix_irq_entries[i].gsi;
msix_entry.entry = i;
r = kvm_assign_set_msix_entry...
2009 May 11
0
[PATCH 2/2] qemu-kvm: use common code for assigned msix
..._ROUTING_MSI;
- adev->entry[entries_nr].flags = 0;
- adev->entry[entries_nr].u.msi.address_lo = msg_addr;
- adev->entry[entries_nr].u.msi.address_hi = msg_upper_addr;
- adev->entry[entries_nr].u.msi.data = msg_data;
- DEBUG("MSI-X data 0x%x, MSI-X addr_lo 0x%x\n!", msg_data, msg_addr);
- kvm_add_routing_entry(kvm_context, &adev->entry[entries_nr]);
-
- msix_entry.gsi = adev->entry[entries_nr].gsi;
- msix_entry.entry = i;
+ msix_entry.gsi = pci_dev->msix_irq_entries[i].gsi;
+ msix_entry.entry = n++;...
2009 May 11
0
[PATCH 2/2] qemu-kvm: use common code for assigned msix
..._ROUTING_MSI;
- adev->entry[entries_nr].flags = 0;
- adev->entry[entries_nr].u.msi.address_lo = msg_addr;
- adev->entry[entries_nr].u.msi.address_hi = msg_upper_addr;
- adev->entry[entries_nr].u.msi.data = msg_data;
- DEBUG("MSI-X data 0x%x, MSI-X addr_lo 0x%x\n!", msg_data, msg_addr);
- kvm_add_routing_entry(kvm_context, &adev->entry[entries_nr]);
-
- msix_entry.gsi = adev->entry[entries_nr].gsi;
- msix_entry.entry = i;
+ msix_entry.gsi = pci_dev->msix_irq_entries[i].gsi;
+ msix_entry.entry = n++;...
2013 Aug 11
10
[PATCH 00/10] Add support for MPEG2 and VC-1 on VP3/VP4 for NV98-NVAF
As it turns out, with the proprietary firmware, the VP3 and VP4 interfaces are
identical. Furthermore, this is all already implemented for nvc0. So these
patches (a) move the easily sharable bits of the nvc0 implementation into the
nouveau directory, and then (b) implement the other parts in nv50. The
non-shared parts are still largely copies, but there are some differences, not
the least of which