In xm start the --vncviewer option has no effect, instead -c tries to
both connect to the console and start vncviewer. Additionally, to
start vncviewer it uses the domid variable which is only defined a few
lines later. Thus xm start -c doesn't work at all.
This patch fixes both problems.
Signed-off-by: Kevin Wolf <kwolf@suse.de>
guest_physmap_add_entry() checks to see if the given mfn and gpfn
range in the p2m and m2p tables is already mapped before overwriting
the maps, and attempts to do something reasonable so that we don't
have any "dangling" pointers.
Unfortunately, these checks got broken when the page_order argument
was added. Each individual p2m and m2p entry needs to be checked, not
just the first page in a page order.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
The barrier is required to prevent the WRMSR from executing before the
processor has written synchronising data to be received by remote
CPUs.
At the same time remove needless wmb() from on_selected_cpus(). We now
assume send_IPI_mask() is a sufficient compiler and CPU memory
barrier.
Original patch by Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
Per-domain irq mappings are now protected by d->evtchn_lock and by the
per-vector irq_desc lock.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
Since Linux started to use one of the 3 low available bits, _PAGE_IO
needed to be moved to a different one. Not remembering about
_PAGE_GNTTAB in debug hypervisors, I ended up assigning it to the same
bit, which made the kernel fail on the debug hypervisor. However,
rather than fixing the kernel it seems more appropriate for the
hypervisor to stay away from these bits, not the least because its
definition was anyway accompanied by a warning that this may be
incompatible with certain OSes.
While obviously the hypervisor has to use some bit (and it's therefore
unavoidable that there's some risk of collision), using one of the
high available bits seems to be the better choice over using one of
the three low ones. Since in 32-bit mode these bits are reserved, the
patch disables the functionality here. The only reasonable alternative
I would see is to disable the functionality by default, but add a
command line option to specify which bit to use.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
XENLOG_G_* should not be used in invocations of gdprintk().
Also change the wording in a few places and consistently print the
target domain. It remains questionable whether the code should be this
verbose in the first place, especially now that MSI is on by default.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
... as this is rather wasteful when Xen is configured to support many
CPUs but is running on systems having only a few.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
XEN_DOMCTL_setvcpucontext, XEN_DOMCTL_max_vcpus, and
XEN_DOMCTL_setdebugging don't seem to allow Dom0 as the subject domain
(based on the criteria that they pause that domain in order to do
their job).
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
This mainly means removing stack variables that (should) depend on
NR_CPUS (other than cpumask_t ones) and adjusting certain array sizes.
There's at least one open tools issue: The 'xm vcpu-pin' path assumes
a maximum of 64 CPU-s in many places.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
As a follow-up to the per-CPU-GDT patch, this also makes the double
fault TSS (and the associated stack) per-CPU.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
The major issue with supporting a significantly larger number of
physical CPUs appears to be the use of per-CPU GDT entries - at
present, x86-64 could support only up to 126 CPUs (with code changes
to also use the top-most GDT page, that would be 254). Instead of
trying to go with incremental steps here, by converting the GDT itself
to be per-CPU, limitations in that respect go away entirely.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
ACPI C2 is quite possible mapped to CPU C3 or deeper state, so
thinking from worst cases, enable C3 like entry/exit handling for C2
by default. Option 'lapic_timer_c2_ok' can be used to select simple C2
entry/exit only if the user make sure that LAPIC tmr & TSC will not be
stop during C2.
Signed-off-by: Wei Gang <gang.wei@intel.com>
There may be multiple ACPI C3 states reported by BIOS. Those C3 states
may be different on latency & power. So made some modification to
support this case.
Signed-off-by: Wei Gang <gang.wei@intel.com>
This patch will make xm return a exit code of 3 if `xm list
<non_existant_domain>` is done rather than the generic code of 1. I
used 3 because XendClient had a macro setup pointing
ERROR_INVALID_DOMAIN to 3.
From: "Shaun R." <mailinglists@unix-scripts.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
Add a missing CPUID leaf that contains AMD-specific cache info.
Without this, Windows can spin trying to prefetch memory buffers using
a stride length of zero.
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
xc_interface_open() may return -1, but if we define xc_fd as unsigned
int, then -1 will be > 0.
Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
Without this patch, vncviewer processes remain as follows.
This patch fixes it.
> # pgrep -fl vnc
> 4303 vncviewer -log *:stdout:0 -listen 5501
> 5089 vncviewer -log *:stdout:0 -listen 5502
> 5763 vncviewer -log *:stdout:0 -listen 5503
details:
Since 21dd1fdb73d8 there have been (as far as I can see) three
separate mechanisms for achieving a VNC display:
1. xm spawns vncviewer after getting vnc display info
from qemu-dm via xenstore (introduced in 21dd1fdb73d8)
2. xm spawns vncviewer -listen and qemu-dm connects to it
3. qemu-dm spawns vncviewer (!)
The latter two are rather strange - No.3 is very strange indeed.
So I decided that rather than try to get No.2 or No.3 on track for
going into qemu upstream, No.2 and No.3 would be dropped.
After discussion on xen-devel the mechanism No.1 was introduced,
above.
No.1 is controlled by the --spawn-vncviewer (and --vncviewer-autopass)
command line options to xm, by analogy with the -c option.
Nos.2 and 3 are controlled by elements of the domain configuration
file - and their code still remains. So if you turn all of the vnc
options on you can get several vncviewers (although only one of them
will work).
This patch removes the support for the passive connection mode No.2
After all ioemu-remote will never connect to such a vncviewer.
The options to engage this functionality were already removed from
the example config files by Keir in 18241:bf4ef45e6a38.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Adding some missing posix function declarations, to get rid of some
qemu-remote compile time warnings.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
... which currently means:
- The 1:1 map cannot deal with more than 1Tb.
- The m2p table can handle at most 8Tb.
- The page_info array can cover up to e.g. 1.6Gb (<=3D 64 CPUs) or
1Tb (193-256 CPUs).
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Just like for the Intel/ACPI cpufreq code, powernow's dom_mask also
must not be confined to the number of CPUs in the system.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
explicitly-named MSRs (but keep the names in the source code in case
we tighten up RDMSR emulation later).
Also add MSR_AMD_PATCHLEVEL MSR as explicitly required (for Solaris).
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
Replace the stubdom/ioemu link farm creation in stubdom/Makefile,
with code which arranges that:
* No symlinks are made for output files - in particular, any
symlinks for .d files would be written through by the compiler
and cause damage to the original tree and other strange
behaviours
* All subdirectories are made as local subdirectories rather than
links
* Any interrupted or half-completed creation of the link farm
leaves the directory in a state where the link farming will be
restarted
* We use make's inherent ability to test for the existence of files
rather than using [ -f ... ] at the start of the rule's commands
* The list of files to be excluded from the link farm can be
easily updated
etc.
This should fix some problems particularly with parallel builds,
or by-hand builds where directories are entered in other than the
usual order.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Keir Fraser
Isaku Yamahata