search for: ospm

When hotplug hvm vcpu by ''xm vcpu-set'' command, if it add/remove many vcpus by 1 ''xm vcpu-set'' command, it has a bug that it cannot add/remove all vcpus that want to be added/removed. This patch is to fix the bug. It delays trigger sci until all xenstore cpu node status are watched. Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

Has there been any work done on getting an ACPI fixed event or perhaps a general purpose event delivered to an HVM guest. Whereby, the HVM guests OSPM could consume the event and act accordingly. Or Perhaps better stated how would one go about passing an ACPI fixed event or general purpose event that was raised and consumed by dom0 and subsequently pass the event on to each of the HVM domu''s. Thanks ___________________________...

...* _STA: return a device''s status, e.g. enabled or removed - * Other methods are optional: - * _PS0/3: put them here for debug purpose * * Eject button would generate a general-purpose event, then the * control method for this event uses Notify() to inform OSPM which @@ -344,13 +342,6 @@ stmt("Name", "_ADR, 0x%08x", ((slot & ~7) << 13) | (slot & 7)); /* _SUN == dev */ stmt("Name", "_SUN, 0x%08x", slot >> 3); - push_block("Method", "...

ioemu-remote: The device model needs to write in the ACPI tables when it wakes up from S3 state. Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com> -- Jean Guyader _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Enable cpufreq support in Xen for AMD Operton processors by: 1) Allowing the PowerNow! driver in dom0 to write to the PowerNow! MSRs. 2) Adding the cpufreq notifier chain to time-xen.c in dom0. On a frequency change, a platform hypercall is performed to scale the frequency multiplier in the hypervisor. 3) Adding a platform hypercall to the hypervisor the scale the frequency multiplier and reset

On 04/27/2017 04:31 PM, Stefano Ricci wrote: > Here is the backtrace of the libvirt process just started [Just a side note, you shouldn't top post on technical lists. Gmail sucks at this.] > > https://pastebin.com/R66myzFp Looks like libvirtd is trying to spawn /usr/bin/qemu-system-x86_64 but it takes ages to init. In the debug logs you might see the actual command line that

...I/O read), and native(using mwait). MWAIT is always preferred when both underlying CPU and OS support, which is a more efficient way to conduct C-state transition. Xen PM relies on Dom0 to parse ACPI Cx/Px information, which involves one step to notify BIOS about a set of capabilities supported by OSPM. One capability is about mwait support, which if true ACPI Cx entry contains entry parameters for mwait, or else I/O port information is provided. Xen PM later decides entry method (i/o or mwait) based on parsed ACPI information from dom0. However Xen doesn''t expose MWAIT capability to d...

...s"}, {"name": "query-chardev"}, {"name": > "query-blockstats"}, {"name": "query-block-jobs"}, {"name": > "query-block"}, {"name": "query-balloon"}, {"name": > "query-acpi-ospm-status"}, {"name": "qom-set"}, {"name": > "qom-list-types"}, {"name": "qom-list"}, {"name": "qom-get"}, {"name": > "qmp_capabilities"}, {"name": "pmemsave"}, {"nam...

From ba9abf6ee7e5fe0515e2d51b14743c8d5416285c Mon Sep 17 00:00:00 2001 From: Liu, Jinsong <jinsong.liu@intel.com> Date: Fri, 24 Feb 2012 02:18:02 +0800 Subject: [PATCH 2/2] Xen pad logic This patch implement Xen pad logic, and when getting pad device notification, it hypercalls to Xen hypervisor for core parking. Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com> ---

...comparison this 400-line parser is well contained and does the job. I > > didn't yet see compelling reasons not to merge this, but I'll be > > interested to see some more specific concerns. > > An ACPI table parse wouldn't need more lines of code. It realies on ACPI OSPM itself to handle ACPI bytecode, which is huge. > For embedded > systems there is still the DT way of describing things. For some embedded systems. > Regards, > > Joerg

resend. didn''t see it show up on the list. Sorry if duplicate. > >>Has there been any work done on getting an ACPI fixed event or >>perhaps a general >>purpose event delivered to an HVM guest. Whereby, the HVM >>guests OSPM could consume the event and act accordingly. > > Now Xen support live migration with VT- d assigned device, which > is based on a virtual ACPI hotplug mechanism, where one specific > GPE bit is created within Qemu. You can check piix4acpi.c in > Qemu for reference. > I will l...

...chardev-backends"}, {"name": "query-chardev"}, {"name": "query-blockstats"}, {"name": "query-block-jobs"}, {"name": "query-block"}, {"name": "query-balloon"}, {"name": "query-acpi-ospm-status"}, {"name": "qom-set"}, {"name": "qom-list-types"}, {"name": "qom-list"}, {"name": "qom-get"}, {"name": "qmp_capabilities"}, {"name": "pmemsave"}, {"name": &...

# HG changeset patch # User Boris Ostrovsky <boris.ostrovsky@amd.com> # Date 1345135101 -7200 # Node ID 85190245a94d9945b7656c971ba36f7d1eff5c19 # Parent 6d56e31fe1e1dc793379d662a36ff1731760eb0c AMD, powernow: Update P-state directly when _PSD''s CoordType is DOMAIN_COORD_TYPE_HW_ALL When _PSD''s CoordType is DOMAIN_COORD_TYPE_HW_ALL (i.e. shared_type is

...quot;name": "query-chardev"}, {"name": >> "query-blockstats"}, {"name": "query-block-jobs"}, {"name": >> "query-block"}, {"name": "query-balloon"}, {"name": >> "query-acpi-ospm-status"}, {"name": "qom-set"}, {"name": >> "qom-list-types"}, {"name": "qom-list"}, {"name": "qom-get"}, {"name": >> "qmp_capabilities"}, {"name": "pmemsave"}, {&...

Hi Michael, On Tue, Mar 03, 2020 at 11:09:41AM -0500, Michael S. Tsirkin wrote: > No. It's coded into the hardware. Which might even be practical > for bare-metal (e.g. on-board flash), but is very practical > when the device is part of a hypervisor. If its that way on PPC, than fine for them. But since this is enablement for x86, it should follow the x86 platform best practices,

Hi Michael, On Tue, Mar 03, 2020 at 11:09:41AM -0500, Michael S. Tsirkin wrote: > No. It's coded into the hardware. Which might even be practical > for bare-metal (e.g. on-board flash), but is very practical > when the device is part of a hypervisor. If its that way on PPC, than fine for them. But since this is enablement for x86, it should follow the x86 platform best practices,

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

On Wed, Oct 16, 2019 at 11:37 PM Bjorn Helgaas <helgaas at kernel.org> wrote: > > [+cc linux-acpi] > > On Wed, Oct 16, 2019 at 09:18:32PM +0200, Karol Herbst wrote: > > but setting the PCI_DEV_FLAGS_NO_D3 flag does prevent using the > > platform means of putting the device into D3cold, right? That's > > actually what should still happen, just the D3hot step

This patch series makes suspend support in qemu alot more useful. Right now the guest can put itself into s3, but qemu will wakeup the guest instantly. With this patch series applied the guest will stay suspended instead and there are a few events which can kick the guest out of suspend state: A monitor command, ps/2 input, serial input, rtc. Not much yet, but it''s a start with the