similar to: free_irq_vector on ia64

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Please review and comments. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops strategy is appropriate too. Later I'll post the patchset which implements xen domU based on ia64/pv_ops. Currently only ia64/xen pv_ops implementation

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Please review and comments. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops strategy is appropriate too. Later I'll post the patchset which implements xen domU based on ia64/pv_ops. Currently only ia64/xen pv_ops implementation

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Now all the comments so far have been addressed, but only a few exceptions. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops strategy is appropriate too. Later I'll post the patchset which implements xen domU based on ia64/pv_ops.

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Now all the comments so far have been addressed, but only a few exceptions. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops strategy is appropriate too. Later I'll post the patchset which implements xen domU based on ia64/pv_ops.

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Changes from take 5 are rebased to Linux 2.6.26-rc3, bug fix ivt.S paravirtualization and multi entry point support. I believe these patches can be applied to the linux ia64 repository. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Changes from take 5 are rebased to Linux 2.6.26-rc3, bug fix ivt.S paravirtualization and multi entry point support. I believe these patches can be applied to the linux ia64 repository. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops

Hi linux/ia64 developers. Few days before Eddie posted the mail for Linux/IA64 paravirtualization. But only a few responded partially because there was no reviewable patches. Here is the patches for xen/ia64 Linux paravirtualization. The goal is to merge IA64 xen Linux paravirtualization for both domU and dom0 eventually. However the first step is to merge domU portion. As you can see from the

Hi. This patchset implements xen/ia64 domU support. Qing He and Eddie Dong also has been woring on pv_ops so that I want to discuss before going further and avoid duplicated work. I suppose that Eddie will also post his own patch. So reviewing both patches, we can reach to better pv_ops interface. - I didn't changed the ia64 intrinsic paravirtulization abi from the last post. Presumably it

Hi. This patchset implements xen/ia64 domU support. Qing He and Eddie Dong also has been woring on pv_ops so that I want to discuss before going further and avoid duplicated work. I suppose that Eddie will also post his own patch. So reviewing both patches, we can reach to better pv_ops interface. - I didn't changed the ia64 intrinsic paravirtulization abi from the last post. Presumably it

These chipsets include the VP2 engine which is composed of a bitstream processor (BSP) that decodes H.264 and a video processor (VP) which can do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are driven by separate xtensa chips embedded in the hardware. This patch provides the mechanism to load the kernel for the xtensa chips and provide the necessary interactions to do the rest of

I'm sure I'm doing something completely boneheaded here, but I've used this idiom (constructing an interpolation spline and using prediction from a backSpline to find an approximation profile confidence interval) many times before and haven't hit this particular problem: r2 <- c(1.04409027570601, 1.09953936543359, 1.15498845516117, 1.21043754488875,

For an SMP Linux HVM guest with PV drivers inserted, when we do save/restore (or LiveMigration) for the guest, it might panic after it''s restored. The panic point is inside ap_suspend(): .... while (info->do_spin) { cpu_relax(); read_lock(&suspend_lock); HYPERVISOR_yield(); ----> guest might panic on the invocation of this function.

... rather than __assign_irq_vector(), to ensure desc->affinity gets initialized properly. This at once eliminates the need to forward-declare the latter function. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/arch/x86/irq.c +++ b/xen/arch/x86/irq.c @@ -25,7 +25,6 @@ #include <public/physdev.h> static void parse_irq_vector_map_param(char *s); -static int

Apparently some players are ill-prepared for us claiming that a decoder exists only to have creating it fail, and express this poor preparation with crashes (e.g. flash). Check that firmware is there to increase the chances of there being a high correlation between reported capabilities and ability to create a decoder. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: 10.0 10.1

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

Hey, Op 04-06-13 20:38, Ilia Mirkin schreef: > On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: >> These chipsets include the VP2 engine which is composed of a bitstream >> processor (BSP) that decodes H.264 and a video processor (VP) which can >> do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are >> driven by separate

The current paravirt startup_ipi hook for vmware commit: ae5da273fe3352febd38658d8d34484cbcfb3423 is quite frankly ridiculous. In the middle of wake_up_secondary_cpu: We have: /* * Paravirt / VMI wants a startup IPI hook here to set up the * target processor state. */ startup_ipi_hook(phys_apicid, (unsigned long) start_secondary, (unsigned

The current paravirt startup_ipi hook for vmware commit: ae5da273fe3352febd38658d8d34484cbcfb3423 is quite frankly ridiculous. In the middle of wake_up_secondary_cpu: We have: /* * Paravirt / VMI wants a startup IPI hook here to set up the * target processor state. */ startup_ipi_hook(phys_apicid, (unsigned long) start_secondary, (unsigned

Hi Konrad, I just tried to boot a 3.8.0-rc0 kernel (last commit: 7313264b899bbf3988841296265a6e0e8a7b6521) as dom0 on my machine with current xen-unstable. The boot stalls: [ 0.000000] ACPI: PM-Timer IO Port: 0x808 [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01]

Recently, I ran rsync and got the following message: skipping non-regular file "981005_plteph-de405s.bsp" It turns out that the file in question is really a degenerate link that points back to itself. lrwxr-xr-x 1 18450 other 24 May 9 20:38 981005_plteph-de405s.bsp -> 981005_PLTEPH-DE405S.bsp The confusing this is that although rsync printed what looks like an