Disallow the unmaintained and presumed broken translated-but-not-
external paging mode combination, allowing the respective paging hooks
to go away (which eliminates one pair of NULL callbacks in HAP mode).
As a result of them no longer being generic paging operations, make the
inline functions pri
... as they're being used for PV guests only, which don't use HAP mode.
This eliminates another pair of NULL callbacks in HAP as well as in 2-
and 3-guest-level shadow modes.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -369,15 +369,14 @
... related to 8-byte cmpxchg having required special precautions
there.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -259,10 +259,10 @@ hvm_emulate_cmpxchg(enum x86_segment seg
struct sh_emulate_ctxt *sh_ctxt =
container
El 4/2/16 a les 21:17, Boris Ostrovsky ha escrit:
> On 02/04/2016 02:21 PM, Roger Pau Monné wrote:
>> El 4/2/16 a les 19:51, Samuel Thibault ha escrit:
>>> Boris Ostrovsky, on Thu 04 Feb 2016 13:38:02 -0500, wrote:
On 02/04/2016 12:48 PM, Roger Pau Monné wrote:
> The format of the boot sta
>>> On 04.02.16 at 18:12, wrote:
> Two angles on this.
>
> First, assuming that limiting the number of ranges is what we want: I'm
> not really a fan of using HVM_PARAMs for this, but as long as it's not
> considered a public interface (i.e., it could go away or disappear and
> everything would
>>> On 05.02.16 at 04:44, wrote:
> This is why Yu mentioned earlier whether we can just set a default
> limit which is good for majority of use cases, while extending our
> device mode to drop/recreate some shadow tables upon the limitation
> is hit. I think this matches how today's CPU shadow pag
Hi Bjorn,
On Fri, Feb 5, 2016 at 5:49 AM, Bjorn Helgaas wrote:
> Hi Jayachandran,
>
> On Fri, Jan 29, 2016 at 02:35:40PM +0530, Jayachandran C wrote:
>> Add a simple ACPI based PCI host controller under config option
>> ACPI_PCI_HOST_GENERIC. This is done by providing an implementation
>> of pci_
On 2/4/2016 7:06 PM, George Dunlap wrote:
On Thu, Feb 4, 2016 at 9:38 AM, Yu, Zhang wrote:
On 2/4/2016 5:28 PM, Paul Durrant wrote:
I assume this means that the emulator can 'unshadow' GTTs (I guess on an
LRU basis) so that it can shadow new ones when the limit has been exhausted?
If so, how
On 2/5/2016 1:12 AM, George Dunlap wrote:
On 04/02/16 14:08, Jan Beulich wrote:
On 04.02.16 at 14:33, wrote:
Jan Beulich writes ("Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter
max_wp_ram_ranges."):
On 04.02.16 at 10:38, wrote:
So another question is, if value of this limit rea
On 2/5/2016 12:18 PM, Tian, Kevin wrote:
From: George Dunlap [mailto:george.dun...@citrix.com]
Sent: Friday, February 05, 2016 1:12 AM
On 04/02/16 14:08, Jan Beulich wrote:
On 04.02.16 at 14:33, wrote:
Jan Beulich writes ("Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter
max_wp_ram
>>> On 04.02.16 at 19:22, wrote:
> On 04/02/16 17:48, Roger Pau Monné wrote:
>> - HVMlite hardware domain: can we get rid of the PHYSDEV ops and PIRQ
>>event channels?
>> - HVMlite PCI-passthrough: can we get rid of pciback/pcifront?
>
> +1000, for both.
I'm a little lost here: However ni
On 2/3/2016 2:23 PM, Ian Campbell wrote:
On Wed, 2016-02-03 at 13:54 +0200, Corneliu ZUZU wrote:
I thought this mail was not sent properly (didn't find it any longer on
the web (?)) and I resent it just earlier.
I figured it must've been the fact that I forgot to put a "Changed since
v1" section
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 05 February 2016 08:33
> To: George Dunlap
> Cc: Andrew Cooper; Ian Campbell; Paul Durrant; Stefano Stabellini; Wei Liu;
> Ian Jackson; Kevin Tian; zhiyuan...@intel.com; Zhang Yu; xen-
> de...@lists.xen.org; Keir (X
I'm going to have a need for it elsewhere.
Signed-off-by: Ian Campbell
Acked-by: Ian Jackson
---
Osstest/BuildSupport.pm | 12
ts-xen-build| 13 +
2 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/Osstest/BuildSupport.pm b/Osstest/BuildSupport
This primarily consists of ts-coverity-{build,upload} and
make-coverity-flight which constructs the sole job.
The branch is named "xen-unstable-coverity" which matches various xen*
in the cr-* scripts. Places which needed special treatement are
handled by matching xen-*-coverity, which leaves the
On Fri, Feb 05, 2016 at 02:05:37PM +0530, Jayachandran Chandrashekaran Nair
wrote:
[...]
> pci_host_acpi.c is a generic implementation of these using a sysdata
> pointing to acpi_pci_root_info, and using a pointer to the pci_mmcfg_region
> to access ECAM area, Maybe I can rename this file to
> p
El 5/2/16 a les 10:12, Jan Beulich ha escrit:
On 04.02.16 at 19:22, wrote:
>> On 04/02/16 17:48, Roger Pau Monné wrote:
>>> - HVMlite hardware domain: can we get rid of the PHYSDEV ops and PIRQ
>>>event channels?
>>> - HVMlite PCI-passthrough: can we get rid of pciback/pcifront?
>>
>>
On Fri, 2016-02-05 at 08:09 +1100, Steven Haigh wrote:
> In building my Xen 4.6.0 packages, I disable qemu-traditional and ONLY
> build qemu-upstream - however as the value for i386-softmmu is not based
> on variables, I'm not sure this makes a difference.
QEMU in a Xen system only provides device
flight 38726 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38726/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-amd64-jessie-netboot-pygrub 3 host-install(3) brok
On Thu, Feb 04, Olaf Hering wrote:
> On Thu, Feb 04, Ian Campbell wrote:
>
> > I think the append_to variant is probably least gross.
>
> libxl_device_vscsidev_append_to_vscsictrl() would work too.
While looking at the MERGE macro in libxl.c, a _remove_from could be
added as well. I have not ch
On Fri, 2016-02-05 at 00:12 +, Andrew Cooper wrote:
> On 04/02/2016 23:14, Steven Haigh wrote:
> > On 2016-02-05 09:22, Andrew Cooper wrote:
> > > On 04/02/2016 22:06, Alex Braunegg wrote:
> > > Qemu is only used for device emulation when used with Xen, not CPU
> > > emulation.
I answered Stev
On 05/02/16 20:51, Ian Campbell wrote:
> On Fri, 2016-02-05 at 08:09 +1100, Steven Haigh wrote:
>> In building my Xen 4.6.0 packages, I disable qemu-traditional and ONLY
>> build qemu-upstream - however as the value for i386-softmmu is not based
>> on variables, I'm not sure this makes a difference
On Fri, 2016-02-05 at 10:55 +0100, Olaf Hering wrote:
> On Thu, Feb 04, Olaf Hering wrote:
>
> > On Thu, Feb 04, Ian Campbell wrote:
> >
> > > I think the append_to variant is probably least gross.
> >
> > libxl_device_vscsidev_append_to_vscsictrl() would work too.
>
> While looking at the MERG
On Fri, 2016-02-05 at 20:57 +1100, Steven Haigh wrote:
>
> > On thing I was sure on (so didn't write) is whether the second
> > paragraph
> > could have an extra sentence:
> >
> > If you are using a distro supplied QEMU then the qemu-system-x86_64
> > could also be used, but it makes no p
Signed-off-by: Olaf Hering
Acked-by: Ian Campbell
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Keir Fraser
Cc: Tim Deegan
---
docs/misc/xenstore-paths.markdown | 10 ++
1 file changed, 10 insertions(+)
diff --git a/docs/misc/xenstore-paths.markdown
b/docs/misc/xenstore-pat
Just to make them public, not meant for merging:
The scripts used during development to create a bunch of SCSI devices in
dom0 using the Linux target framework. targetcli3 and rtslib3 is used.
A patch is required for python-rtslib:
http://article.gmane.org/gmane.linux.scsi.target.devel/8146
Signe
Port pvscsi support from xend to libxl:
vscsi=['pdev,vdev{,options}']
xl scsi-attach
xl scsi-detach
xl scsi-list
Signed-off-by: Olaf Hering
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
docs/man/xl.cfg.pod.5| 55 +++
docs/man/xl.pod.1
The pvops kernel expects either "naa.WWN:LUN" or "h:c:t:l" in the p-dev
property. Add the missing :LUN part to the comment.
Signed-off-by: Olaf Hering
Acked-by: Ian Campbell
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Keir Fraser
Cc: Tim Deegan
---
xen/include/public/io/vscsiif.h
Port vscsi=[] and scsi-{attach,detach,list} commands from xend to libxl.
libvirt uses its existing SCSI support:
http://lists.xenproject.org/archives/html/xen-devel/2015-04/msg02963.html
targetcli/rtslib has to be aware of xen-scsiback (upstream unresponsive):
http://article.gmane.org/gmane.linux
Signed-off-by: Olaf Hering
Acked-by: Ian Campbell
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Keir Fraser
Cc: Tim Deegan
---
xen/include/public/io/vscsiif.h | 68 +
1 file changed, 68 insertions(+)
diff --git a/xen/include/public/io/vscsiif.
I have a patch in Xen which stores some information of VM process. I have
another program running in Dom0 which intercept this information.
i) I want to configure my patch running in Xen to send the alert
notification to program running in Dom0 to read data, probably using event
channels. How to c
to pass down a flag indicating whether the lock is being held,
and check the way up the call trees.
Signed-off-by: Quan Xu
---
xen/arch/x86/mm/p2m-ept.c| 3 +-
xen/drivers/passthrough/vtd/iommu.c | 73 ++--
xen/drivers/passthrough/vtd/iommu.h | 3 +
to pass down a flag indicating whether the lock is being held,
and check the way up the call trees.
Signed-off-by: Quan Xu
---
xen/arch/x86/mm.c | 9 ++---
xen/arch/x86/mm/p2m-ept.c | 7 ---
xen/arch/x86/mm/p2m-pt.c |
to pass down a flag indicating whether the lock is being held.
Signed-off-by: Quan Xu
---
xen/arch/arm/p2m.c | 2 +-
xen/common/memory.c | 4 ++--
xen/drivers/passthrough/iommu.c | 9 +
xen/drivers/passthrough/vtd/iommu.c | 5 +++--
xen/drivers/pa
This patch checks all kinds of error and all the way up
the call trees of VT-d Device-TLB flush(IOMMU part).
Signed-off-by: Quan Xu
---
xen/drivers/passthrough/amd/iommu_init.c | 4 +-
xen/drivers/passthrough/amd/pci_amd_iommu.c | 4 +-
xen/drivers/passthrough/arm/smmu.c|
If Device-TLB flush is timeout, we'll hide the target ATS
device and crash the domain owning this ATS device.
If impacted domain is hardware domain, just throw out a warning.
The hidden device will be disallowed to be further assigned to
any domain.
Signed-off-by: Quan Xu
---
xen/drivers/passt
This patch checks all kinds of error and all the way up
the call trees of VT-d Device-TLB flush(MMU part).
Signed-off-by: Quan Xu
---
xen/arch/x86/acpi/power.c | 6 +-
xen/arch/x86/crash.c| 3 ++-
xen/arch/x86/domain_build.c | 5 -
xen/arch/x86/mm.c | 10 +++---
Signed-off-by: Quan Xu
---
docs/misc/xen-command-line.markdown | 7 +++
xen/drivers/passthrough/vtd/qinval.c | 11 +--
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index a565c1b..6ed5cd8 10
This patches fix current timeout concern and also allow limited ATS support:
1. Check VT-d Device-TLB flush error.
This patch checks all kinds of error and all the way up the call trees of
VT-d Device-TLB flush.
2. Reduce spin timeout to 1ms, which can be boot-time changed with
'vtd_qi_timeo
On Thu, 2016-02-04 at 18:48 +0100, Roger Pau Monné wrote:
> Hello,
>
> I've Cced a bunch of people who have expressed interest in the HVMlite
> design/implementation,
I think "HVMlite" has now reached the point where we should start the
transition from PVH (classic) to PVH (hvmlite) naming rathe
On Fri, Feb 05, Olaf Hering wrote:
> @@ -6799,6 +7375,8 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx,
> uint32_t domid,
>
> MERGE(nic, nics, COMPARE_DEVID, {});
>
> +MERGE(vscsictrl, vscsictrls, COMPARE_VSCSI, {});
I think the actual "merge" should be like this, to copy
>>> On 04.02.16 at 19:36, wrote:
> (XEN) nvmx_handle_vmwrite 1: IO_BITMAP_A(2000)[0=]
> (XEN) nvmx_handle_vmwrite 0: IO_BITMAP_A(2000)[0=]
> (XEN) nvmx_handle_vmwrite 1: IO_BITMAP_B(2002)[0=]
> (XEN) nvmx_handle_vmwrite 2: IO_BITMAP_A(2000)[0=fff
On 04/02/16 21:04, hanji unit wrote:
> Hello, does Xen support sharing memory pages between multiple domains
> (such as as Dom0, DomU1, DomU2)? The Grant Table hypercalls seem
> limited to:
>
> IOCTL_GNTALLOC_ALLOC_GREF
> IOCTL_GNTALLOC_DEALLOC_GREF
> IOCTL_GNTALLOC_SET_UNMAP_NOTIFY
These are the
>>> On 05.02.16 at 10:50, wrote:
> For legacy PCI interrupts, we can parse the MADT inside of Xen in order
> to properly setup the lines/overwrites and inject the interrupts that
> are not handled by Xen straight into the hardware domain. This will
> require us to be able to emulate the same topol
>>> On 05.02.16 at 10:24, wrote:
> Utilizing the default server is a backwards step. GVT-g would have to use the
> old HVM_PARAM mechanism to cause it's emulator to become default. I think a
> more appropriate mechanism would be p2m_mmio_write_dm to become something
> like 'p2m_ioreq_server_wri
On Fri, Feb 05, 2016 at 09:15:52PM +1100, PREETI MISHRA wrote:
> I have a patch in Xen which stores some information of VM process. I have
> another program running in Dom0 which intercept this information.
>
I'm not sure I can parse this sentence. It's too vague for what you want
to do. For one,
flight 80434 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/80434/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail
REGR. vs. 79422
test-a
On 05/02/16 10:40, Jan Beulich wrote:
On 05.02.16 at 10:50, wrote:
>> For legacy PCI interrupts, we can parse the MADT inside of Xen in order
>> to properly setup the lines/overwrites and inject the interrupts that
>> are not handled by Xen straight into the hardware domain. This will
>> requ
On Fri, Feb 5, 2016 at 3:44 AM, Tian, Kevin wrote:
>> > So as long as the currently-in-use GTT tree contains no more than
>> > $LIMIT ranges, you can unshadow and reshadow; this will be slow, but
>> > strictly speaking correct.
>> >
>> > What do you do if the guest driver switches to a GTT such th
>>> On 05.02.16 at 12:04, wrote:
> On 05/02/16 10:40, Jan Beulich wrote:
> On 05.02.16 at 10:50, wrote:
>>> Status flag? Why don't we just say that all user-settable bits in the
>>> status register will be set to 0 (or cleared)?
>> Would be an option too.
>
> What about the ID bit, which pro
Add back xen-devel, please use "reply-all" in the future.
And please don't top-post.
On Fri, Feb 05, 2016 at 10:01:57PM +1100, PREETI MISHRA wrote:
> Thanks for the reply,
>
> actually, I have a virtual machine in which some processes are running. I
> want to analysis their behavior using VMI at
On Fri, Feb 5, 2016 at 9:24 AM, Paul Durrant wrote:
> Utilizing the default server is a backwards step. GVT-g would have to use the
> old HVM_PARAM mechanism to cause it's emulator to become default. I think a
> more appropriate mechanism would be p2m_mmio_write_dm to become something
> like 'p
BTW please check out:
http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
> -Original Message-
> From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of
> George Dunlap
> Sent: 05 February 2016 11:14
> To: Paul Durrant
> Cc: Jan Beulich; George Dunlap; Kevin Tian; Wei Liu; Ian Campbell; Andrew
> Cooper; Zhang Yu; xen-devel@lists.xen.org; Stefano Stabellin
El 5/2/16 a les 11:40, Jan Beulich ha escrit:
On 05.02.16 at 10:50, wrote:
>> For legacy PCI interrupts, we can parse the MADT inside of Xen in order
>> to properly setup the lines/overwrites and inject the interrupts that
>> are not handled by Xen straight into the hardware domain. This will
>>> On 17.01.16 at 22:58, wrote:
> Both VMX TSC scaling and SVM TSC ratio use the 64-bit TSC scaling ratio,
> but the number of fractional bits of the ratio is different between VMX
> and SVM. This patch adds the architecture code to collect the number of
> fractional bits and other related inform
>>> On 05.02.16 at 12:30, wrote:
> El 5/2/16 a les 11:40, Jan Beulich ha escrit:
> On 05.02.16 at 10:50, wrote:
>>> For legacy PCI interrupts, we can parse the MADT inside of Xen in order
>>> to properly setup the lines/overwrites and inject the interrupts that
>>> are not handled by Xen stra
El 5/2/16 a les 12:45, Jan Beulich ha escrit:
On 05.02.16 at 12:30, wrote:
>> El 5/2/16 a les 11:40, Jan Beulich ha escrit:
>> On 05.02.16 at 10:50, wrote:
For legacy PCI interrupts, we can parse the MADT inside of Xen in order
to properly setup the lines/overwrites and inject
On Fri, Feb 05, 2016 at 06:30:25AM +, osstest service owner wrote:
> flight 80469 qemu-mainline real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/80469/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-i386
This will prevent alignments from getting in the way. It's not safe to
define this memory structures using C anyway, since the ABI depends on the
bitness, while our protocol does not.
Also add a command line parameter to each module, and a reserved field in
order to have the layout aligned. Note t
>>> On 05.02.16 at 13:28, wrote:
> This will prevent alignments from getting in the way. It's not safe to
> define this memory structures using C anyway, since the ABI depends on the
> bitness, while our protocol does not.
>
> Also add a command line parameter to each module, and a reserved field
Correct two issues in the Xen pvscsi backend.
Juergen Gross (2):
xen/scsiback: correct frontend counting
xen/scsiback: avoid warnings when adding multiple LUNs to a domain
drivers/xen/xen-scsiback.c | 75 ++
1 file changed, 42 insertions(+), 33 del
When adding a new frontend to xen-scsiback don't decrement the number
of active frontends in case of no error. Not doing so results in a
failure when trying to remove the xen-pvscsi nexus even if no domain
is using it.
Signed-off-by: Juergen Gross
Cc: sta...@vger.kernel.org
---
drivers/xen/xen-s
When adding more than one LUN to a frontend a warning for a failed
assignment is issued in dom0 for each already existing LUN. Avoid this
warning.
Signed-off-by: Juergen Gross
Cc: sta...@vger.kernel.org
---
drivers/xen/xen-scsiback.c | 65 ++
1 file ch
>>> On 05.02.16 at 12:50, wrote:
> El 5/2/16 a les 12:45, Jan Beulich ha escrit:
> On 05.02.16 at 12:30, wrote:
>>> El 5/2/16 a les 11:40, Jan Beulich ha escrit:
>>> On 05.02.16 at 10:50, wrote:
> For legacy PCI interrupts, we can parse the MADT inside of Xen in order
> to proper
>>> On 17.01.16 at 22:58, wrote:
> This patch adds several functions to take multiplication, division and
> shifting involving 64-bit integers.
>
> Signed-off-by: Haozhong Zhang
> Reviewed-by: Boris Ostrovsky
> ---
> Changes in v4:
> (addressing Jan Beulich's comments)
> * Rewrite mul_u64_u64
Presented here is v2 of my work to improve cpuid levelling for guests.
This series is available in git form at:
http://xenbits.xen.org/git-http/people/andrewcoop/xen.git levelling-v2
Major changes from v1 include a rebase onto staging, reworking of the
automatic generation of cpu featureset inf
Nothing uses them.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
New in v2
---
xen/arch/x86/cpu/centaur.c | 3 ---
xen/include/asm-x86/cpufeature.h | 12 +---
2 files changed, 1 insertion(+), 14 deletions(-)
diff --git a/xen/arch/x86/cpu/centaur.c b/xen/arch/x86/cpu/centaur.
If Xen doesn't know about a feature, it is unsafe for use and should be
deliberately hidden from Xen's capabilities.
This doesn't make a practical difference yet, but will make a difference
later when the guest featuresets are seeded from the host featureset.
Signed-off-by: Andrew Cooper
---
CC:
Awkwardly, some new feature bits mean "Feature $X no longer works".
Store these inverted in a featureset.
This permits safe zero-extending of a smaller featureset as part of a
comparison, and safe reasoning (subset?, superset?, compatible? etc.)
without specific knowldge of meaning of each bit.
S
pv_cpuid() has two completely separate paths inside it depending on whether
current is dom0 or a domU. This causes unnecessary divergence, and
complicates future improvements. Take steps to undo it.
Changes:
* Create leaf and subleaf variables and use them consistently, instead of a
mix of {
This script consumes include/public/arch-x86/cpufeatureset.h and generates a
single include/asm-x86/cpuid-autogen.h containing all the processed
information.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: Ian Campbell
For all intents and purposes, new in v2. All generate
For the featureset to be a useful object, it needs a stable interpretation, a
property which is missing from the current hw_caps interface.
Additionly, introduce TSC_ADJUST, SHA, PREFETCHWT1, ITSC, EFRO and CLZERO
which will be used by later changes.
To maintain compilation, FSCAPINTS is currentl
Nothing uses it.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
New in v2
---
xen/arch/x86/cpu/amd.c | 3 +--
xen/include/asm-x86/processor.h | 1 -
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 1ac44e0..c184f57 1
Introducing an X86_FEATURE aliased value turns out to complicate automatic
processing of the feature list. Drop X86_FEATURE_3DNOW_ALT and use
X86_FEATURE_PBE, extending the comment accordingly.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
New in v2
---
xen/arch/x86/cpu/amd.c | 9
New words are:
* 0x8007.edx - Contains Invarient TSC
* 0x8008.ebx - Newly used for AMD Zen processors
In addition, replace some open-coded ITSC and EFRO manipulation.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
v2:
* Rely on ordering of generic_identify() to simplify init_amd()
>>> On 17.01.16 at 22:58, wrote:
> +u64 hvm_get_tsc_scaling_ratio(u32 gtsc_khz)
> +{
> +u64 ratio;
> +
> +if ( !hvm_tsc_scaling_supported )
> +return 0;
> +
> +/*
> + * The multiplication of the first two terms may overflow a 64-bit
> + * integer, so use mul_u64_u32_div
It is conceptually wrong to base a VM's featureset on the features visible to
the toolstack which happens to construct it.
Instead, the featureset used is either an explicit one passed by the
toolstack, or the default which Xen believes it can give to the guest.
Collect all the feature manipulati
And provide stubs for toolstack use.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: Ian Campbell
CC: Wei Liu
CC: David Scott
CC: Rob Hoes
v2:
* Rebased to use libxencall
* Improve hypercall documentation
---
tools/libxc/include/xenctrl.h | 3 ++
tools/libxc/x
This patch is best reviewed as its end result rather than as a diff, as it
rewrites almost all of the setup.
On the BSP, cpuid information is used to evaluate the potential available set
of masking MSRs, and they are unconditionally probed, filling in the
availability information and hardware defa
All of this information will be used by the toolstack to make informed
levelling decisions for VMs, and by Xen to sanity check toolstack-provided
information.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/cpuid.c| 152
xen
* Use the boot-generated pv and hvm featureset to clamp the visible features,
rather than picking and choosing at individual features. This subsumes the
static feature manipulation.
* More use of compiler-visible &'s and |'s, rather than clear,set bit.
* Remove logic which hides PSE36 out of P
This change is purely scaffolding to reduce the complexity of the following
three patches.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
v2: s/cpumasks/cpuidmasks/
---
xen/arch/x86/cpu/common.c| 6 ++
xen/include/asm-x86/cpufeature.h | 1 +
xen/include/asm-x86/processor.h | 2
APIC and XSAVE have dependent features, which also need disabling if Xen
chooses to disable a feature.
Use setup_clear_cpu_cap() rather than clear_bit(), as it takes care of
dependent features as well.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
v2: Move boolean_param() adjacent t
Use attributes to specify whether a feature is applicable to be exposed to:
1) All guests
2) HVM guests
3) HVM HAP guests
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
v2: Annotate features using a magic comment and autogeneration.
---
xen/include/public/arch-x86/cpufeatureset.h | 187 ++
When clearing a cpu cap, clear all dependent features. This avoids having a
featureset with intermediate features disabled, but leaf features enabled.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/cpu/common.c | 16
1 file changed, 16 insertions(+)
diff --
This patch is best reviewed as its end result rather than as a diff, as it
rewrites almost all of the setup.
On the BSP, cpuid information is used to evaluate the potential available set
of masking MSRs, and they are unconditionally probed, filling in the
availability information and hardware defa
And use them in preference to cpumask_defaults on context switch. HVM domains
must not be masked (to avoid interfering with cpuid calls within the guest),
so always lazily context switch to the host default.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
v2:
* s/cpumasks/cpuidmasks/
* Use
Signed-off-by: Andrew Cooper
---
CC: Ian Campbell
CC: Ian Jackson
CC: Wei Liu
New in v2
---
tools/libxc/Makefile | 9 ++
tools/libxc/include/xenctrl.h | 14
tools/libxc/xc_cpuid_x86.c| 75 +++
3 files changed, 98 insertions(+)
Later changes will cause the cpuid generation logic to seed their information
from a featureset. This patch adds the infrastructure to specify a
featureset, and will obtain the appropriate default from Xen if omitted.
Signed-off-by: Andrew Cooper
---
CC: Ian Campbell
CC: Ian Jackson
CC: Wei Li
It is unsafe to generate the guests xstate leaves from host information, as it
prevents the differences between hosts from being hidden.
Signed-off-by: Andrew Cooper
---
CC: Ian Campbell
CC: Ian Jackson
CC: Wei Liu
---
tools/libxc/xc_cpuid_x86.c | 44 ++
It is able to reports the current featuresets; both the static masks and
dynamic featuresets from Xen, or to decode an arbitrary featureset into
`/proc/cpuinfo` style strings.
Signed-off-by: Andrew Cooper
---
CC: Ian Campbell
CC: Ian Jackson
CC: Wei Liu
v2: No linking hackary
---
.gitignore
Rather than having a different local copy of some of the feature
definitions.
Modify the xc_cpuid_x86.c cpumask helpers to appropriate truncate the
new values.
Signed-off-by: Andrew Cooper
---
CC: Ian Campbell
CC: Ian Jackson
CC: Wei Liu
---
tools/libxc/xc_cpufeature.h | 147
The type of the pointer to a bitmap is not interesting; it does not affect the
representation of the block of bits being pointed to.
Make the libxc functions consistent with those in Xen, so they can work just
as well with 'unsigned int *' based bitmaps.
Signed-off-by: Andrew Cooper
---
CC: Ian
Some features depend on other features. Working out and maintaining the exact
dependency tree is complicated, so it is expressed in the automatic generation
script, and flattened for faster runtime use.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
For all intents an purposes, new in v2.
--
Before c/s 44e24f8567 "x86: don't call generic_identify() redundantly", the
commandline-provided masks would take effect in Xen's view of the features.
As the masks got applied after the query for features, the redundant call to
generic_identify() would clobber the pre-masking feature information
A single ctxt_switch_levelling() function pointer is provided
(defaulting to an empty nop), which is overridden in the appropriate
$VENDOR_init_levelling().
set_cpuid_faulting() is made private and included within
intel_ctxt_switch_levelling().
One functional change is that the faulting configura
This allows PV domains with different featuresets to observe different values
from a native cpuid instruction, on supporting hardware.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
v2:
* Use switch() rather than if/elseif chain
* Clamp to static PV featuremask
---
xen/arch/x86/dom
>>> On 19.01.16 at 03:55, wrote:
> @@ -2107,6 +2115,14 @@ const struct hvm_function_table * __init
> start_vmx(void)
> && cpu_has_vmx_secondary_exec_control )
> vmx_function_table.pvh_supported = 1;
>
> +if ( cpu_has_vmx_tsc_scaling )
> +{
> +vmx_function_tabl
On Thu, Feb 04, 2016 at 04:50:42PM -0600, Chong Li wrote:
> Add xc_sched_rtds_vcpu_get/set functions to interact with
> Xen to get/set a domain's per-VCPU parameters.
>
> Signed-off-by: Chong Li
> Signed-off-by: Meng Xu
> Signed-off-by: Sisu Xi
These looks like sensible wrappers. I will defer
1 - 100 of 219 matches
Mail list logo
