similar to: [PATCH v2] arm: change vendor ID for virtio-mmio

On 2015/7/30 3:16, Michael S. Tsirkin wrote: > ACPI spec 5.0 allows the use of PCI vendor IDs. > But virtio-mmio is not a PCI device, it's a platform device. Why do we drop the previous way using "QEMUXXXX"? Something I missed? > Since we have one for virtio, it seems neater to use that > rather than LNRO. For the device ID, use 103F which is a legacy ID that >

On 2015/7/30 16:04, Michael S. Tsirkin wrote: > On Thu, Jul 30, 2015 at 09:23:20AM +0800, Shannon Zhao wrote: >> >> >> On 2015/7/30 3:16, Michael S. Tsirkin wrote: >>> ACPI spec 5.0 allows the use of PCI vendor IDs. >>> >> But virtio-mmio is not a PCI device, it's a platform device. > > Yes. ACPI spec 5.0 says: > > A valid PNP ID must

On 2015/7/30 16:04, Michael S. Tsirkin wrote: > On Thu, Jul 30, 2015 at 09:23:20AM +0800, Shannon Zhao wrote: >> >> >> On 2015/7/30 3:16, Michael S. Tsirkin wrote: >>> ACPI spec 5.0 allows the use of PCI vendor IDs. >>> >> But virtio-mmio is not a PCI device, it's a platform device. > > Yes. ACPI spec 5.0 says: > > A valid PNP ID must

On 28 July 2015 at 11:27, Michael S. Tsirkin <mst at redhat.com> wrote: > On Tue, Jul 28, 2015 at 11:12:33AM +0100, Peter Maydell wrote: >> On 28 July 2015 at 11:08, Michael S. Tsirkin <mst at redhat.com> wrote: >> > On Tue, Jul 28, 2015 at 10:44:02AM +0100, Graeme Gregory wrote: >> >> Added the match table and pointers for ACPI probing to the driver.

On 28 July 2015 at 11:27, Michael S. Tsirkin <mst at redhat.com> wrote: > On Tue, Jul 28, 2015 at 11:12:33AM +0100, Peter Maydell wrote: >> On 28 July 2015 at 11:08, Michael S. Tsirkin <mst at redhat.com> wrote: >> > On Tue, Jul 28, 2015 at 10:44:02AM +0100, Graeme Gregory wrote: >> >> Added the match table and pointers for ACPI probing to the driver.

On 29 July 2015 at 20:16, Michael S. Tsirkin <mst at redhat.com> wrote: > ACPI spec 5.0 allows the use of PCI vendor IDs. > > Since we have one for virtio, it seems neater to use that > rather than LNRO. For the device ID, use 103F which is a legacy ID that > isn't used in virtio PCI spec - seems to make sense since virtio-mmio is > a legacy device but we don't know

On Thu, Jul 30, 2015 at 09:23:20AM +0800, Shannon Zhao wrote: > > > On 2015/7/30 3:16, Michael S. Tsirkin wrote: > > ACPI spec 5.0 allows the use of PCI vendor IDs. > > > But virtio-mmio is not a PCI device, it's a platform device. Yes. ACPI spec 5.0 says: A valid PNP ID must be of the form "AAA####" where A is an uppercase letter and # is a hex digit.

On 30 July 2015 at 09:04, Michael S. Tsirkin <mst at redhat.com> wrote: > On Thu, Jul 30, 2015 at 09:23:20AM +0800, Shannon Zhao wrote: >> >> Why do we drop the previous way using "QEMUXXXX"? Something I missed? > > So that guests that bind to this interface will work fine with non QEMU > implementations of virtio-mmio. I don't understand this sentence.

On 30 July 2015 at 09:04, Michael S. Tsirkin <mst at redhat.com> wrote: > On Thu, Jul 30, 2015 at 09:23:20AM +0800, Shannon Zhao wrote: >> >> Why do we drop the previous way using "QEMUXXXX"? Something I missed? > > So that guests that bind to this interface will work fine with non QEMU > implementations of virtio-mmio. I don't understand this sentence.

> From: Jean-Philippe Brucker > Sent: Saturday, April 8, 2017 3:18 AM > > Unlike other virtio devices, the virtio-iommu doesn't work independently, > it is linked to other virtual or assigned devices. So before jumping into > device operations, we need to define a way for the guest to discover the > virtual IOMMU and the devices it translates. > > The host must

> From: Jean-Philippe Brucker > Sent: Saturday, April 8, 2017 3:18 AM > > Unlike other virtio devices, the virtio-iommu doesn't work independently, > it is linked to other virtual or assigned devices. So before jumping into > device operations, we need to define a way for the guest to discover the > virtual IOMMU and the devices it translates. > > The host must

Hello everybody! Since the update from 6.2-STABLE to 7.0 I'm encountering problems with the temperature of my Thinkpad X60s. Under heavy load, e.g., make builworld or compile gcc or... I get the following output in /var/log/messages: Dec 29 01:53:13 delta1 root: WARNING: system temperature too high, shutting down soon! Dec 29 01:53:13 delta1 syslogd: /dev/:0: No such file or directory Dec 29

The following is a revised patch series to add support for a VM generation ID virtual device for HVM guests. The basic requirements of this device are as follows: - It must be exposed somewhere in ACPI namespace with a _CID of "VM_Gen_Counter". - It must also include a _DDN of "VM_Gen_Counter". - It must contain a _HID object but no particular value is required. - It must

> From: Jean-Philippe Brucker [mailto:jean-philippe.brucker at arm.com] > Sent: Wednesday, April 19, 2017 2:41 AM > > On 18/04/17 10:51, Tian, Kevin wrote: > >> From: Jean-Philippe Brucker > >> Sent: Saturday, April 8, 2017 3:18 AM > >> > >> Unlike other virtio devices, the virtio-iommu doesn't work independently, > >> it is linked to

> From: Jean-Philippe Brucker [mailto:jean-philippe.brucker at arm.com] > Sent: Wednesday, April 19, 2017 2:41 AM > > On 18/04/17 10:51, Tian, Kevin wrote: > >> From: Jean-Philippe Brucker > >> Sent: Saturday, April 8, 2017 3:18 AM > >> > >> Unlike other virtio devices, the virtio-iommu doesn't work independently, > >> it is linked to

These patch update Windows generation ID support on ACPI. First patch mainly update to new specifications while second one introduce again the device in ACPI table. Frediano Ziglio (2): genid: Update Windows generation ID genid: Introduce again Windows generation ID device docs/misc/xenstore-paths.markdown | 6 ++++ tools/firmware/hvmloader/acpi/build.c | 49

> From: Jean-Philippe Brucker > Sent: Saturday, February 29, 2020 1:26 AM > > Platforms without device-tree do not currently have a method for > describing the vIOMMU topology. Provide a topology description embedded > into the virtio device. > > Use PCI FIXUP to probe the config space early, because we need to > discover the topology before any DMA configuration takes

> From: Jean-Philippe Brucker > Sent: Saturday, February 29, 2020 1:26 AM > > Platforms without device-tree do not currently have a method for > describing the vIOMMU topology. Provide a topology description embedded > into the virtio device. > > Use PCI FIXUP to probe the config space early, because we need to > discover the topology before any DMA configuration takes

Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080617/73afe727/attachment.pgp

I have an Asus A8V-MX motherboard with an AMD Athlong 64 X2 3800+ CPU and I'm trying to run powerd to keep it cooler/quieter/greener. I'm running -STABLE (6.1-RC) cvsup'ed a couple of days ago, with a kernel config that consists of the SMP sample plus an atapicam device. I'm loading the cpufreq.ko module in /boot/loader.conf. I've attached my dmesg output and sysctl -a