>>> On 02.07.18 at 18:22, wrote:
> On Mon, Jul 02, 2018 at 09:09:31AM -0600, Jan Beulich wrote:
>> >>> On 02.07.18 at 16:54, wrote:
>> > Ping?
>>
>> I don't understand: There's no open question in the quoted mail.
>
> It's more of a refute of your argument about assert of level triggered
>
On 02/07/18 20:03, Lars Kurth wrote:
> Non-html version: apologies
> Lars
>
> From: Lars Kurth
> Date: Monday, 2 July 2018 at 19:00
> To: xen-devel
> Cc: "committ...@xenproject.org" , Rich Persaud
> , Doug Goldstein ,
> "advisory-bo...@lists.xenproject.org"
> Subject: [Notes for xen summit
> -Original Message-
> From: Xin Li [mailto:talons@gmail.com]
> Sent: Tuesday, July 3, 2018 9:26 AM
> To: xen-de...@lists.xen.org
> Cc: Xin Li (Talons) ; Daniel De Graaf
> ; George Dunlap ; Jan
> Beulich ; Konrad Rzeszutek Wilk
> ; Stefano Stabellini ; Tim
> (Xen.org) ; Wei Liu ;
>>> 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/2018, 07:26, "Juergen Gross" wrote:
On 02/07/18 20:03, 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
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 set to write-back.
>
> This should avoid
On Thu, Jun 14, 2018 at 2:26 AM, Chenjia (C) wrote:
> Dear XEN expert:
>
> We meet some problem in our project: In our previous project, we
> use KVM, and we do some job like this:
>
>
>
> We create KVM snapshot by “virsh snapshot-create $DomainName $SnapshotXml”,
> then do following
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, July 3, 2018 3:12 PM
> To: Xin Li
> Cc: Andrew Cooper ; Ming Lu
> ; Sergey Dyasli ; Wei Liu
> ; Xin Li (Talons) ; George Dunlap
> ; Stefano Stabellini ; xen-
> de...@lists.xen.org; Konrad Rzeszutek Wilk ;
First of all - please indicate the version also in the subject, i.e. here
[PATCH v2 1/2] or some such.
>>> On 03.07.18 at 03:26, wrote:
> v2
> To further discuss:
> 1) is "dummy" a good command line option?
> other choices: basic", "trivial", or "simple"
Indeed, but not limited to the named
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 Monné writes ("Re: [PATCH RFC] tools/libxl: Switch
>>> On 03.07.18 at 03:26, wrote:
> v2
> To further discuss:
> 1) is the new Kconfig option XSM_SILO necessary?
> we can handle SILO similar as DUMMY, using exsting CONFIG_XSM.
>
> 2) explain "unmediated communication channel"
I'm confused: As said in the reply to patch 1, this section is
>>> On 02.07.18 at 18:19, wrote:
> Now that ELF support has been dropped to boot Dom0, no-one is using
> libelf within the hypervisor.
>
> Introduce a config option to select libelf on x86 and keep unselected
> for Arm.
>
> Signed-off-by: Julien Grall
Acked-by: Jan Beulich
Hello Jan,
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, July 3, 2018 3:34 PM
> To: Xin Li ; Daniel de Graaf
> Cc: Andrew Cooper ; Ming Lu
> ; Sergey Dyasli ; Wei Liu
> ; Xin Li (Talons) ; George Dunlap
> ; Stefano Stabellini ; xen-
>
On Wed, Jun 20, 2018 at 04:42:34PM +0200, Roger Pau Monne wrote:
> So that a PCI device that supports SR-IOV (PF) can enable the capability
> and use the virtual functions.
>
> This code is expected to only be used by privileged domains,
> unprivileged domains should not get access to the SR-IOV
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
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
>>> 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
>>> 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 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,
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 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 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 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: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 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) &&
>> > +
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 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 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
>>
> -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
> ;
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;
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 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
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 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 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
>>> 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); }
>>
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
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,
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"
>>> 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
> > @@ -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/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.
> >
>
> > 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/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
> > --- 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
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 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 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
>>> 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
>>> 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 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
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 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 +
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 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 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 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 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 */
>>
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
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 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
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 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 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 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
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,
> > > > >
> > >
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, 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 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: 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
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
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
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
> -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
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:
>>> 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
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
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
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 =
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
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: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
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 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
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:
> > >
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
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 \
>
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é
> >
> >
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
>
1 - 100 of 114 matches
Mail list logo