On Sat, Jan 21, 2017 at 09:43:19AM +0800, Baoquan He wrote:
> Hi,
>
> I don't strongly oppose against this, but could you tell what you have
> met makes the kexec_loaded/kexec_crash_loaded checking not convenient to
> you?
kexec_loaded/kexec_crash_loaded exposes Linux kernel kexec/crash state.
It
On 01/23/17 at 09:34am, Daniel Kiper wrote:
> On Sat, Jan 21, 2017 at 09:43:19AM +0800, Baoquan He wrote:
> > Hi,
> >
> > I don't strongly oppose against this, but could you tell what you have
> > met makes the kexec_loaded/kexec_crash_loaded checking not convenient to
> > you?
>
> kexec_loaded/ke
> -Original Message-
> From: Andrew Cooper
> Sent: 20 January 2017 18:34
> To: Paul Durrant ; xen-de...@lists.xenproject.org
> Cc: Daniel De Graaf ; Ian Jackson
>
> Subject: Re: [PATCH v4 7/8] dm_op: convert HVMOP_inject_trap and
> HVMOP_inject_msi
>
> On 17/01/17 17:29, Paul Durrant wrot
> -Original Message-
> From: Andrew Cooper
> Sent: 20 January 2017 18:28
> To: Paul Durrant ; xen-de...@lists.xenproject.org
> Cc: Ian Jackson ; Daniel De Graaf
>
> Subject: Re: [PATCH v4 6/8] dm_op: convert HVMOP_set_mem_type
>
> On 17/01/17 17:29, Paul Durrant wrote:
> > diff --git a/xe
On 20/01/2017 15:02, Paul Durrant wrote:
>
>>> +if ( !rc &&
>>> + !copy_buf_to_guest(bufs, nr_bufs, 0, &op, sizeof(op)) )
>> Do all ops need a copyback? If they do, this is fine. If not, it would
>> be better to have a copyback boolean which subops set as necessary.
> I can restrict c
> -Original Message-
> From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of
> Andrew Cooper
> Sent: 23 January 2017 09:15
> To: Paul Durrant ; xen-de...@lists.xenproject.org
> Cc: Ian Jackson ; Jennifer Herbert
> ; Daniel De Graaf ;
> Wei Liu ; Jan Beulich
> Subject: Re: [PATCH
The information given in the xl man page for the mem-max command is
rather brief. Expand it in order to let the reader understand what it
is really doing.
As the related libxl function libxl_domain_setmaxmem() isn't much
clearer add a comment to it explaining the desired semantics.
Signed-off-by:
Block backends defined with -drive if=ide are meant to be picked up by
machine initialization code: a suitable frontend gets created and
wired up automatically.
if=ide drives not picked up that way can still be used with -device as
if they had if=none, but that's unclean and best avoided. Unused
flight 104599 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104599/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 104572
test-amd64-i386-xl-qemut-wi
...as a set of hypercalls to be used by a device model.
As stated in the new docs/designs/dm_op.markdown:
"The aim of DMOP is to prevent a compromised device model from
compromising domains other then the one it is associated with. (And is
therefore likely already compromised)."
See that file fo
... HVMOP_set_pci_link_route
These HVMOPs were exposed to guests so their definitions need to be
preserved for compatibility. This patch therefore updates
__XEN_LATEST_INTERFACE_VERSION__ to 0x00040900 and makes the HVMOP
defintions conditional on __XEN_INTERFACE_VERSION__ less than that value.
N
This patch removes the need for handling HVMOP restarts, so that
infrastructure is removed.
NOTE: This patch also modifies the type of the 'nr' argument of
xc_hvm_set_mem_type() from uint64_t to uint32_t. In practice the
value passed was always truncated to 32 bits.
Suggested-by: Jan
NOTE: This patch also modifies the types of the 'vector', 'type' and
'insn_len' arguments of xc_hvm_inject_trap() from uint32_t to
uint8_t. In practice the values passed were always truncated to
8 bits.
Suggested-by: Jan Beulich
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beul
This patch introduces code to handle DMOP continuations.
NOTE: This patch also modifies the type of the 'nr' argument of
xc_hvm_modified_memory() from uint64_t to uint32_t. In practice the
value passed was always truncated to 32 bits.
Suggested-by: Jan Beulich
Signed-off-by: Paul Dur
The handle type passed to the underlying shadow and hap functions is
changed for compatibility with the new hypercall buffer.
NOTE: This patch also modifies the type of the 'nr' parameter of
xc_hvm_track_dirty_vram() from uint64_t to uint32_t. In practice
the value passed was always tr
The definitions of HVM_IOREQSRV_BUFIOREQ_* have to persist as they are
already in use by callers of the libxc interface.
Suggested-by: Jan Beulich
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
Acked-by: Wei Liu
Acked-by: Daniel De Graaf
Reviewed-by: Andrew Cooper
--
Cc: Ian Jackson
Since injection works on a remote vCPU, and since there's no
enforcement of the subject vCPU being paused, there's a potential race
between the producing and consuming sides. Fix this by leveraging the
vector field as synchronization variable.
Signed-off-by: Jan Beulich
[re-based]
Signed-off-by:
Following on from the design submitted by Jennifer Herbert to the list [1]
this series provides an implementation of __HYPERCALL_dm_op followed by
patches based on Jan Beulich's previous HVMCTL series [2] to convert
tools-only HVMOPs used by device models to DMOPs.
[1] https://lists.xenproject.org
Today a Xenstore watch event is delivered via a callback function
declared as:
void (*callback)(struct xenbus_watch *,
const char **vec, unsigned int len);
As all watch events only ever come with two parameters (path and token)
changing the prototype to:
void (*callback)(struct
The xenbus driver has an awful mixture of internally and globally
visible headers: some of the internally used only stuff is defined in
the global header include/xen/xenbus.h while some stuff defined in
internal headers is used by other drivers, too.
Clean this up by moving the externally used sym
Handling of multiple concurrent Xenstore accesses through xenbus driver
either from the kernel or user land is rather lame today: xenbus is
capable to have one access active only at one point of time.
Rewrite xenbus to handle multiple requests concurrently by making use
of the request id of the Xe
The xenbus driver used for communication with Xenstore (all kernel
accesses to Xenstore and in case of Xenstore living in another domain
all accesses of the local domain to Xenstore) is rather simple
especially regarding multiple concurrent accesses: they are just being
serialized in spite of Xenst
This run is configured for baseline tests only.
flight 68419 xen-4.5-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68419/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops
Properly inform the compiler about fic's role as both an input (its
insn_bytes field) and output (its exn_raised field).
Take the opportunity and bring emulate_fpu_insn_stub() more in line
with emulate_fpu_insn_stub_eflags().
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate
Using MOVUPS on an 8-byte quantity is wrong. There's no need for memory
accesses in any of the probe_*() functions anyway - switch them all to
insns without any operands or with register ones.
Signed-off-by: Jan Beulich
--- a/tests/fpu-exception-emulation/main.c
+++ b/tests/fpu-exception-emulati
>>> On 22.01.17 at 05:35, wrote:
> Yes, I asked Chao to add some debug info in that case. The problem now
> is when we will reproduce the bug to see meaningful hint...
If written reasonably, feel free to submit the patch for considering to
put it into staging for a while. The bigger problem is th
>>> On 22.01.17 at 19:39, wrote:
> On 01/18/2017 08:25 AM, Jan Beulich wrote:
> On 18.01.17 at 12:54, wrote:
>>> So, would it be fine to start a PVH Dom0 with as many vCPUs as what's
>>> returned
>>> from dom0_max_vcpus, and mark them as enabled in the MADT. That's basically
>>> all
>>> we
On Fri, Jan 20, 2017 at 02:53:34PM -0800, Stefano Stabellini wrote:
> On Fri, 20 Jan 2017, Roger Pau Monné wrote:
> > > > > So you need DOM0 to tell the list of regions.
> > > >
> > > > Yes, I agree that we need such hypercall ATM, although I think that we
> > > > might be
> > > > able to get rid
On 23/01/17 10:30, Jan Beulich wrote:
> Using MOVUPS on an 8-byte quantity is wrong. There's no need for memory
> accesses in any of the probe_*() functions anyway - switch them all to
> insns without any operands or with register ones.
>
> Signed-off-by: Jan Beulich
So it is.
The memory pointer
On 23/01/17 10:45, Andrew Cooper wrote:
> On 23/01/17 10:30, Jan Beulich wrote:
>> Using MOVUPS on an 8-byte quantity is wrong. There's no need for memory
>> accesses in any of the probe_*() functions anyway - switch them all to
>> insns without any operands or with register ones.
>>
>> Signed-off-
On January 20, 2017 5:09 PM, Quan Xu wrote:
>btw, for PIR.. I find that there might be a bug in
>__vmx_deliver_posted_interrupt()...
>why test_and_set_bit(VCPU_KICK_SOFTIRQ, &softirq_pending(cpu)) ??
>
>static void __vmx_deliver_posted_interrupt(struct vcpu *v) { ...
>if ( !test_and_set_bit
On 23/01/17 10:00, Paul Durrant wrote:
> diff --git a/xen/include/public/hvm/dm_op.h b/xen/include/public/hvm/dm_op.h
> new file mode 100644
> index 000..9f3e9ee
> --- /dev/null
> +++ b/xen/include/public/hvm/dm_op.h
> @@ -0,0 +1,69 @@
> +/*
> + * Copyright (c) 2016, Citrix Systems Inc
> + *
>
>>> On 23.01.17 at 11:51, wrote:
> On 23/01/17 10:45, Andrew Cooper wrote:
>> On 23/01/17 10:30, Jan Beulich wrote:
>>> Using MOVUPS on an 8-byte quantity is wrong. There's no need for memory
>>> accesses in any of the probe_*() functions anyway - switch them all to
>>> insns without any operands
>>> On 20.01.17 at 20:41, wrote:
> On 19/01/17 17:29, Roger Pau Monne wrote:
>> +tss = map_domain_gfn(p2m_get_hostp2m(d), _gfn(PFN_DOWN(gaddr)),
>> + &mfn, &p2mt, 0, &rc);
>> +if ( tss == NULL )
>> +{
>> +printk("Unable to map VM86 TSS area\n");
>> +
On Wed, Jan 4, 2017 at 2:48 PM, George Dunlap wrote:
> On Wed, Jan 4, 2017 at 1:16 PM, Jan Beulich wrote:
> On 04.01.17 at 13:36, wrote:
>>> 4. The security team will only issue an advisory if there is a known
>>> combination of software in which the vulnerability can be exploited.
>>>
>>> I
>>> On 20.01.17 at 20:21, wrote:
> James Bulpin writes ("Re: [Xen-devel] Possible improvement to Xen Security
> Response Process"):
>> , and the issue is considered to be of significant urgency due
>> to its severity, then the fourth Tuesday in the month should be
>> considered so long as this al
flight 104601 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104601/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 5 kernel-build fail REGR. vs. 59254
Regressions which a
XS_RESTRICT and the xenstore library function xs_restrict() have never
been usable in all configurations and there are no known users.
This functionality was thought to limit access rights of device models
to xenstore in order to avoid affecting other domains in case of a
security breech. Unfortun
On 23/01/17 11:09, Jan Beulich wrote:
On 23.01.17 at 11:51, wrote:
>> On 23/01/17 10:45, Andrew Cooper wrote:
>>> On 23/01/17 10:30, Jan Beulich wrote:
Using MOVUPS on an 8-byte quantity is wrong. There's no need for memory
accesses in any of the probe_*() functions anyway - switch
>>> On 23.01.17 at 12:27, wrote:
> On Wed, Jan 4, 2017 at 2:48 PM, George Dunlap
> wrote:
>> On Wed, Jan 4, 2017 at 1:16 PM, Jan Beulich wrote:
>> On 04.01.17 at 13:36, wrote:
4. The security team will only issue an advisory if there is a known
combination of software in which th
On 23/01/17 10:28, Jan Beulich wrote:
> Properly inform the compiler about fic's role as both an input (its
> insn_bytes field) and output (its exn_raised field).
>
> Take the opportunity and bring emulate_fpu_insn_stub() more in line
> with emulate_fpu_insn_stub_eflags().
>
> Signed-off-by: Jan Be
> -Original Message-
> From: Andrew Cooper
> Sent: 23 January 2017 11:06
> To: Paul Durrant ; xen-de...@lists.xenproject.org
> Cc: Ian Jackson ; Jennifer Herbert
> ; Jan Beulich
> Subject: Re: [PATCH v6 1/8] public / x86: Introduce __HYPERCALL_dm_op...
>
> On 23/01/17 10:00, Paul Durrant
On Mon, Jan 23, 2017 at 12:32:55PM +0100, Juergen Gross wrote:
> XS_RESTRICT and the xenstore library function xs_restrict() have never
> been usable in all configurations and there are no known users.
>
> This functionality was thought to limit access rights of device models
> to xenstore in orde
Ian Jackson writes ("Re: [Xen-devel] [linux-linus test] 104237: regressions -
FAIL"):
> I'm inclined to increasing the timeout, although this slowness does
> mean that our tests may be blocked more than we would like.
I have set the host property which I think will cause the timeout to
be increas
On Fri, Jan 20, 2017 at 06:41:21PM +, Andrew Cooper wrote:
> On 19/01/17 17:29, Roger Pau Monne wrote:
> > @@ -3768,7 +3770,9 @@ static long hvm_physdev_op(int cmd,
> > XEN_GUEST_HANDLE_PARAM(void) arg)
> > case PHYSDEVOP_eoi:
> > case PHYSDEVOP_irq_status_query:
> > case PHYSDE
On 23/01/17 13:14, Wei Liu wrote:
> On Mon, Jan 23, 2017 at 12:32:55PM +0100, Juergen Gross wrote:
>> XS_RESTRICT and the xenstore library function xs_restrict() have never
>> been usable in all configurations and there are no known users.
>>
>> This functionality was thought to limit access rights
On Mon, Jan 23, 2017 at 01:34:21PM +0100, Juergen Gross wrote:
> On 23/01/17 13:14, Wei Liu wrote:
> > On Mon, Jan 23, 2017 at 12:32:55PM +0100, Juergen Gross wrote:
> >> XS_RESTRICT and the xenstore library function xs_restrict() have never
> >> been usable in all configurations and there are no k
flight 104603 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104603/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7cf59c854f35c9680965fe83e9cfd863079ddd73
baseline version:
ovmf f3fa35a00233b6f2e7653
On Fri, Jan 20, 2017 at 07:03:10PM +, Andrew Cooper wrote:
> On 19/01/17 17:29, Roger Pau Monne wrote:
> > diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> > index 0ccef1d..f52f269 100644
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -1545,6 +1545,15 @@ void __i
On 23/01/17 12:58, Roger Pau Monne wrote:
> On Fri, Jan 20, 2017 at 07:03:10PM +, Andrew Cooper wrote:
>> On 19/01/17 17:29, Roger Pau Monne wrote:
>>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
>>> index 0ccef1d..f52f269 100644
>>> --- a/xen/arch/x86/setup.c
>>> +++ b/xen/arch/x8
On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote:
> On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote:
> > On 1/19/17 8:34 PM, Daniel Kiper wrote:
> > > Hi,
> > >
> > > I am sending twelfth version of multiboot2 protocol support for
> > > legacy BIOS and EFI platforms. This
On Fri, Jan 20, 2017 at 07:45:35PM +, Andrew Cooper wrote:
> On 19/01/17 17:29, Roger Pau Monne wrote:
> > @@ -3172,9 +3173,9 @@ static enum hvm_copy_result __hvm_copy(
> > {
> > static unsigned long lastpage;
> > if ( xchg(&lastpage, gfn) != gfn )
... as they're different from SSE and FPU ones.
Signed-off-by: Jan Beulich
--- a/include/arch/x86/cpuid.h
+++ b/include/arch/x86/cpuid.h
@@ -75,6 +75,7 @@ static inline bool cpu_has(unsigned int
#define cpu_has_smx cpu_has(X86_FEATURE_SMX)
#define cpu_has_pcidcpu_has(X8
Following on from the design submitted by Jennifer Herbert to the list [1]
this series provides an implementation of __HYPERCALL_dm_op followed by
patches based on Jan Beulich's previous HVMCTL series [2] to convert
tools-only HVMOPs used by device models to DMOPs.
[1] https://lists.xenproject.org
Since injection works on a remote vCPU, and since there's no
enforcement of the subject vCPU being paused, there's a potential race
between the producing and consuming sides. Fix this by leveraging the
vector field as synchronization variable.
Signed-off-by: Jan Beulich
[re-based]
Signed-off-by:
NOTE: This patch also modifies the types of the 'vector', 'type' and
'insn_len' arguments of xc_hvm_inject_trap() from uint32_t to
uint8_t. In practice the values passed were always truncated to
8 bits.
Suggested-by: Jan Beulich
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beul
... HVMOP_set_pci_link_route
These HVMOPs were exposed to guests so their definitions need to be
preserved for compatibility. This patch therefore updates
__XEN_LATEST_INTERFACE_VERSION__ to 0x00040900 and makes the HVMOP
defintions conditional on __XEN_INTERFACE_VERSION__ less than that value.
N
The definitions of HVM_IOREQSRV_BUFIOREQ_* have to persist as they are
already in use by callers of the libxc interface.
Suggested-by: Jan Beulich
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
Acked-by: Wei Liu
Acked-by: Daniel De Graaf
Reviewed-by: Andrew Cooper
--
Cc: Ian Jackson
The handle type passed to the underlying shadow and hap functions is
changed for compatibility with the new hypercall buffer.
NOTE: This patch also modifies the type of the 'nr' parameter of
xc_hvm_track_dirty_vram() from uint64_t to uint32_t. In practice
the value passed was always tr
This patch removes the need for handling HVMOP restarts, so that
infrastructure is removed.
NOTE: This patch also modifies the type of the 'nr' argument of
xc_hvm_set_mem_type() from uint64_t to uint32_t. In practice the
value passed was always truncated to 32 bits.
Suggested-by: Jan
...as a set of hypercalls to be used by a device model.
As stated in the new docs/designs/dm_op.markdown:
"The aim of DMOP is to prevent a compromised device model from
compromising domains other then the one it is associated with. (And is
therefore likely already compromised)."
See that file fo
This patch introduces code to handle DMOP continuations.
NOTE: This patch also modifies the type of the 'nr' argument of
xc_hvm_modified_memory() from uint64_t to uint32_t. In practice the
value passed was always truncated to 32 bits.
Suggested-by: Jan Beulich
Signed-off-by: Paul Dur
flight 104606 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104606/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 7e1bc8009286dcf505a1be3587d8d8388d8ab95d
baseline version:
xtf ee3e2656886a3bfdee19c7
>
> +static int __init modify_identity_mmio(struct domain *d, unsigned long pfn,
> + unsigned long nr_pages, bool map)
> +{
> +int rc;
> +
> +for ( ; ; )
> +{
> +rc = (map ? map_mmio_regions : unmap_mmio_regions)
This can be taken outsid
On 01/23/2017 05:35 AM, Jan Beulich wrote:
On 22.01.17 at 19:39, wrote:
>> On 01/18/2017 08:25 AM, Jan Beulich wrote:
>> On 18.01.17 at 12:54, wrote:
So, would it be fine to start a PVH Dom0 with as many vCPUs as what's
returned
from dom0_max_vcpus, and mark them as enabl
On Mon, Jan 23, 2017 at 02:08:58PM +0100, Daniel Kiper wrote:
> On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote:
> > On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote:
> > > On 1/19/17 8:34 PM, Daniel Kiper wrote:
> > > > Hi,
> > > >
> > > > I am sending twelfth version of
On 01/23/2017 07:16 AM, Ian Jackson wrote:
> Ian Jackson writes ("Re: [Xen-devel] [linux-linus test] 104237: regressions -
> FAIL"):
>> I'm inclined to increasing the timeout, although this slowness does
>> mean that our tests may be blocked more than we would like.
> I have set the host property
Intel reserve eax and ebx, while AMD duplicates eax from the low
family/model/stepping leaf. For AMD, ebx contains further brand/package
information which is left as the toolstack chooses (other than bits 27:16
which are reserved).
While moving the dynamic adjustments from the legacy path, simpli
With accurate vendor information available, the shared bits can be sorted out
during recalculation, rather than at query time in the legacy cpuid path.
This means that:
* Duplication can be dropped from the automatically generated cpuid data.
* The toolstack need not worry about setting them app
Leaf 0x8009 is reserved.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
v2:
* New
---
xen/arch/x86/cpuid.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 4d48552..a8dce40 100644
--- a/xen/arch/x86/cpuid.c
+++
The entirety of edx is reserved.
Intel only defines the lower 16 bits of eax, although ebx is covered by the
featureset ABI, so left unclobbered.
AMD uses 24 bits in eax, although nothing thus far has ever exposed a non-zero
guest maxphysaddr to HVM guests. ecx contains some reserved bits, and s
Leaf 0x8005 contains L1 cache/TLB information, 0x8006 L2 & L3
cache/TLB information, and 0x8007 Power management information.
Intel reserves all of this information other than the L2 cache information,
and the ITSC bit from the power management leaf.
AMD passes all of the cache/TLB in
The series has been extended substantially, and now handles the entire extd
union in the guest_cpuid() path.
Andrew Cooper (14):
x86/cpufeatures: Expose self-snoop to all guests
x86/cpuid: Handle leaf 0x8000 in guest_cpuid()
x86/cpuid: Only recalculate the shared feature bits once
x86/
Self-snoop describes a property of the CPU cache behaviour, which FreeBSD uses
to optimise its cache flushing algorithm.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
v2:
* New
---
xen/include/public/arch-x86/cpufeatureset.h | 1 +
1 file changed, 1 insertion(+)
diff
Intel now document leaf 2 as a plain leaf, with %al always containing the
value 0x01. Collect this leaf normally in calculate_raw_policy() and expose
it to guests. The leaf is reserved by AMD.
Intel leaves 3 and 9 (PSN and DCA respectively) are not exposed to guests at
all. They are reserved by
Leaves 0x8002 through 0x8004 are plain ASCII text, and are left
exactly as the toolstack chooses.
Signed-off-by: Andrew Cooper
Reviewed-by: Doug Goldstein
Reviewed-by: Jan Beulich
---
v2:
* Rebased, but no significant changes
---
xen/arch/x86/cpuid.c | 6 +++---
1 file changed, 3 inse
The calculations for p->extd.max_leaf are reworked to force a value of at
least 0x8000, and to take the domains chosen vendor into account when
clamping maximum value.
The high short vendor information is clobbered or duplicated according to the
chosen vendor.
As a side effect of handing out
On Thu, Jan 19, 2017 at 8:08 AM, Juergen Gross wrote:
> On 17/01/17 18:26, Dario Faggioli wrote:
>> In fact, relying on the mask of what pCPUs belong to
>> which Credit2 runqueue is not enough. If we only do that,
>> when Credit2 is the boot scheduler, we may ASSERT() or
>> panic when moving a pCP
On 16/01/17 11:17, Andrew Cooper wrote:
> If the hardware supports faulting, and the guest has chosen to use it, leave
> faulting active in HVM context.
>
> It is more efficient to have hardware convert CPUID to a #GP fault (which we
> don't intercept), than to take a VMExit and have Xen re-inject
flight 104604 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104604/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a
test-armhf-armhf-libvirt
On Mon, Jan 23, 2017 at 09:11:06AM -0500, Boris Ostrovsky wrote:
>
> >
> > +static int __init modify_identity_mmio(struct domain *d, unsigned long pfn,
> > + unsigned long nr_pages, bool map)
> > +{
> > +int rc;
> > +
> > +for ( ; ; )
> > +{
> >
Leaf 0x800a contains SVM information. The feature choices are borrowed
straight from the libxc policy code.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
v2:
* New
---
xen/arch/x86/cpuid.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/
Leaves 800b-18 are reserved. Leaf 8019 is 1G TLB information and leaf
0x801a is performance hints. These leaves have previously been hidden
from guests, but are perfectly safe to expose.
Update libxc to also expose these leaves.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC:
Leaf 0x801c contains LWP information. edx contains hardware supported
features (and is clamped against the maximum), while ecx and ebx contain
various properties of the implementation. eax is entirely dynamic, depending
on xcr0 and MSR_LWP_CFG.
The call to guest_cpuid() in svm_update_lwp_cfg
Xen advertises the IBS feature flag to guests on capable AMD hardware.
However, the PV path in Xen, and both the PV and HVM paths in libxc
deliberately clobber the IBS CPUID leaf.
Furthermore, Xen has nothing providing an implementation of the IBS MSRs, so
guests can't actually use the feature at
All leaves in the extd union are handled in guest_cpuid() now, so remove
legacy handling.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/cpuid.c| 14 +++---
xen/include/asm-x86/cpuid.h | 4 ++--
2 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/
On Mon, Jan 23, 2017 at 02:39:14PM +, Andrew Cooper wrote:
> Leaves 800b-18 are reserved. Leaf 8019 is 1G TLB information and leaf
> 0x801a is performance hints. These leaves have previously been hidden
> from guests, but are perfectly safe to expose.
>
> Update libxc to also exp
This run is configured for baseline tests only.
flight 68421 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68421/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-i3863 host-install(3) broken bas
flight 104607 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104607/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 223a99e524679a7f811755442897bfad7cf49830
baseline version:
ovmf 7cf59c854f35c9680965f
Don't truncate the "feature-persistent" value read from xenstore: Any
non-zero value is supposed to enable the feature, just like is already
being done for feature_secdiscard.
Just like the other feature_* fields, feature_flush and feature_fua are
boolean flags, and hence fit well into a single bi
>>> On 23.01.17 at 15:28, wrote:
> On 01/23/2017 05:35 AM, Jan Beulich wrote:
> On 22.01.17 at 19:39, wrote:
>>> On 01/18/2017 08:25 AM, Jan Beulich wrote:
>>> On 18.01.17 at 12:54, wrote:
> So, would it be fine to start a PVH Dom0 with as many vCPUs as what's
> returned
> f
Making use of "max_indirect_segments=" has issues:
- blkfront_setup_indirect() may end up with zero psegs when PAGE_SIZE
is sufficiently much larger than XEN_PAGE_SIZE
- the variable driven by the command line option
(xen_blkif_max_segments) has a somewhat different purpose, and hence
should
On Tue, Jan 17, 2017 at 5:26 PM, Dario Faggioli
wrote:
> In fact, relying on the mask of what pCPUs belong to
> which Credit2 runqueue is not enough. If we only do that,
> when Credit2 is the boot scheduler, we may ASSERT() or
> panic when moving a pCPU from Pool-0 to another cpupool.
>
> This is
On 1/23/17 7:08 AM, Daniel Kiper wrote:
> On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote:
>> On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote:
>>> On 1/19/17 8:34 PM, Daniel Kiper wrote:
Hi,
I am sending twelfth version of multiboot2 protocol support for
>
>> From Linux perspective one option could be to have domU with PV-style
>> vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when
>> it becomes available. This, however, will need an indication from the
>> hypervisor. We could, for example, set ACPI_FADT_HW_REDUCED, as we
>> discu
On Mon, Jan 23, 2017 at 09:35:55AM -0600, Doug Goldstein wrote:
> On 1/23/17 7:08 AM, Daniel Kiper wrote:
> > On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote:
> >> On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote:
> >>> On 1/19/17 8:34 PM, Daniel Kiper wrote:
> Hi,
>
On Tue, Jan 17, 2017 at 5:26 PM, Dario Faggioli
wrote:
> In fact, during shutdown/suspend, we temporarily move all
> the vCPUs to the BSP (i.e., pCPU 0, as of now). For Credit2
> domains, we call csched2_vcpu_migrate(), expects to find the
> target pCPU in the domain's pool
>
> Therefore, if Credi
On 01/23/2017 10:43 AM, Boris Ostrovsky wrote:
>>> From Linux perspective one option could be to have domU with PV-style
>>> vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when
>>> it becomes available. This, however, will need an indication from the
>>> hypervisor. We could, for
>>> On 23.01.17 at 16:43, wrote:
>>> From Linux perspective one option could be to have domU with PV-style
>>> vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when
>>> it becomes available. This, however, will need an indication from the
>>> hypervisor. We could, for example, set
On Tue, Jan 17, 2017 at 5:27 PM, Dario Faggioli
wrote:
> In fact, when domains are being unpaused:
> - it's not necessary to put the vcpu to sleep, as
>they are all already paused;
> - it is not necessary to call vcpu_migrate(), as
>the vcpus are still paused, and therefore won't
>wa
1 - 100 of 145 matches
Mail list logo
