flight 124911 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124911/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-cubietruckbroken in 124874
build-i386-libvirt
On 04/07/18 04:23, Chenjia (C) wrote:
> Dear Jan:
>
> In a xen 4.8.2 server, We got this information, could
> you please help us to see what the problem maybe?(the crashed service
> only record this information, we can only see the following information)
This is a Linux problem.
flight 124935 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124935/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd broken
Dear Jan:
In a xen 4.8.2 server, We got this information, could you
please help us to see what the problem maybe?(the crashed service only record
this information, we can only see the following information) Thankyou!
[cid:image002.png@01D41380.4F7CD630]
BestRegards
发件人: Chenjia
flight 124907 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124907/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 124389
Tests which did not
flight 124902 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124902/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt broken in 124870
Hi Edgar,
Yes, we certainly don't want the xl parser in the hypervisor. We only
need a minimal subset of options. We do already have a device tree
parser that understands cells. We also have a parser for a set of
command line options, some of them similar to the VM options we need to
pass. I
On Tue, 3 Jul 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 02/07/18 22:31, Stefano Stabellini wrote:
> > On Thu, 14 Jun 2018, Julien Grall wrote:
> > > On 13/06/18 23:15, Stefano Stabellini wrote:
> > > > +
> > > > +- cpus (optional)
> > > > +
> > > > +A string specifying the number of
flight 74931 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74931/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-i386-weekly-netinst-pygrub 10 debian-di-install fail blocked
in 74910
On Tue, 3 Jul 2018, Julien Grall wrote:
> Hi,
>
> On 02/07/18 22:38, Stefano Stabellini wrote:
> > On Mon, 2 Jul 2018, Julien Grall wrote:
> > > Hi,
> > >
> > > On 02/07/2018 21:37, Stefano Stabellini wrote:
> > > > On Fri, 15 Jun 2018, Julien Grall wrote:
> > > > > Hi Stefano,
> > > > >
> > >
From: Sergey Dyasli
This hypercall allows the toolstack to present one combined CPUID and MSR
policy for a domain, which can be audited in one go by Xen, which is necessary
for correctness of the auditing.
A stub x86_policies_are_compatible() function is introduced, although at
present it will
As with the serialise side, Xen's copy_from_guest API is used, with a
compatibility wrapper for the userspace build.
Signed-off-by: Andrew Cooper
Signed-off-by: Sergey Dyasli
Signed-off-by: Roger Pau Monné
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Sergey Dyasli
CC: Ian
From: Roger Pau Monné
Signed-off-by: Sergey Dyasli
Signed-off-by: Roger Pau Monné
Signed-off-by: Andrew Cooper
---
xen/common/libx86/msr.c | 63
xen/include/xen/libx86/msr.h | 4 +++
2 files changed, 67 insertions(+)
diff --git
From: Sergey Dyasli
This finally (after literally years of work!) marks the point where the
toolstack can ask the hypervisor for the current CPUID configuration of a
specific domain.
Also extend xen-cpuid's --policy mode to be able to take a domid and dump a
specific domains CPUID and MSR
flight 124899 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124899/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 16
From: Roger Pau Monné
As with CPUID, the an architectural form is used for representing the MSR
data. It is expected not to change moving forwards, but does have a 32 bit
field (currently reserved) which can be used compatibly if needs be.
Signed-off-by: Andrew Cooper
Signed-off-by: Sergey
From: Roger Pau Monné
No functional change.
Signed-off-by: Roger Pau Monné
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Sergey Dyasli
CC: Ian Jackson
---
tools/libxc/xc_cpuid_x86.c | 2 +
tools/tests/x86_emulator/x86-emulate.h | 2
From: Sergey Dyasli
Provide a SYSCTL for the toolstack to obtain complete system CPUID and MSR
policy information. The split of default vs max policies is introduced into
the API, including a description of the intended behaviour. For now, max is
the default, but this is intended to change
From: Roger Pau Monné
This prevents having to generate it inside the libxc folder.
Signed-off-by: Roger Pau Monné
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Sergey Dyasli
CC: Ian Jackson
RFC - I'm not sure a parallel build of Xen and the tools
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Sergey Dyasli
CC: Ian Jackson
---
tools/libxc/xc_cpuid_x86.c | 1 +
xen/include/asm-x86/msr.h| 51 +++---
xen/include/xen/libx86/msr.h | 58
From: Roger Pau Monné
Move x86_cpuid_lookup_deep_deps() into the shared library, removing the
individual copies from the hypervisor and libxc respectively.
Signed-off-by: Roger Pau Monné
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Sergey Dyasli
CC:
The serialised form is made up of the leaf, subleaf and data tuple. As this
is the architectural form, it is expected not to change going forwards.
x86_cpuid_copy_to_buffer() is implemented using Xen's regular copy_to_guest
primitives, with an API-compatible memcpy() is used for the libxc half
This series introduces libx86, a small shared library between the hypervisor
and libxc, and hypercalls to get/set full CPUID/MSR policies. Future work
will arrange for XEN_DOMCTL_set_cpumsr_policy to function properly, after the
auditing and comparison logic is sorted.
In the meantime, the data
This is mainly prep work for the following patch, but this specific
abstraction is also specifically useful for the future auditing logic.
Not all of msr_vcpu_policy will be interesting from a domain building
perspective, but some soon-to-appear fields will be (SGX Launch Hash
specifically). The
Begin to untangle the header dependency tangle by moving definition of
struct cpuid_leaf out of x86_emulate.h into the new cpuid.h.
Additionally, plumb the header through to libxc. This is technically a
redundant include at this point, but it helps build-test the later changes,
and will be used
On Tue, 3 Jul 2018, Roger Pau Monné wrote:
> On Mon, Jul 02, 2018 at 10:18:17AM -0700, Stefano Stabellini wrote:
> > On Mon, 2 Jul 2018, Julien Grall wrote:
> > > On 06/26/2018 07:49 AM, Roger Pau Monné wrote:
> > > > On Mon, Jun 25, 2018 at 05:39:12PM +0100, Ian Jackson wrote:
> > > > > Roger Pau
flight 124897 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124897/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken in 124786
build-arm64
This run is configured for baseline tests only.
flight 74930 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74930/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-121
On Tue, 3 Jul 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 02/07/18 23:08, Stefano Stabellini wrote:
> > On Mon, 2 Jul 2018, Julien Grall wrote:
> > > Hi,
> > >
> > > On 02/07/2018 19:24, Stefano Stabellini wrote:
> > > > On Mon, 2 Jul 2018, Julien Grall wrote:
> > > > > Hi Stefano,
> > > > >
flight 124920 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124920/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf aa4240edff41034d709938a15b42cf4fd3214386
baseline version:
ovmf
Roger Pau Monné writes ("Re: [PATCH 3/3] osstest: add FreeBSD Xen build job"):
> On Tue, Jul 03, 2018 at 04:22:45PM +0100, Ian Jackson wrote:
> > This is quite ugly. sg-run-job normally tries to be a bit more
> > abstract. I'm not sure exactly what to suggest.
> >
> > Maybe a ts-xen-build-clang
Roger Pau Monné writes ("Re: [PATCH 2/3] osstest: set the make command to use
for xen-build"):
> On Tue, Jul 03, 2018 at 04:12:06PM +0100, Ian Jackson wrote:
> > Wouldn't it be better to write
> >$ho->{OS} =~ m/bsd/
> > or something ?
>
> Yes, that's indeed better. Would you like me to send
Roger Pau Monné writes ("Re: [PATCH 1/3] osstest: remove duplicate
set_freebsd_runvars"):
> On Tue, Jul 03, 2018 at 04:10:56PM +0100, Ian Jackson wrote:
> > Roger Pau Monne writes ("[PATCH 1/3] osstest: remove duplicate
> > set_freebsd_runvars"):
> > > Signed-off-by: Roger Pau Monné
> >
> >
On Tue, Jul 03, 2018 at 06:02:27PM +0200, Daniel Kiper wrote:
> On Thu, Jun 28, 2018 at 11:35:24PM -0600, Jan Beulich wrote:
> > >>> Roger Pau Monne 06/28/18 5:38 PM >>>
> > >lld (the llvm linker) has some issues with Xen linker script. It
> > >doesn't understand '||' in assert expressions:
> > >
On Tue, Jul 03, 2018 at 09:14:30AM -0600, Jan Beulich wrote:
> >>> On 25.06.18 at 10:33, wrote:
> > the dom0 has been running for a week now, running the daily NetBSD tests.
> > Attached is the console log.
> > I didn't notice anything suspect, exept a few domU crashes (crashing in
> > Xen, the
flight 124892 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124892/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-cubietruckbroken in 124853
On Tue, Jul 03, 2018 at 04:22:45PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH 3/3] osstest: add FreeBSD Xen build job"):
> > To both the FreeBSD and the xen-unstable flights.
> >
> > This is the runvar difference of a xen-unstable flight:
>
> Just to clarify my thinking:
>
> >
On Thu, Jun 28, 2018 at 11:35:24PM -0600, Jan Beulich wrote:
> >>> Roger Pau Monne 06/28/18 5:38 PM >>>
> >lld (the llvm linker) has some issues with Xen linker script. It
> >doesn't understand '||' in assert expressions:
> >
> >ld-melf_x86_64_fbsd -T xen.lds -N prelink.o --build-id=sha1 \
>
On Tue, Jul 03, 2018 at 04:12:06PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH 2/3] osstest: set the make command to use for
> xen-build"):
> > The default make on FreeBSD is the BSD make, and Xen requires the GNU
> > make in order to build. Set the make command based on the OS
On Tue, Jul 03, 2018 at 04:10:56PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH 1/3] osstest: remove duplicate
> set_freebsd_runvars"):
> > Signed-off-by: Roger Pau Monné
>
> Oops. I wonder if this was my doing. Have you verified that they're
> identical ?
They are not
Roger Pau Monne writes ("[PATCH 3/3] osstest: add FreeBSD Xen build job"):
> To both the FreeBSD and the xen-unstable flights.
>
> This is the runvar difference of a xen-unstable flight:
Just to clarify my thinking:
> +# Create a Xen build job that's going to use the output from the first
>
>>> On 25.06.18 at 10:33, wrote:
> the dom0 has been running for a week now, running the daily NetBSD tests.
> Attached is the console log.
> I didn't notice anything suspect, exept a few domU crashes (crashing in
> Xen, the problem is not reported back to the domU). But as this is
> running
Roger Pau Monne writes ("[PATCH 2/3] osstest: set the make command to use for
xen-build"):
> The default make on FreeBSD is the BSD make, and Xen requires the GNU
> make in order to build. Set the make command based on the OS for the
> Xen build.
...
> our $dokconfig = 1;
> +our $make =
Roger Pau Monne writes ("[PATCH 1/3] osstest: remove duplicate
set_freebsd_runvars"):
> Signed-off-by: Roger Pau Monné
Oops. I wonder if this was my doing. Have you verified that they're
identical ?
Ian.
___
Xen-devel mailing list
The increased number of messages (spec_ctrl.c:print_details()) within a
certain time window made me notice some slowness of boot time screen
output. Experimentally I've narrowed the time window to be from
immediately after the early ucode update on the BSP to the PAT write in
cpu_init(). For that
Anthony PERARD writes ("[PATCH v3.1] libxl: Design of an async API to issue QMP
commands to QEMU"):
> All the functions will be implemented in later patches.
Thanks, this really makes things clearer for me.
> What do you think of this design? This is the same as in my patch series
> with new
On Thu, Jun 28, 2018 at 12:26:01PM +0300, Kristaps Čivkulis wrote:
> Roger provided Xen kernel binary for me and it worked. I don't know
> why I couldn't build it properly on FreeBSD.
Please try to execute "make distclean" before the build. This will
cleanup whole Xen source tree. Sometimes it
On Tue, Jul 03, 2018 at 10:46:51AM +0800, zhiyong ye wrote:
> Hi,
> I've come across a need to hotplug PCI devices between dom0 and domU
> using SR-IOV NIC. But I'm experiencing problems when trying to detach VF
> more than one PV guests.
> I can attach VF to DomU successful as follow:
flight 124885 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124885/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
> -Original Message-
> From: Dongli Zhang
> Sent: Monday, July 2, 2018 4:19 AM
> To: xen-devel@lists.xenproject.org
> Cc: Boris Ostrovsky ; jgr...@suse.com; Paul
> Durrant ; Srinivas REDDY Eeda
> ; Wei Liu ; Joao Marcal
> Lemos Martins
> Subject: [Notes for xen summit 2018 design session
flight 124906 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124906/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814
build-amd64-libvirt
>>> On 03.07.18 at 14:05, wrote:
> On Vi, 2018-06-29 at 10:00 -0600, Jan Beulich wrote:
>> > > > On 28.06.18 at 11:25, wrote:
>> > --- a/xen/include/asm-x86/hvm/support.h
>> > +++ b/xen/include/asm-x86/hvm/support.h
>> > @@ -52,6 +52,8 @@ extern unsigned int opt_hvm_debug_level;
>> > #define
>>> On 03.07.18 at 12:19, wrote:
>> > +/*
>> > + * Any attempt to modify IA32_RTIT_CTL while TraceEn is set will
>> > + * result in a #GP unless the same write also clears TraceEn.
>> > + */
>> > +if ( (ipt_desc->ipt_guest.ctl & RTIT_CTL_TRACEEN) &&
>> > +
>>> On 03.07.18 at 12:18, wrote:
>> > --- a/xen/arch/x86/hvm/vmx/vmx.c
>> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> > @@ -2898,6 +2898,15 @@ static int vmx_msr_read_intercept(unsigned int
>> > msr, uint64_t *msr_content)
>> > if ( vpmu_do_rdmsr(msr, msr_content) )
>> > goto
>>> On 03.07.18 at 12:18, wrote:
>> > +#define IPT_CAP(_n, _l, _r, _m) \
>> > +[IPT_CAP_ ## _n] = { .name = __stringify(_n), .leaf = _l, \
>> > +.reg = _r, .mask = _m }
>> > +
>> > +static struct ipt_cap_desc {
>> > +const char*name;
>> > +
On Vi, 2018-06-29 at 10:00 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 28.06.18 at 11:25, wrote:
> > +static int hvm_save_cpu_ctxt_one(struct vcpu *v,
> > hvm_domain_context_t *h)
> > +{
> > +struct segment_register seg;
> > +struct hvm_hw_cpu ctxt;
> > +
> > +memset(, 0,
>>> On 03.07.18 at 12:18, wrote:
>> > @@ -40,3 +42,102 @@ static int __init parse_ipt_params(const char
>> > +static inline void ipt_save_msr(struct ipt_ctx *ctx, unsigned int
>> > +addr_range) {
>> > +unsigned int i;
>> > +
>> > +rdmsrl(MSR_IA32_RTIT_STATUS, ctx->status);
>> > +
>>> On 03.07.18 at 12:18, wrote:
>> > --- a/xen/include/asm-x86/msr-index.h
>> > +++ b/xen/include/asm-x86/msr-index.h
>> > @@ -548,4 +548,41 @@
>> > #define MSR_PKGC9_IRTL0x0634
>> > #define MSR_PKGC10_IRTL 0x0635
>> >
>> > +/* Intel PT MSRs */
>>
>>> On 03.07.18 at 12:18, wrote:
>> > --- a/docs/misc/xen-command-line.markdown
>> > +++ b/docs/misc/xen-command-line.markdown
>> > @@ -1215,6 +1215,16 @@ Rather than only mapping RAM pages for IOMMU
>> > accesses for Dom0, with this option all pages not marked as unusable
>> > in the E820 table
>>> On 03.07.18 at 12:48, wrote:
> On Tue, Jun 26, 2018 at 01:51:47AM -0600, Jan Beulich wrote:
>> First of all introduce a helper function instead of replicating almost
>> the same code for PV and HVM. The differences between the two pieces of
>> code actually points out an issue (which is also
>>> On 03.07.18 at 13:07, wrote:
> On Tue, Jul 03, 2018 at 04:56:38AM -0600, Jan Beulich wrote:
>> >>> On 03.07.18 at 12:51, wrote:
>> > I don't think we ever want to allow DomU-s to manage the SR-IOV
>> > capability, so this code is always going to be Dom0 only AFAICT. In
>> > fact I think I'm
flight 124884 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124884/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale broken
test-armhf-armhf-xl-arndale 4
On Tue, Jul 03, 2018 at 10:14:06AM +, Lars Kurth wrote:
>
>
> On 03/07/2018, 11:01, "Jan Beulich" wrote:
>
> >>> On 03.07.18 at 10:06, wrote:
> > The GitLab discussion was really interesting. Looking at OSSTEST, it
> > basically performs build test and integration tests on
thanks very much for your reply, could you please tell us:
1. if develop this “copy-on-write functionality”, how many lines of codes maybe
needed？
2. if this tool is done, how many performance may be improved?
best regards
陈甲 Chenjia
M：+86-13301235534
Taking the advisory board list off the CC list: will summarize when we have
more of a plan forward
On 03/07/2018, 11:47, "Juergen Gross" wrote:
On 03/07/18 12:23, Lars Kurth wrote:
> Combined reply to Jan and Roger
> Lars
>
> On 03/07/2018, 11:07, "Roger Pau Monne"
Hi Stefano,
On 02/07/18 23:08, Stefano Stabellini wrote:
On Mon, 2 Jul 2018, Julien Grall wrote:
Hi,
On 02/07/2018 19:24, Stefano Stabellini wrote:
On Mon, 2 Jul 2018, Julien Grall wrote:
Hi Stefano,
On 06/29/2018 07:38 PM, Stefano Stabellini wrote:
On Thu, 28 Jun 2018, Roger Pau Monné
On Tue, Jul 03, 2018 at 04:56:38AM -0600, Jan Beulich wrote:
> >>> On 03.07.18 at 12:51, wrote:
> > I don't think we ever want to allow DomU-s to manage the SR-IOV
> > capability, so this code is always going to be Dom0 only AFAICT. In
> > fact I think I'm going to add an assert to that effect in
>>> On 03.07.18 at 12:51, wrote:
> I don't think we ever want to allow DomU-s to manage the SR-IOV
> capability, so this code is always going to be Dom0 only AFAICT. In
> fact I think I'm going to add an assert to that effect in the SR-IOV
> init handler.
Did you consider nested virt here?
Jan
On Tue, Jul 03, 2018 at 12:21:08PM +0200, Roger Pau Monné wrote:
> On Tue, Jul 03, 2018 at 10:27:59AM +0100, Wei Liu wrote:
> > On Wed, Jun 20, 2018 at 04:42:34PM +0200, Roger Pau Monne wrote:
> > > +/* Set the BARs addresses and size. */
> > > +for ( i = 0; i < PCI_SRIOV_NUM_BARS;
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, July 3, 2018 6:16 PM
> To: Xin Li (Talons) ; Xin Li
> Cc: Andrew Cooper ; George Dunlap
> ; Ming Lu ; Sergey Dyasli
> ; Wei Liu ; Stefano Stabellini
> ; xen-de...@lists.xen.org; Konrad Rzeszutek Wilk
> ;
Hi all,
Xen 4.11 rc7 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.11.0-rc7
For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.11.0-rc7/xen-4.11.0-rc7.tar.gz
And the signature is at:
On 03/07/18 11:47, Julien Grall wrote:
>
>
> On 03/07/18 07:29, Jan Beulich wrote:
> On 02.07.18 at 22:28, wrote:
>>> On Mon, Jul 02, 2018 at 02:47:42PM +0100, Julien Grall wrote:
On 06/26/2018 10:03 AM, Jan Beulich wrote:
On 26.06.18 at 10:43, wrote:
>> On 26/06/18 08:24,
On Tue, Jul 03, 2018 at 04:48:19AM -0600, Jan Beulich wrote:
> >>> On 03.07.18 at 12:21, wrote:
> > On Tue, Jul 03, 2018 at 10:27:59AM +0100, Wei Liu wrote:
> >> On Wed, Jun 20, 2018 at 04:42:34PM +0200, Roger Pau Monne wrote:
> >> > +sriov->num_vfs = pci_conf_read16(pdev->seg,
>>> On 03.07.18 at 12:21, wrote:
> On Tue, Jul 03, 2018 at 10:27:59AM +0100, Wei Liu wrote:
>> On Wed, Jun 20, 2018 at 04:42:34PM +0200, Roger Pau Monne wrote:
>> > +sriov->num_vfs = pci_conf_read16(pdev->seg, pdev->bus,
>> > +
On Tue, Jun 26, 2018 at 01:51:47AM -0600, Jan Beulich wrote:
> First of all introduce a helper function instead of replicating almost
> the same code for PV and HVM. The differences between the two pieces of
> code actually points out an issue (which is also addressed here): In
> the HVM case FCW
On 03/07/18 07:29, Jan Beulich wrote:
On 02.07.18 at 22:28, wrote:
On Mon, Jul 02, 2018 at 02:47:42PM +0100, Julien Grall wrote:
On 06/26/2018 10:03 AM, Jan Beulich wrote:
On 26.06.18 at 10:43, wrote:
On 26/06/18 08:24, Jan Beulich wrote:
@@ -698,26 +701,30 @@ static void
On 03/07/18 12:23, Lars Kurth wrote:
> Combined reply to Jan and Roger
> Lars
>
> On 03/07/2018, 11:07, "Roger Pau Monne" wrote:
>
> On Mon, Jul 02, 2018 at 06:03:39PM +, Lars Kurth wrote:
> > We then had a discussion around why the positive benefits didn't
> materialize:
> >
Hi Stefano,
On 02/07/18 22:31, Stefano Stabellini wrote:
On Thu, 14 Jun 2018, Julien Grall wrote:
On 13/06/18 23:15, Stefano Stabellini wrote:
+
+- cpus (optional)
+
+A string specifying the number of vcpus to allocate to the guest. If
+not specified it defaults to "1".
Same remarks
On 03/07/18 12:07, Roger Pau Monné wrote:
> On Mon, Jul 02, 2018 at 06:03:39PM +, Lars Kurth wrote:
>> We then had a discussion around why the positive benefits didn't materialize:
>> * Andrew and a few other believe that the model isn't broken, but that the
>> issue is with how we
>>
On 03/07/18 11:19, Kang, Luwei wrote:
>>> --- a/xen/include/public/arch-x86/cpufeatureset.h
>>> +++ b/xen/include/public/arch-x86/cpufeatureset.h
>>> @@ -215,6 +215,7 @@ XEN_CPUFEATURE(SMAP, 5*32+20) /*S Supervisor
>>> Mode Access Prevention */
>>> XEN_CPUFEATURE(AVX512IFMA,
Combined reply to Jan and Roger
Lars
On 03/07/2018, 11:07, "Roger Pau Monne" wrote:
On Mon, Jul 02, 2018 at 06:03:39PM +, Lars Kurth wrote:
> We then had a discussion around why the positive benefits didn't
materialize:
> * Andrew and a few other believe that the model isn't
Hi,
On 02/07/18 22:38, Stefano Stabellini wrote:
On Mon, 2 Jul 2018, Julien Grall wrote:
Hi,
On 02/07/2018 21:37, Stefano Stabellini wrote:
On Fri, 15 Jun 2018, Julien Grall wrote:
Hi Stefano,
On 06/14/2018 10:15 PM, Stefano Stabellini wrote:
On Thu, 14 Jun 2018, Julien Grall wrote:
On
On Tue, Jul 03, 2018 at 10:27:59AM +0100, Wei Liu wrote:
> On Wed, Jun 20, 2018 at 04:42:34PM +0200, Roger Pau Monne wrote:
> > +/* Set the BARs addresses and size. */
> > +for ( i = 0; i < PCI_SRIOV_NUM_BARS; i += rc )
> > +{
> > +unsigned int j, idx = pos +
> > Any attempt to modify IA32_RTIT_CTL while TraceEn is set will result
> > in a #GP unless the same write also clears TraceEn.
> > Writes to IA32_RTIT_CTL that do not modify any bits will not cause a
> > #GP, even if TraceEn remains set.
> > MSR write that attempts to change bits marked
> > @@ -1519,6 +1520,14 @@ int nvmx_handle_vmxon(struct cpu_user_regs *regs)
> > v->arch.hvm_vmx.launched = 0;
> > vmsucceed(regs);
> >
> > +if ( v->arch.hvm_vmx.ipt_desc )
> > +{
> > +v->arch.hvm_vmx.ipt_desc->ipt_guest.ctl = 0;
> > +vmx_vmcs_enter(current);
> >
> > --- a/docs/misc/xen-command-line.markdown
> > +++ b/docs/misc/xen-command-line.markdown
> > @@ -1215,6 +1215,16 @@ Rather than only mapping RAM pages for IOMMU
> > accesses for Dom0, with this option all pages not marked as unusable
> > in the E820 table will get a mapping established.
> >
>
> > @@ -40,3 +42,102 @@ static int __init parse_ipt_params(const char
> > *str)
> >
> > return 0;
> > }
> > +
> > +static inline void ipt_load_msr(const struct ipt_ctx *ctx,
> > + unsigned int addr_range)
>
> Please let the compiler decide whether to inline such
> > --- a/xen/include/asm-x86/msr-index.h
> > +++ b/xen/include/asm-x86/msr-index.h
> > @@ -548,4 +548,41 @@
> > #define MSR_PKGC9_IRTL 0x0634
> > #define MSR_PKGC10_IRTL0x0635
> >
> > +/* Intel PT MSRs */
> > +#define MSR_IA32_RTIT_CTL
> > --- a/xen/include/public/arch-x86/cpufeatureset.h
> > +++ b/xen/include/public/arch-x86/cpufeatureset.h
> > @@ -215,6 +215,7 @@ XEN_CPUFEATURE(SMAP, 5*32+20) /*S Supervisor
> > Mode Access Prevention */
> > XEN_CPUFEATURE(AVX512IFMA,5*32+21) /*A AVX-512 Integer Fused Multiply
> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> > @@ -2898,6 +2898,15 @@ static int vmx_msr_read_intercept(unsigned int
> > msr, uint64_t *msr_content)
> > if ( vpmu_do_rdmsr(msr, msr_content) )
> > goto gp_fault;
> > break;
> > +case
> > --- a/xen/arch/x86/cpu/ipt.c
> > +++ b/xen/arch/x86/cpu/ipt.c
> > @@ -25,11 +25,74 @@
> > #include
> > #include
> >
> > +#define EAX 0
> > +#define ECX 1
> > +#define EDX 2
> > +#define EBX 3
> > +#define CPUID_REGS_NUM 4 /* number of regsters (eax, ebx, ecx, edx) */
> > +
> > +#define
>>> On 03.07.18 at 11:07, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Tuesday, July 3, 2018 3:34 PM
>> >>> On 03.07.18 at 03:26, wrote:
>> > +return (is_control_domain(cur_dom) || is_control_domain(ldom) ||
>> > +is_control_domain(rdom) || ldom == rdom); }
>>
>>> On 03.07.18 at 10:13, wrote:
> On 03/07/2018, 08:00, "Jan Beulich" wrote:
> Fundamentally the problem can as well be seen when looking at any
> of the stable branches: The variety of authors there is significantly
> more narrow than for what goes into master. I understand people
On 03/07/2018, 11:01, "Jan Beulich" wrote:
>>> On 03.07.18 at 10:06, wrote:
> The GitLab discussion was really interesting. Looking at OSSTEST, it
> basically performs build test and integration tests on Hardware. Whereas
all
> these are needed, build testing and testing
On Mon, Jul 02, 2018 at 06:03:39PM +, Lars Kurth wrote:
> We then had a discussion around why the positive benefits didn't materialize:
> * Andrew and a few other believe that the model isn't broken, but that the
> issue is with how we
> develop. In other words, moving to a 9 months model
osstest service owner writes ("[xen-4.11-testing test] 124876: trouble:
blocked/broken/fail/pass"):
> flight 124876 xen-4.11-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/124876/
>
> Failures and problems with tests :-(
>
> Tests which did not succeed and are blocking,
>>> On 03.07.18 at 10:06, wrote:
> The GitLab discussion was really interesting. Looking at OSSTEST, it
> basically performs build test and integration tests on Hardware. Whereas all
> these are needed, build testing and testing of functionality that does not
> depend on hardware could be done
>>> On 03.07.18 at 10:17, wrote:
> On Fri, Jun 08, 2018 at 11:59:26AM +0200, Roger Pau Monne wrote:
>> Hello,
>>
>> The following patches set a sane initial MTRR state for both Dom0 and
>> DomU PVH guests. Note that for Dom0 the host MTRR state is used, OTOH
>> for DomU the default MTRR type is
All the functions will be implemented in later patches.
Signed-off-by: Anthony PERARD
---
What do you think of this design? This is the same as in my patch series
with new names (to avoid confusion with libxl___ev_*) and documentation.
I'll write something as well for the internal of the
Hi, Sorry for the top post (I'm not managing todo in line reply with my
phone).
Yes, in the long run it there are some benefits if the format could be kept
similar when possible. We could reuse some of the documentation and perhaps
some of the code to parse. Allthough I'm guessing that most of
1 - 100 of 114 matches
Mail list logo
