point, because they ought to be immediate.
Tidy up the examples in the presentation and wire-protocol sections, and bring
them into sync with the main body text.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
There are three reasons to do this.
1. IOSAPIC is different with IOAPIC
such as:
1. IOAPIC implement broadcast, but IOSAPIC doesn't
2. IOSAPIC doesn't implement dest_mode and remote irr bits.
3. IOSAPIC implement EOI but IOAPIC doesn't
etc.
2. In IA32 side there are I8259 and LAPIC who are
related to IOAPIC, but In IPF there is no I8259 and has LSAPIC.
3. after creating this file, all header files under asm-ia64/hvm, which
are linked from IA32 side, are not needed.
Signed-off-by: Anthony Xu <anthony.xu@intel.com>
After being offline for a long time, the softlockup watchdog triggers
a BUG() on our faces. This is expected, as in fact, we spent more than
a fixed 10*HZ amount of time without touching the watchdog.
However, by inspecting the contents of stolen inside timer irq handler,
we can gain awareness of the fact, and do better than that.
Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com>
The major/minor has now been allocated to us by lanana.org.
This is based on previous patches from:
Jeremy Katz <katzj@redhat.com>
Amos Waterland <apw@us.ibm.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
1. Fix RIP-relative EA calculation. Immediate operands are never 64-bit.
2. Displacements are sign-extended so used signed types.
Signed-off-by: Keir Fraser <keir@xensource.com>
allowed in some files in order to track linux lineage
Signed-off-by: Jimi Xenidis <jimix@watson.ibm.com>
Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
When using the register dump feature of Xen, one will sometimes see a
message about an IPI finish stall. This is because of an int to long
comparison bug, so fix it by doing proper nanosecond based time
accounting with no explicit reference to timebase_freq.
Signed-off-by: Amos Waterland <apw@us.ibm.com>
Signed-off-by: Jimi Xenidis <jimix@watson.ibm.com>
Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
--HG--
extra : transplant_source : .%90%9Do%2A%B7g%FEW%23%A9%7E/T%13%F8v%16r%96
Do not override the caller's wishes regarding waiting for smp function
call completion. I was being too conservative in this respect: the lock
protects the call_data structure, and the function called is expected to
be threadsafe.
Signed-off-by: Amos Waterland <apw@us.ibm.com>
Signed-off-by: Jimi Xenidis <jimix@watson.ibm.com>
Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
--HG--
extra : transplant_source : %E0%1E%08%CAb%9BO%15H%28%B0%97jX%DF%87gU%8A%EC
Our problem with x86 do_IRQ is that it does not respect IRQ_PER_CPU, so
make our logic reflect that generically. We remove the spin lock in
this case, since the programming convention is to update irq descs
atomically (if at all). This patch allows read_clocks to work properly.
Signed-off-by: Amos Waterland <apw@us.ibm.com>
Signed-off-by: Jimi Xenidis <jimix@watson.ibm.com>
Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
--HG--
extra : transplant_source : %1E%1Ac%40%81%29%BE%A2%D8%7FH%5CR%F1%BE%21%AD%A3_%F0
domains_lock. This makes the VM.start call blocking, but allows xm list to
work while it is blocked. Move the handling of start_paused out of
XendDomainInfo.start as part of this.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
unpause the VM on start by default. This should fix problems seen recently
whereby devices are not attached to the VM by the time they boot, as
xm create was expecting to be able to wait for the devices before unpausing.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
targets, because it introduces an additional dependency (libcurl), but
make test/test_bindings does the right thing.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
for the RSDP in memory (up to the BIOS) rather than calculating its
start address. Recent changes seem to have moved the RSDP to another
location in memory so that I received 'BAD RSPD signature' messages.
I have also fixed some other possible issues related to return codes
and alignment of ACPI entries.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
While the kernel side of blktap drivers is using 64-bit sector numbers
correctly when reporting disk sizing, the userspace parts where this
dat is actually generated is truncating at 32-bit. There are 3 variables
related to disk sizing which are used in the kernel/userspace code
'size', 'sector size' & 'info'. In kernel space these are treated as being
unsigned long long, unsigned long, and unsigned int, respectively. In
the blktap userspace code this were all varyingly long, unsigned long.
This mismatch caused 32-bit wraparound on large disks. The attached
patch updates the blktap userspace to use the same data types as
kernel space for all these params, thus both fixing the 32-bit bug &
giving the code consistency.
This patch has been tested both by comparing /proc/partitions in the
guest, with the image size seen in the host, and by using Stephen
Tweedie's 'verify-data' tool on a variety of multi-TB sized disks.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The default config read/write handlers allows a 4-byte read/write at
address 255. This can clobber the field after the config area. This
happens to be the PCIBus pointer in the PCIDevice structure.
This patch stops this from reducing the read/write to the (largest
multiple of 2) number of bytes within the config area.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
this handled by a new message (xend.domains_with_state) and make xend.domains
equivalent to xend.domains_with_state(running). This restores the Xen 3.0.3
semantics of xend.domains.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
