similar to: [PATCH]xend: fix a typo in pci.py

The hvm domain which is being debugged sometimes crashes with the following message: (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest state (0). (XEN) ************* VMCS Area ************** (XEN) *** Guest State *** (XEN) CR0: actual=0x000000008005003b, shadow=0x000000008005003b, gh_mask=ffffffffffffffff ...[snip]... (XEN) DebugCtl=0000000000000000

Hi, This set of patches remarkably accelerates IDE PIO on HVM/IA64. I got a throughput of 2.11MB/sec in disk read performance. Without it, it was only 64kB/sec. I posted the prototype once. http://lists.xensource.com/archives/html/xen-devel/2006-12/msg00077.html The basic idea is to add a buffering mechanism in a hypervisor. I know this approach is not sophisticated. But there is no other good

The value of ACPI PM-Timer may be broken on save unless the timer mode is delay_for_missed_ticks. With other timer modes, vcpu->arch.hvm_vcpu.guest_time is always zero and the adjustment from its value is wrong. This patch fixes the saved value of ACPI PM-Timer: - don''t adjust the PM-Timer if vcpu->arch.hvm_vcpu.guest_time is zero. - consolidate calculations of PM-Timer to one

There is a race condition between XEN_DOMCTL_SHADOW_OP_ENABLE_LOGDIRTY and HVMOP_track_dirty_vram hypercall. Although HVMOP_track_dirty_vram is called many times from qemu-dm which is connected via VNC, XEN_DOMCTL_SHADOW_OP_ENABLE_LOGDIRTY is called only once from a migration process (e.g. xc_save, libxl-save-helper). So the race seldom happens, but the following cases are possible.

Hi all, I downloaded the xen 3.3.0 and now testing the pci pass-through with the NIC. Using late binding, the pci slot 0000:08:01.0 is assigned to pciback. But pci related xm commands are not working. For eg: linux-242:/home/xen-3.3.0 # xm pci-list-assignable-devices Unexpected error: <type ''exceptions.OSError''> Please report to

> What do you mean exactly by "behave differently on the other side of the cast”? Do you have a concrete example? I was hesitant to say only in that it is probably an "abuse of mechanics" and definitely playing with fire, _however_ the target I'm working on has extensive bit operations for a subset of memory, including atomic test-and-set, etc. It's convenient to be

Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device states. v2: convert to pci_dev quirk put a proper technical explanation of the issue as a in-code comment v3: disable it only for certain combinations of intel and nvidia hardware v4: simplify quirk by setting flag on the GPU itself v5: restructure quirk to make it easier to add new IDs fix whitespace issues

On Fri, Nov 22, 2019 at 12:30:20PM +0100, Rafael J. Wysocki wrote: > On Fri, Nov 22, 2019 at 11:36 AM Mika Westerberg > <mika.westerberg at intel.com> wrote: > > > > On Thu, Nov 21, 2019 at 11:39:23PM +0100, Rafael J. Wysocki wrote: > > > On Thu, Nov 21, 2019 at 8:49 PM Mika Westerberg > > > <mika.westerberg at intel.com> wrote: > > > >

On Tue, Nov 21, 2017 at 6:46 PM, Thierry Reding <thierry.reding at gmail.com> wrote: > On Tue, Nov 21, 2017 at 04:01:16PM +0100, Karol Herbst wrote: >> This should make systems more stable where resuming the GPU fails. This >> can happen due to bad firmware or due to a bug within the kernel. The >> last thing which should happen in either case is an unusable system.

On Thu, Nov 21, 2019 at 11:39:23PM +0100, Rafael J. Wysocki wrote: > On Thu, Nov 21, 2019 at 8:49 PM Mika Westerberg > <mika.westerberg at intel.com> wrote: > > > > On Thu, Nov 21, 2019 at 04:43:24PM +0100, Rafael J. Wysocki wrote: > > > On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg > > > <mika.westerberg at intel.com> wrote: > > > >

Folks, The patch queue for 3.1.1 has been pushed into http://xenbits.xensource.com/xen-3.1-testing.hg, and tagged as -rc1. Please try it out and let us know of any problems (patches gladly accepted!). -- Keir PS. The patch queue (xen-3.1-testing.pq.hg) is no longer being used. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device states. v2: convert to pci_dev quirk put a proper technical explanation of the issue as a in-code comment v3: disable it only for certain combinations of intel and nvidia hardware v4: simplify quirk by setting flag on the GPU itself Signed-off-by: Karol Herbst <kherbst at redhat.com> Cc: Bjorn Helgaas

The following combine(-enabling transformation) makes me uncomfortable:   gep(addrspacecast(gep p0) to p1)   addrspacecast(gep(gep p0)) to p1 It's applied at visitAddrSpaceCast in InstCombineCasts.cpp. Before this, I'd always assumed address spaces were very much "user domain". Datalayout even supports marking a space as "non-integral", to designate that manipulation as

Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device states. v2: convert to pci_dev quirk put a proper technical explanation of the issue as a in-code comment v3: disable it only for certain combinations of intel and nvidia hardware Signed-off-by: Karol Herbst <kherbst at redhat.com> Cc: Bjorn Helgaas <bhelgaas at google.com> Cc: Lyude Paul <lyude at

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 should be skipped. On Wed, Oct 16, 2019 at 9:14 PM Bjorn Helgaas <helgaas at kernel.org> wrote: > > On Wed, Oct 16, 2019 at 04:44:49PM +0200, Karol Herbst wrote: > > Fixes state transitions of

On Fri, Nov 22, 2019 at 12:30 PM Rafael J. Wysocki <rafael at kernel.org> wrote: > > On Fri, Nov 22, 2019 at 11:36 AM Mika Westerberg > <mika.westerberg at intel.com> wrote: > > > > On Thu, Nov 21, 2019 at 11:39:23PM +0100, Rafael J. Wysocki wrote: > > > On Thu, Nov 21, 2019 at 8:49 PM Mika Westerberg > > > <mika.westerberg at intel.com>

Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device states. v2: convert to pci_dev quirk put a proper technical explanation of the issue as a in-code comment v3: disable it only for certain combinations of intel and nvidia hardware v4: simplify quirk by setting flag on the GPU itself v5: restructure quirk to make it easier to add new IDs fix whitespace issues

Hi, In the case of linux, crash_kexec() is occured by "sysrq c". In the case of DomainU on xen, Help is occured by "sysrq c" now. So The way of dumping DomainU''s memory manualy is nothing. I fix this issue by the following way. 1. Panic is occured by "sysrq c" on both Domain0 and DomainU. 2. On DomainU, coredump is generated in /var/xen/dump (on Domain0).

The patch moves the struct IO_APIC_route_entry to a common place. This allows us to share the struct with iosapic. Thanks, -- Dexuan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

I tried latest xen and linux-xen staging tree, but failed to run HVM domain on x86-64 environment. domU creation is OK. However the weird thing is not HVM domain itself. Instead system crashed on dom0 context. I saw once with some stack dump that xen''s page fault handler is executed on a dom0''s stack which then causes nested page fault due to unable to fetch vcpu pointer.