[Xen-devel] [PATCH] xen/domctl: lower loglevel of XEN_DOMCTL_memory_mapping

We should lower loglevel to XENLOG_G_DEBUG while mapping or unmapping memory via XEN_DOMCTL_memory_mapping since its fair enough to check this info just while debugging. CC: Ian Campbell CC: Ian Jackson CC: Jan Beulich CC:

Re: [Xen-devel] [Xen-users] Xen bridging issue.

On 09/08/2015 02:45 PM, Wei Liu wrote: On Tue, Sep 08, 2015 at 02:33:53PM +0300, johnny Strom wrote: On 09/08/2015 02:12 PM, Wei Liu wrote: On Tue, Sep 08, 2015 at 02:07:21PM +0300, johnny Strom wrote: On 09/08/2015 01:06 PM, Wei Liu wrote: On Tue, Sep 08, 2015 at 12:59:39PM +0300, johnny

[Xen-devel] [PATCH] x86/hvm: fix saved pmtimer value

The ACPI PM timer is sometimes broken on live migration. Since vcpu->arch.hvm_vcpu.guest_time is zero in most cases. Without this patch, the clock of windows server 2012R2 without HPET might leap forward several minutes on live migration. Signed-off-by: Kouya Shimura ---

Re: [Xen-devel] [PATCH v4 10/11] x86/intel_pstate: support the use of intel_pstate in pmstat.c

On 24/07/2015 22:16, Jan Beulich wrote: >>> On 25.06.15 at 13:17, wrote: > --- a/xen/drivers/acpi/pmstat.c > +++ b/xen/drivers/acpi/pmstat.c > --- a/xen/include/public/sysctl.h > +++ b/xen/include/public/sysctl.h > @@ -315,8 +315,18 @@ struct xen_get_cpufreq_para { >

Re: [Xen-devel] [PATCH v2 3/4] tools: add tools support for Intel CDP

>>> On 09.09.15 at 10:10, wrote: > On Wed, Sep 09, 2015 at 03:32:11PM +0800, Chao Peng wrote: >> On Wed, Sep 09, 2015 at 01:16:47PM +0800, He Chen wrote: >> > @@ -304,14 +305,41 @@ int libxl_psr_cat_set_cbm(libxl_ctx *ctx, uint32_t >> > domid, >> > goto out; >>

Re: [Xen-devel] [PATCH v6 16/18] vmx: Add some scheduler hooks for VT-d posted interrupts

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Monday, September 07, 2015 8:55 PM > To: Wu, Feng > Cc: Andrew Cooper; Dario Faggioli; George Dunlap; Tian, Kevin; > xen-devel@lists.xen.org; Keir Fraser > Subject: Re: [PATCH v6 16/18] vmx: Add some scheduler

Re: [Xen-devel] [PATCH v2 1/4] x86: Support enable CDP by boot parameter and add get CDP status

On Wed, Sep 09, 2015 at 01:16:45PM +0800, He Chen wrote: > Intel Code/Data Prioritization(CDP) feature is based on CAT. cdp_enabled > is added to CAT socket info to indicate CDP is on or off on the socket, > note that cos_max would be half when CDP is on. struct psr_cat_cbm is > extended to

Re: [Xen-devel] [PATCH v4 10/11] x86/intel_pstate: support the use of intel_pstate in pmstat.c

On 09/09/2015 16:32, Jan Beulich wrote: >>> On 09.09.15 at 10:11, wrote: > On 24/07/2015 22:16, Jan Beulich wrote: On 25.06.15 at 13:17, wrote: >> --- a/xen/drivers/acpi/pmstat.c >> +++ b/xen/drivers/acpi/pmstat.c >> ---

Re: [Xen-devel] [PATCH v2 3/4] tools: add tools support for Intel CDP

On Wed, Sep 09, 2015 at 02:37:36AM -0600, Jan Beulich wrote: > >>> On 09.09.15 at 10:10, wrote: > > On Wed, Sep 09, 2015 at 03:32:11PM +0800, Chao Peng wrote: > >> On Wed, Sep 09, 2015 at 01:16:47PM +0800, He Chen wrote: > >> > @@ -304,14 +305,41 @@ int

Re: [Xen-devel] [PATCH for 4.6] x86/VPMU: Set VPMU context pointer to NULL when freeing it

>>> On 09.09.15 at 04:55, wrote: > Otherwise we may hit assertion in vpmu_initialise() if vcpu is offlined > and then onlined again. > > For tidyness, set priv_context to NULL as well. > > Signed-off-by: Boris Ostrovsky Acked-by: Jan

Re: [Xen-devel] [PATCH v2 2/4] x86: add domctl cmd to set/get CDP code/data CBM

On Wed, Sep 09, 2015 at 01:16:46PM +0800, He Chen wrote: > CDP extends CAT and provides the capacity to control L3 code & data > cache. With CDP, one COS correspond to two CMBs(code & data). cbm_type > is added to support distinguish different CBM operation. Besides, new > domctl cmds are

Re: [Xen-devel] [PATCH v2 0/4] Intel Code/Data Prioritization(CDP) feature enabling

On Wed, Sep 09, 2015 at 01:16:44PM +0800, He Chen wrote: > Changes in v2: > - x86: Enable CDP by boot parameter instead of enabling/disabling CDP at > runtime (suggested by Andrew) As you added a new boot option, you also need a patch for docs/misc/xen-command-line.markdown. Chao > - tools:

Re: [Xen-devel] [PATCH for 4.6] x86/VPMU: Set VPMU context pointer to NULL when freeing it

On Tue, Sep 08, 2015 at 10:55:52PM -0400, Boris Ostrovsky wrote: > Otherwise we may hit assertion in vpmu_initialise() if vcpu is offlined > and then onlined again. > > For tidyness, set priv_context to NULL as well. > > Signed-off-by: Boris Ostrovsky

Re: [Xen-devel] [PATCH for 4.6] x86/VPMU: Set VPMU context pointer to NULL when freeing it

Am Dienstag 08 September 2015, 22:55:52 schrieb Boris Ostrovsky: > Otherwise we may hit assertion in vpmu_initialise() if vcpu is offlined > and then onlined again. > > For tidyness, set priv_context to NULL as well. Reviewed-by: Dietmar Hahn > > Signed-off-by:

Re: [Xen-devel] [PATCH] x86/hvm: fix saved pmtimer value

>>> On 09.09.15 at 09:31, wrote: > The ACPI PM timer is sometimes broken on live migration. > Since vcpu->arch.hvm_vcpu.guest_time is zero in most cases. I.e. in other than "delay for missed ticks mode". Would have been nice if you had spelled this out explicitly. With that

Re: [Xen-devel] Question to Xen log level in the case of PT

So can Xen change log level dynamically like Linux? If yes, we might change this level temporarily while passing through IGD. If not, any suggestion? First of all you could boot without lowering the log level (non-debug builds) or raising the log level ("loglvl=warning"; debug builds). But

Re: [Xen-devel] [v2][PATCH] xen/vtd/iommu: permit group devices to passthrough in relaxed mode

>>> On 09.09.15 at 03:59, wrote: > @@ -2310,12 +2312,16 @@ static int intel_iommu_assign_device( > PCI_DEVFN2(bdf) == devfn && > rmrr->scope.devices_cnt > 1 ) > { > -printk(XENLOG_G_ERR VTDPREFIX > - "

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

>>> On 09.09.15 at 00:23, wrote: > On 09/08/15 19:26, Anthony PERARD wrote: >> And I get this on the console: >> Welcome to GRUB! >> >> X64 Exception Type - 0E(#PF - Page-Fault) CPU Apic ID - >> RIP - 0F5F8918, CS - 0028, RFLAGS -

Re: [Xen-devel] [PATCH v2 3/4] tools: add tools support for Intel CDP

On Wed, Sep 09, 2015 at 01:16:47PM +0800, He Chen wrote: > This is the xl/xc changes to support Intel Code/Data Prioritization. > CAT xl commands to set/get CBMs are extended to support CDP. > > Signed-off-by: He Chen > --- > diff --git a/tools/libxl/libxl.h

Re: [Xen-devel] [PATCH v2 2/4] x86: add domctl cmd to set/get CDP code/data CBM

>>> On 09.09.15 at 09:24, wrote: > On Wed, Sep 09, 2015 at 01:16:46PM +0800, He Chen wrote: >> -int psr_get_l3_cbm(struct domain *d, unsigned int socket, uint64_t *cbm) >> +int psr_get_l3_cbm(struct domain *d, unsigned int socket, >> + uint64_t *cbm,

Re: [Xen-devel] [PATCH v2 1/4] x86: Support enable CDP by boot parameter and add get CDP status

On Wed, Sep 09, 2015 at 03:04:35PM +0800, Chao Peng wrote: > On Wed, Sep 09, 2015 at 01:16:45PM +0800, He Chen wrote: > > Intel Code/Data Prioritization(CDP) feature is based on CAT. cdp_enabled > > is added to CAT socket info to indicate CDP is on or off on the socket, > > note that cos_max would

Re: [Xen-devel] [PATCH v4 10/11] x86/intel_pstate: support the use of intel_pstate in pmstat.c

>>> On 09.09.15 at 10:49, wrote: > On 09/09/2015 16:32, Jan Beulich wrote: On 09.09.15 at 10:11, wrote: >> On 24/07/2015 22:16, Jan Beulich wrote: > On 25.06.15 at 13:17, wrote: >>> --- a/xen/drivers/acpi/pmstat.c >>>

Re: [Xen-devel] xhci_hcd intterrupt affinity in Dom0/DomU limited to single interrupt

>>> On 08.09.15 at 18:02, wrote: > I believe the driver does support use of multiple interrupts based on > the previous explanation of the lspci output where it was established > that the device could use up to 8 interrupts which is what I see on bare > metal. Where is the

Re: [Xen-devel] Question to Xen log level in the case of PT

>>> On 09.09.15 at 08:53, wrote: >> > So can Xen change log level dynamically like Linux? If yes, we might >>> change this level temporarily while passing through IGD. If not, any >>> suggestion? >> >> First of all you could boot without lowering the log level (non-debug >>

Re: [Xen-devel] [PATCH v2 3/4] tools: add tools support for Intel CDP

On Wed, Sep 09, 2015 at 03:32:11PM +0800, Chao Peng wrote: > On Wed, Sep 09, 2015 at 01:16:47PM +0800, He Chen wrote: > > This is the xl/xc changes to support Intel Code/Data Prioritization. > > CAT xl commands to set/get CBMs are extended to support CDP. > > > > Signed-off-by: He Chen

Re: [Xen-devel] [PATCH] x86/hvm: fix saved pmtimer value

Jan Beulich writes: On 09.09.15 at 09:31, wrote: >> The ACPI PM timer is sometimes broken on live migration. >> Since vcpu->arch.hvm_vcpu.guest_time is zero in most cases. > > I.e. in other than "delay for missed ticks mode". Would have been > nice

Re: [Xen-devel] [PATCH v4 10/11] x86/intel_pstate: support the use of intel_pstate in pmstat.c

>>> On 09.09.15 at 10:11, wrote: > On 24/07/2015 22:16, Jan Beulich wrote: On 25.06.15 at 13:17, wrote: >> --- a/xen/drivers/acpi/pmstat.c >> +++ b/xen/drivers/acpi/pmstat.c >> --- a/xen/include/public/sysctl.h >> +++

Re: [Xen-devel] [PATCH] x86/hvm: fix saved pmtimer value

>>> On 09.09.15 at 10:31, wrote: > Jan Beulich writes: > > On 09.09.15 at 09:31, wrote: >>> The ACPI PM timer is sometimes broken on live migration. >>> Since vcpu->arch.hvm_vcpu.guest_time is zero in most cases. >> >> I.e. in

Re: [Xen-devel] Asus X99-A VT-d problems

>>> On 08.09.15 at 15:21, wrote: > I got Xen booting now with VT-d enabled, lot's of errors and the system is > unstable. xl dmesg output: Lots of errors? I don't see much - can you point out the errors you see? There are two interesting things: > (XEN)

Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API

>>> On 9/9/2015 at 12:52 AM, in message <55ef1244@citrix.com>, George Dunlap wrote: > On 09/08/2015 03:17 PM, Ian Campbell wrote: > > On Mon, 2015-08-10 at 18:35 +0800, Chunyan Liu wrote: > > > > Sorry for the delay, between 4.6 freeze crunch, conference and

Re: [Xen-devel] [xen-unstable test] 61521: regressions - FAIL

On Tue, 2015-09-08 at 17:13 +0100, Ian Jackson wrote: > Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 61521: > regressions - FAIL"): > > That's what I was about to say in a reply to your earlier mail. To me > > this still means the guest booted up successfully (or else it wouldn't > >

Re: [Xen-devel] OVMF BoF @ KVM Forum 2015

On 08/10/15 18:24, Laszlo Ersek wrote: > Hi. > > Let's do an OVMF BoF at this year's KVM Forum too. Here's a preliminary task list, after some off-list discussion (I tried to incorporate comments): - create GPL'd fork called "ovmf" for expediting virt development (OvmfPkg, ArmVirtPkg) -

Re: [Xen-devel] [linux-linus test] 61295: regressions - FAIL

On Thu, 2015-09-03 at 23:29 +, osstest service owner wrote: > flight 61295 linux-linus real [real] > http://logs.test-lab.xenproject.org/osstest/logs/61295/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > [...] >

Re: [Xen-devel] [PATCH v4 10/11] x86/intel_pstate: support the use of intel_pstate in pmstat.c

>>> On 09.09.15 at 12:35, wrote: > On 09/09/2015 18:10, Jan Beulich wrote: On 09.09.15 at 11:35, wrote: >>> Using the drinking vessel analogy, we are not putting milk and water >>> into the vessel at the same time. If the producer puts water

Re: [Xen-devel] [Xen-users] Xen bridging issue.

On Wed, Sep 09, 2015 at 10:09:09AM +0300, johnny Strom wrote: [...] > > Hello again > > I am not sure but there might be another issue with the xen_netback module > in Debian jessie. > > I am not able to set the max_queues options so that it is set at load time. > > I have tested with the

[Xen-devel] [linux-linus test] 61594: regressions - trouble: broken/fail/pass

flight 61594 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/61594/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl 14 guest-saverestore fail REGR. vs. 59254

Re: [Xen-devel] [Patch V1 1/3] xen: introduce dummy system device

On 09/07/2015 05:29 PM, Stefano Stabellini wrote: On Thu, 3 Sep 2015, Juergen Gross wrote: Introduce a new dummy system device serving as parent for virtual buses. This will enable new pv backends to introduce virtual buses which are removable again opposed to system buses which are meant to

Re: [Xen-devel] On distro packaging of stub domains (Re: Notes from Xen BoF at Debconf15)

On Tue, 2015-09-08 at 18:38 +, Antti Kantee wrote: > On 08/09/15 16:15, Ian Campbell wrote: > > On Tue, 2015-09-08 at 15:03 +, Antti Kantee wrote: > > > > > For unikernels, the rump kernel project provides Rumprun, which can > > > provide you with a near-full POSIX'y interface. > > > >

Re: [Xen-devel] [PATCH v4 10/11] x86/intel_pstate: support the use of intel_pstate in pmstat.c

>>> On 09.09.15 at 11:35, wrote: > Using the drinking vessel analogy, we are not putting milk and water into > the vessel at the same time. If the producer puts water into the vessel, then > the consumer simply consumes water; If the producer puts milk into the > vessel,

Re: [Xen-devel] [PATCH net] xen-netback: respect user provided max_queues

On Wed, Sep 09, 2015 at 11:12:44AM +0100, David Vrabel wrote: > On 09/09/15 11:09, Wei Liu wrote: > > Originally that parameter was always reset to num_online_cpus during > > module initialisation, which renders it useless. > > > > The fix is to only set max_queues to num_online_cpus when user

[Xen-devel] [PATCH net v2 0/2] xen-net{front, back}: respect user provided max_queues

Wei Liu (2): xen-netback: respect user provided max_queues xen-netfront: respect user provided max_queues drivers/net/xen-netback/netback.c | 7 +-- drivers/net/xen-netfront.c| 7 +-- 2 files changed, 10 insertions(+), 4 deletions(-) -- 2.1.4

[Xen-devel] [PATCH net v2 2/2] xen-netfront: respect user provided max_queues

Originally that parameter was always reset to num_online_cpus during module initialisation, which renders it useless. The fix is to only set max_queues to num_online_cpus when user has not provided a value. Signed-off-by: Wei Liu Cc: David Vrabel

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

On Wed, 2015-09-09 at 01:06 -0600, Jan Beulich wrote: > > > > On 09.09.15 at 00:23, wrote: > > On 09/08/15 19:26, Anthony PERARD wrote: > > > And I get this on the console: > > > Welcome to GRUB! > > > > > > X64 Exception Type - 0E(#PF - Page-Fault) CPU Apic ID - > > >

Re: [Xen-devel] [xen-unstable test] 61521: regressions - FAIL

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 61521: regressions - FAIL"): > On Tue, 2015-09-08 at 17:13 +0100, Ian Jackson wrote: > > I have looked a the histories of various `debianhvm' tests in many > > other osstest `branches' and there do seem to be occasional similar > >

Re: [Xen-devel] [PATCH v4 10/11] x86/intel_pstate: support the use of intel_pstate in pmstat.c

On 09/09/2015 18:10, Jan Beulich wrote: >>> On 09.09.15 at 11:35, wrote: >> Using the drinking vessel analogy, we are not putting milk and water >> into the vessel at the same time. If the producer puts water into the >> vessel, then the consumer simply consumes water; If

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

On 09/09/15 11:37, Ian Campbell wrote: > On Wed, 2015-09-09 at 01:06 -0600, Jan Beulich wrote: > On 09.09.15 at 00:23, wrote: >>> On 09/08/15 19:26, Anthony PERARD wrote: And I get this on the console: Welcome to GRUB! X64 Exception Type - 0E(#PF -

Re: [Xen-devel] [PATCH] x86/hvm: fix saved pmtimer value

On Wed, Sep 09, 2015 at 01:46:35AM -0600, Jan Beulich wrote: > >>> On 09.09.15 at 09:31, wrote: > > The ACPI PM timer is sometimes broken on live migration. > > Since vcpu->arch.hvm_vcpu.guest_time is zero in most cases. > > I.e. in other than "delay for missed ticks mode".

Re: [Xen-devel] [PATCH net v2 2/2] xen-netfront: respect user provided max_queues

On 09/09/15 11:23, Wei Liu wrote: > Originally that parameter was always reset to num_online_cpus during > module initialisation, which renders it useless. > > The fix is to only set max_queues to num_online_cpus when user has not > provided a value. Reviewed-by: David Vrabel

Re: [Xen-devel] [PATCH net] xen-netback: respect user provided max_queues

On Wed, 2015-09-09 at 11:16 +0100, Wei Liu wrote: > On Wed, Sep 09, 2015 at 11:12:44AM +0100, David Vrabel wrote: > > On 09/09/15 11:09, Wei Liu wrote: > > > Originally that parameter was always reset to num_online_cpus during > > > module initialisation, which renders it useless. > > > > > > The

Re: [Xen-devel] [PATCHv1 net] xen-netback: require fewer guest Rx slots when not using GSO

On Tue, Sep 08, 2015 at 02:25:14PM +0100, David Vrabel wrote: > Commit f48da8b14d04ca87ffcffe68829afd45f926ec6a (xen-netback: fix > unlimited guest Rx internal queue and carrier flapping) introduced a > regression. > > The PV frontend in IPXE only places 4 requests on the guest Rx ring. > Since

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

On Wed, 2015-09-09 at 12:48 +0200, Laszlo Ersek wrote: Thanks for all the info, I think I get it (although its not clear to me whether how an app can claim to be UEFI 2.5 capable and what the transition plan for legacy applications was going to be). > ... The question could be then if grub (in

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

On 09/09/15 13:07, Ian Campbell wrote: > On Wed, 2015-09-09 at 12:48 +0200, Laszlo Ersek wrote: > > Thanks for all the info, I think I get it (although its not clear to me > whether how an app can claim to be UEFI 2.5 capable and what the transition > plan for legacy applications was going to

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

On 09/09/15 13:30, Paolo Bonzini wrote: > > > On 09/09/2015 13:07, Ian Campbell wrote: >> I have a question: What attack vector is setting the stack as Nx in OVMF >> (or even UEFI generally) trying to protect against? Or is this being done >> for a reason other than security? >> >> I understand

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

On 09/09/15 09:06, Jan Beulich wrote: On 09.09.15 at 00:23, wrote: >> On 09/08/15 19:26, Anthony PERARD wrote: >>> And I get this on the console: >>> Welcome to GRUB! >>> >>> X64 Exception Type - 0E(#PF - Page-Fault) CPU Apic ID - >>> RIP -

Re: [Xen-devel] [PATCH v4 10/11] x86/intel_pstate: support the use of intel_pstate in pmstat.c

On 09/09/2015 17:02, Jan Beulich wrote: >>> On 09.09.15 at 10:49, wrote: > On 09/09/2015 16:32, Jan Beulich wrote: On 09.09.15 at 10:11, wrote: >> On 24/07/2015 22:16, Jan Beulich wrote: > On 25.06.15 at 13:17, wrote:

Re: [Xen-devel] [Xen-users] Xen bridging issue.

On 09/09/2015 12:35 PM, Wei Liu wrote: On Wed, Sep 09, 2015 at 10:09:09AM +0300, johnny Strom wrote: [...] Hello again I am not sure but there might be another issue with the xen_netback module in Debian jessie. I am not able to set the max_queues options so that it is set at load time. I

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

>>> On 09.09.15 at 11:37, wrote: > I'm not 100% what is going on, but if this (executable code on stack) is > happening in grub is there something which is explicitly forbidden to UEFI > apps by the UEFI spec? Whether it's spelled out explicitly I don't know, but the

Re: [Xen-devel] [PATCH net] xen-netback: respect user provided max_queues

On 09/09/15 11:09, Wei Liu wrote: > Originally that parameter was always reset to num_online_cpus during > module initialisation, which renders it useless. > > The fix is to only set max_queues to num_online_cpus when user has not > provided a value. [...] > ---

Re: [Xen-devel] [PATCH v6 16/18] vmx: Add some scheduler hooks for VT-d posted interrupts

>>> On 09.09.15 at 10:56, wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: Monday, September 07, 2015 8:55 PM >> >>> On 25.08.15 at 03:57, wrote: >> > @@ -1605,9 +1621,12 @@ void context_switch(struct vcpu *prev, struct >> vcpu *next) >> > >>

Re: [Xen-devel] [Patch V1 2/3] xen/usb: add capability for passing through isoc jobs to host devices

On 09/04/2015 03:25 PM, Gerd Hoffmann wrote: On Do, 2015-09-03 at 12:45 +0200, Juergen Gross wrote: When Xen is using the qemu usb framework for pure passthrough of I/Os to host devices the handling of isoc jobs is rather complicated if multiple isoc frames are transferred with one call.

[Xen-devel] [xen-4.4-testing test] 61599: regressions - FAIL

flight 61599 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/61599/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qcow2 9 debian-di-install fail REGR. vs. 60727

[Xen-devel] linux-3.4 broken on chardonnay and huxelrebe (Re: [linux-3.4 test] 61301: regressions - FAIL)

On Fri, 2015-09-04 at 08:58 +, osstest service owner wrote: > flight 61301 linux-3.4 real [real] > http://logs.test-lab.xenproject.org/osstest/logs/61301/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: >

[Xen-devel] [PATCH net] xen-netback: respect user provided max_queues

Originally that parameter was always reset to num_online_cpus during module initialisation, which renders it useless. The fix is to only set max_queues to num_online_cpus when user has not provided a value. Reported-by: Johnny Strom Signed-off-by: Wei Liu

Re: [Xen-devel] [Patch V1 2/3] xen/usb: add capability for passing through isoc jobs to host devices

Hi, > > So, the signaling needs to be different. The host adapter needs to > > signal somehow that it can handle async iso packets. One way would be > > to flag this per usb bus, another one per usb packet. Also all xen > > naming and the xen inlude should go away. BTW: does this build

Re: [Xen-devel] [PATCH v6 04/31] xen/arm: Set nr_cpu_ids to available number of cpus

On Mon, 2015-08-31 at 15:25 +0100, Julien Grall wrote: > title: Set nr_cpu_ids to the number of CPUs available > > On 31/08/2015 12:06, vijay.kil...@gmail.com wrote: > > From: Vijaya Kumar K > > > > nr_cpu_ids for arm platforms is set to NR_CPUS irrespective of

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

>>> On 09.09.15 at 12:48, wrote: > Personally I think that this dynamic approach is overkill (mainly > because I'm fine with being unable to install Debian Wheezy guests, both > wearing and not wearing my red fedora; and because the properties table > feature is not active for

[Xen-devel] ANNOUNCEMENT: Xen 4.6 RC3

Hi all Xen 4.6 RC3 has been tagged. You can check out the tag 4.6.0-rc3 in xen.git. The tarball can be downloaded from: http://bits.xensource.com/oss-xen/release/4.6.0-rc3/xen-4.6.0-rc3.tar.gz Signature for tarball: http://bits.xensource.com/oss-xen/release/4.6.0-rc3/xen-4.6.0-rc3.tar.gz.sig

Re: [Xen-devel] On distro packaging of stub domains (Re: Notes from Xen BoF at Debconf15)

Ian, Thank you for the explanations. Hmm. (not replying to anything specific) My guess is that shared libs won't be the biggest problem. I'd find it extremely surprising if you can take a Linux (or any other !NetBSD) packaging system and discover the dozens of dependencies of QEMU to not

Re: [Xen-devel] [PATCH v6 11/29] xen/x86: add bitmap of enabled emulated devices

On Fri, Sep 04, 2015 at 02:08:50PM +0200, Roger Pau Monne wrote: > Introduce a bitmap in x86 xen_arch_domainconfig that allows enabling or > disabling specific devices emulated inside of Xen for HVM guests. > > Signed-off-by: Roger Pau Monné > Reviewed-by: Andrew Cooper

Re: [Xen-devel] [PATCH] xen/domctl: lower loglevel of XEN_DOMCTL_memory_mapping

>>> On 09.09.15 at 16:20, wrote: > Perhaps the solution is remove the first printk(s) and just have them > once the operation has completed? That may fix the outstanding tasklet > problem? Considering that this is a tool stack based retry, how would the hypervisor know

Re: [Xen-devel] [PATCH v6 09/31] xen/arm: ITS: Add APIs to add and assign device

On 09/09/15 14:28, Ian Campbell wrote: > On Thu, 2015-09-03 at 18:34 +0100, Julien Grall wrote: >> @@ -522,6 +535,205 @@ static void its_lpi_free(struct its_device *dev) >>> xfree(dev->event_map.lpi_map); >>> } >>> >>> +static void its_discard_lpis(struct its_device *dev, u32 ids) >>> +{

Re: [Xen-devel] [PATCH v4 10/11] x86/intel_pstate: support the use of intel_pstate in pmstat.c

>>> On 09.09.15 at 14:56, wrote: > Can you please explain more why it doesn't scale? > From my point of view, any other future value representation can be passed > from the producer to the related consumer through this method. Did you read all of my earlier replies? I

Re: [Xen-devel] [PATCH v2 0/4] Intel Code/Data Prioritization(CDP) feature enabling

On Wed, 2015-09-09 at 15:37 +0800, Chao Peng wrote: > On Wed, Sep 09, 2015 at 01:16:44PM +0800, He Chen wrote: > > Changes in v2: > > - x86: Enable CDP by boot parameter instead of enabling/disabling CDP > > at > > runtime (suggested by Andrew) > > As you added a new boot option, you also need a

Re: [Xen-devel] [PATCH v4 10/11] x86/intel_pstate: support the use of intel_pstate in pmstat.c

On 09/09/2015 19:57, Jan Beulich wrote: >>> On 09.09.15 at 12:35, wrote: > On 09/09/2015 18:10, Jan Beulich wrote: On 09.09.15 at 11:35, wrote: >>> Using the drinking vessel analogy, we are not putting milk and water >>>into the vessel at the

Re: [Xen-devel] [PATCH v6 05/31] xen/arm: Rename NR_IRQs and vgic_num_irqs helper function

On Mon, 2015-08-31 at 15:40 +0100, Julien Grall wrote: > [...] > > +#define nr_irqs NR_LINE_IRQS > > +#define nr_static_irqs NR_LINE_IRQS > > +#define arch_hwdom_irqs(domid) NR_LINE_IRQS An aside: While looking at this patch I realised that all of these are used by common code solely in relation

Re: [Xen-devel] [PATCH v6 08/31] xen/arm: ITS: Introduce msi_desc for LPIs

On Mon, 2015-08-31 at 16:36 +0530, vijay.kil...@gmail.com wrote: > From: Vijaya Kumar K > > Define msi_desc structure for arm and introduce > helper functions to access msi_desc member variables. > > Signed-off-by: Vijaya Kumar K

Re: [Xen-devel] [PULL 0/19] xen-2015-09-08-tag

On Tue, 8 Sep 2015, Peter Maydell wrote: > On 8 September 2015 at 18:21, Stefano Stabellini > wrote: > > The following changes since commit 8611280505119e296757a60711a881341603fa5a: > > > > target-microblaze: Use setcond for pcmp* (2015-09-08 08:49:33 +0200) >

Re: [Xen-devel] [PATCH v6 05/31] xen/arm: Rename NR_IRQs and vgic_num_irqs helper function

On 09/09/15 14:08, Ian Campbell wrote: > On Mon, 2015-08-31 at 15:40 +0100, Julien Grall wrote: >> [...] >>> +#define nr_irqs NR_LINE_IRQS >>> +#define nr_static_irqs NR_LINE_IRQS >>> +#define arch_hwdom_irqs(domid) NR_LINE_IRQS > > An aside: While looking at this patch I realised that all of

Re: [Xen-devel] [PATCH v6 08/31] xen/arm: ITS: Introduce msi_desc for LPIs

On 09/09/15 14:16, Ian Campbell wrote: > On Mon, 2015-08-31 at 16:36 +0530, vijay.kil...@gmail.com wrote: >> From: Vijaya Kumar K >> >> Define msi_desc structure for arm and introduce >> helper functions to access msi_desc member variables. >> >> Signed-off-by:

[Xen-devel] Xen 4.6 branched, unstable reopen for new contributions

Hi all Xen 4.6 has been branched and xen-unstable is reopen to new contributions. The commit moratorium is now lifted. Committers can now commit any remaining patches to both branches. Note that Xen 4.6 is not yet out released, please consider the impact on Xen 4.6 branch when applying new

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

On 09/09/15 14:08, Jan Beulich wrote: On 09.09.15 at 12:48, wrote: >> Personally I think that this dynamic approach is overkill (mainly >> because I'm fine with being unable to install Debian Wheezy guests, both >> wearing and not wearing my red fedora; and because the

Re: [Xen-devel] [Patch V1 2/3] xen/usb: add capability for passing through isoc jobs to host devices

On 09/09/2015 02:01 PM, Gerd Hoffmann wrote: Hi, So, the signaling needs to be different. The host adapter needs to signal somehow that it can handle async iso packets. One way would be to flag this per usb bus, another one per usb packet. Also all xen naming and the xen inlude should go

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

>>> On 09.09.15 at 15:04, wrote: > On 09/09/15 14:08, Jan Beulich wrote: > On 09.09.15 at 12:48, wrote: >> However, I would want to suggest an even more dynamic approach: >> Assuming that within the core UEFI code it ought to be possible to >> flip

Re: [Xen-devel] [Patch V1 3/3] xen: add pvUSB backend

On Wed, 9 Sep 2015, Juergen Gross wrote: > On 09/07/2015 07:38 PM, Stefano Stabellini wrote: > > On Thu, 3 Sep 2015, Juergen Gross wrote: > > > Add a backend for para-virtualized USB devices for xen domains. > > > > > > The backend is using host-libusb to forward USB requests from a > > > domain

Re: [Xen-devel] [PATCH v6 09/31] xen/arm: ITS: Add APIs to add and assign device

On Thu, 2015-09-03 at 18:34 +0100, Julien Grall wrote: > @@ -522,6 +535,205 @@ static void its_lpi_free(struct its_device *dev) > > xfree(dev->event_map.lpi_map); > > } > > > > +static void its_discard_lpis(struct its_device *dev, u32 ids) > > +{ > > +int i; > > + > > I would have

Re: [Xen-devel] [PATCH v6 24/31] xen/arm: ITS: Add GICR register emulation

On Mon, 2015-09-07 at 20:56 +0530, Vijay Kilari wrote: > On Mon, Sep 7, 2015 at 7:50 PM, Julien Grall > wrote: > > Hi Vijay, > > > > On 31/08/15 12:06, vijay.kil...@gmail.com wrote: > > > +static int vgic_v3_gits_lpi_mmio_read(struct vcpu *v, mmio_info_t > > > *info) > >

Re: [Xen-devel] [PATCH] xen/domctl: lower loglevel of XEN_DOMCTL_memory_mapping

On Wed, Sep 09, 2015 at 02:50:25PM +0800, Tiejun Chen wrote: > We should lower loglevel to XENLOG_G_DEBUG while mapping or > unmapping memory via XEN_DOMCTL_memory_mapping since its > fair enough to check this info just while debugging. The issue you folks are hitting where it takes eons to boot

[Xen-devel] [raisin][PATCH 2/3] Delete dangling white space

Signed-off-by: Doug Goldstein --- lib/commands.sh | 4 ++-- lib/common-functions.sh | 10 +- scripts/mkdeb | 8 scripts/mkrpm | 4 ++-- tests/busybox-hvm | 8 tests/busybox-hvm-migrate | 4 ++--

[Xen-devel] [raisin][PATCH 3/3] Fix up coding style

Signed-off-by: Doug Goldstein --- lib/git-checkout.sh | 26 +- scripts/mkdeb | 22 +++--- 2 files changed, 24 insertions(+), 24 deletions(-) diff --git a/lib/git-checkout.sh b/lib/git-checkout.sh index 2ca8f25..d462453 100755 ---

[Xen-devel] [raisin][PATCH 1/3] Handle unsupported distros with a prettier message

Handle unknown distros by saying "unknown" instead of an empty string and for Gentoo users actually mention it. Signed-off-by: Doug Goldstein --- lib/common-functions.sh | 4 1 file changed, 4 insertions(+) diff --git a/lib/common-functions.sh b/lib/common-functions.sh

Re: [Xen-devel] [PATCH OSSTEST v2 0/6] Have OpenStack tested on top of xen's master and libvirt's master.

On Thu, 2015-08-06 at 18:03 +0100, Anthony PERARD wrote: > Anthony PERARD (6): > ts-kernel-build: Enable CONFIG_NETFILTER_XT_TARGET_CHECKSUM > ts-kernel-build: Compile CONFIG_CRYPTO_XTS in > ts-xen-install: Add dom0_mem runvar to control dom0 memory I stuck these 3 into osstest's pretest

Re: [Xen-devel] [PATCH OSSTEST v3 2/2] cambridge: arrange to test each new baseline

On Thu, 2015-08-13 at 19:07 +0100, Ian Jackson wrote: > Ian Campbell writes ("[PATCH OSSTEST v3 2/2] cambridge: arrange to test > each new baseline"): > > Provide a new cr-daily-branch setting OSSTEST_BASELINES_ONLY which > > causes it to only attempt to test the current baseline (if it is > >

Re: [Xen-devel] EDK II & GPL - Re: [edk2] OVMF BoF @ KVM Forum 2015

On 09/09/15 18:17, Jordan Justen wrote: > On 2015-09-09 01:57:51, Laszlo Ersek wrote: >> On 08/10/15 18:24, Laszlo Ersek wrote: >>> Hi. >>> >>> Let's do an OVMF BoF at this year's KVM Forum too. >> >> Here's a preliminary task list, after some off-list discussion (I tried >> to incorporate

Re: [Xen-devel] [PATCH] xen/domctl: lower loglevel of XEN_DOMCTL_memory_mapping

>>> On 09.09.15 at 16:50, wrote: > On Wed, Sep 09, 2015 at 08:33:52AM -0600, Jan Beulich wrote: >> >>> On 09.09.15 at 16:20, wrote: >> > Perhaps the solution is remove the first printk(s) and just have them >> > once the operation has completed?

Re: [Xen-devel] [PATCH v6 00/31] Add ITS support

On Mon, 2015-08-31 at 16:36 +0530, vijay.kil...@gmail.com wrote: > Some Major TODOs: >1) Avoid making vits_process_cmd() static in later point of time >2) How to handle LPI that does not have LPI config table entry. >3) Enable/disable ITS to Dom0 I'm not quite sure what any of these

Re: [Xen-devel] [PATCH OSSTEST] Osstest/TestSupport: Hide $ho->{Toolstack} from casual use

Ian Campbell writes ("[PATCH OSSTEST] Osstest/TestSupport: Hide $ho->{Toolstack} from casual use"): > This should only be accessed via toolstack($ho), which is responsible > for caching the value. Rename the field to _Toolstack to deter code > from using it. Acked-by: Ian Jackson

Re: [Xen-devel] [PULL 0/19] xen-2015-09-08-tag

On Wed, 9 Sep 2015, Stefano Stabellini wrote: > On Tue, 8 Sep 2015, Peter Maydell wrote: > > On 8 September 2015 at 18:21, Stefano Stabellini > > wrote: > > > The following changes since commit > > > 8611280505119e296757a60711a881341603fa5a: > > > > > >

Re: [Xen-devel] [PATCH v2] Remove XenPTReg->data and use dev.config for guest configuration values.

On Tue, Sep 08, 2015 at 06:22:13PM +0100, Stefano Stabellini wrote: > Now that is fully Acked, could you please rebase on > > http://marc.info/?i=alpine.DEB.2.02.1509081818590.2672%40kaball.uk.xensource.com > > and resend? I've rebased it (and put in your Reviewed-by tags) and stuck it in:

Re: [Xen-devel] [PATCH v6 31/31] xen/arm: ITS: Add pci devices in ThunderX

On Mon, 2015-08-31 at 16:36 +0530, vijay.kil...@gmail.com wrote: > [...] > +#define NUM_DEVIDS 54 > + > +static struct pci_dev_list bdf[NUM_DEVIDS] = FYI you could make this static struct pci_dev_list bdf[] = and use ARRAY_SIZE(bdf) in the loops. That would save you having to manually keep

Re: [Xen-devel] [PATCH] xen/domctl: lower loglevel of XEN_DOMCTL_memory_mapping

>>> On 09.09.15 at 17:19, wrote: > On 09/09/15 15:50, Konrad Rzeszutek Wilk wrote: >> On Wed, Sep 09, 2015 at 08:33:52AM -0600, Jan Beulich wrote: >> On 09.09.15 at 16:20, wrote: Perhaps the solution is remove the first printk(s) and

  1   2   >