On March 18, 2016 4:10pm, wrote:
> >>> On 18.03.16 at 04:19, wrote:
> > On March 17, 2016 8:34pm, George Dunlap
> wrote:
> >> On Thu, Mar 17, 2016 at 12:30 PM, George Dunlap
> >> wrote:
> >> > On Thu, Mar 17, 2016 at 6:54 AM, Quan Xu wrote:
> >> >> --- a/xen/arch/x86/mm/p2m-ept.c
> >> >> +++ b
flight 86993 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/86993/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684
test-amd64
This patches fix current timeout concern and also allow limited ATS support:
1. Reduce spin timeout to 1ms, which can be boot-time changed with
'vtd_qi_timeout'.
For example:
multiboot /boot/xen.gz ... vtd_qi_timeout=100 ...
2. Wrap a _sync version for all VT-d flush interfaces.
For consistency, we wrap a _sync version for all VT-d flush interfaces.
It simplifies caller logic and makes code more readable as well.
Signed-off-by: Quan Xu
---
xen/drivers/passthrough/vtd/extern.h | 2 +
xen/drivers/passthrough/vtd/qinval.c | 173 --
xen/d
If Device-TLB flush timed out, we would hide the target ATS
device and crash the domain owning this ATS device. If impacted
domain is hardware domain, just throw out a warning.
The hidden device should be disallowed to be further assigned
to any domain.
Signed-off-by: Quan Xu
---
xen/drivers/pa
Signed-off-by: Quan Xu
---
docs/misc/xen-command-line.markdown | 7 +++
xen/drivers/passthrough/vtd/qinval.c | 17 -
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index ca77e3b..384d
flight 86891 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/86891/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail
REGR. vs. 86454
test
flight 87061 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/87061/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-i386-xl-qemuu-ovm
On 03/23/2016 02:46 PM, Sarah Newman wrote:
> On 03/22/2016 11:03 PM, Sarah Newman wrote:
>> And nested xen.
>>
>> CPU: AMD Opteron 2352
>> Outer configuration: Xen4CentOS 6 xen 4.6.1-2.el6, linux
>> 3.18.25-18.el6.x86_64
>> Inner configuration: Xen4CentOS 6 xen 4.6.1-2.el6, linux
>> 3.18.25-19.e
flight 86882 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/86882/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254
build-amd64-rumpuserx
Just wanted to give a bit of a poke about this.
Currently running kernel 4.4.6 in a PV DomU and still occasionally
getting hangs.
Also stumbled across this that may be related:
https://lkml.org/lkml/2016/2/4/724
My latest hang shows:
[339844.594001] INFO: rcu_sched self-detected stall on
On Wed, Mar 23, 2016 at 05:18:39AM -0600, Jan Beulich wrote:
> >>> On 15.03.16 at 18:56, wrote:
> > +### XEN_SYSCTL_XSPLICE_LIST (2)
> > +
> > +Retrieve an array of abbreviated status and names of payloads that are
> > loaded in the
> > +hypervisor.
> > +
> > +The caller provides:
> > +
> > + * `
On Wed, Mar 23, 2016 at 07:51:29AM -0600, Jan Beulich wrote:
> >>> On 15.03.16 at 18:56, wrote:
> > --- a/xen/common/Kconfig
> > +++ b/xen/common/Kconfig
> > @@ -168,4 +168,15 @@ config SCHED_DEFAULT
> >
> > endmenu
> >
> > +# Enable/Disable xsplice support
> > +config XSPLICE
> > + bool "x
> >> > +#ifdef CONFIG_X86
> >> > +#include
> >> > +#endif
> >>
> >> Why?
> >
> > Otherwise the compilation will fail on ARM as they do not have exceptions
> > (and no asm/uaccess.h file)
>
> Well, the question was for the #include, not the #ifdef.
Ah, yes. And with the 'ex' being pointers it m
. fixed all of those ..
> > --- a/xen/xsm/flask/hooks.c
> > +++ b/xen/xsm/flask/hooks.c
> > @@ -1658,6 +1658,40 @@ static int flask_xen_version (uint32_t op)
> > }
> > }
> >
> > +static int flask_version_op (uint32_t op)
> > +{
> > +u32 dsid = domain_sid(current->domain);
> > +
> > +
flight 87031 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/87031/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 66399
build-i386-rumpuserxen
On 03/23/2016 09:27 AM, osstest service owner wrote:
> flight 87014 ovmf real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/87014/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-xl-qemuu-ovmf-amd64 9 de
On 03/22/2016 11:03 PM, Sarah Newman wrote:
> And nested xen.
>
> CPU: AMD Opteron 2352
> Outer configuration: Xen4CentOS 6 xen 4.6.1-2.el6, linux 3.18.25-18.el6.x86_64
> Inner configuration: Xen4CentOS 6 xen 4.6.1-2.el6, linux 3.18.25-19.el6.x86_64
> Inner xen command line: cpuinfo loglvl=all gu
7c8f3483 introduced a break within a loop in netfront.c such that
cons and nr_consumed were no longer always being incremented. The
offset at cons will be processed multiple times with the break in
place.
Remove the break and re-add "some !=0" in the loop for HAVE_LIBC.
Signed-off-by: Sarah Newma
On Wed, 2016-03-23 at 09:53 -0600, Toshi Kani wrote:
> On Wed, 2016-03-23 at 09:44 +0100, Borislav Petkov wrote:
> > On Tue, Mar 22, 2016 at 03:53:30PM -0600, Toshi Kani wrote:
> > > Yes. I had to remove this number since checkpatch complained that I
> > > needed to quote the whole patch tile again
flight 87027 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/87027/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs.
86491
test-amd64-amd6
get_mtrr_state() calls pat_init() on BSP even if MTRR is disabled.
This results in calling pat_init() on BSP only since APs do not call
pat_init() when MTRR is disabled. This inconsistency between BSP
and APs leads to undefined behavior.
Make BSP's calling condition to pat_init() consistent with
In preparation for fixing a regression caused by 'commit 9cd25aac1f44
("x86/mm/pat: Emulate PAT when it is disabled")', PAT needs to
support a case that PAT MSR is initialized with a non-default
value.
When pat_init() is called and PAT is disabled, it initializes
PAT table with the BIOS default va
Update PAT documentation to describe how PAT is initialized under
various configurations.
Signed-off-by: Toshi Kani
Cc: Borislav Petkov
Cc: Luis R. Rodriguez
Cc: Juergen Gross
Cc: Ingo Molnar
Cc: H. Peter Anvin
Cc: Thomas Gleixner
---
Documentation/x86/pat.txt | 32 ++
Borislav Petkov wrote:
> Please use on init paths boot_cpu_has(X86_FEATURE_PAT) and on fast
> paths static_cpu_has(X86_FEATURE_PAT). No more of that cpu_has_XXX
> ugliness.
Replace the use of cpu_has_pat on init paths with boot_cpu_has().
Suggested-by: Borislav Petkov
Signed-off-by: Toshi Kani
A Xorg failure on qemu32 was reported as a regression [1] caused by
'commit 9cd25aac1f44 ("x86/mm/pat: Emulate PAT when it is disabled")'.
This patch fixes this regression.
Negative effects of this regression were the following two failures [2]
in Xorg on QEMU with QEMU CPU model "qemu32" (-cpu qe
Xen supports PAT without MTRRs for its guests. In order to
enable WC attribute, it was necessary for xen_start_kernel()
to call pat_init_cache_modes() to update PAT table before
starting guest kernel.
Now that the kernel initializes PAT table to the BIOS handoff
state when MTRR is disabled, this
A Xorg failure on qemu32 was reported as a regression [1] caused by
'commit 9cd25aac1f44 ("x86/mm/pat: Emulate PAT when it is disabled")'.
This patch-set fixes the regression.
Negative effects of this regression were two failures [2] in Xorg on
QEMU with QEMU CPU model "qemu32" (-cpu qemu32), whic
In preparation for fixing a regression caused by 'commit 9cd25aac1f44
("x86/mm/pat: Emulate PAT when it is disabled")', PAT needs to
provide an interface that prevents the OS from initializing the
PAT MSR.
PAT MSR initialization must be done on all CPUs using the specific
sequence of operations de
> diff --git a/docs/misc/xsplice.markdown b/docs/misc/xsplice.markdown
> index 6aa5a27..8252e6c 100644
> --- a/docs/misc/xsplice.markdown
> +++ b/docs/misc/xsplice.markdown
> @@ -487,7 +487,9 @@ hypervisor.
> The caller provides:
>
> * `version`. Initially (on first hypercall) *MUST* be zero.
On Wed, Mar 23, 2016 at 05:18:39AM -0600, Jan Beulich wrote:
> >>> On 15.03.16 at 18:56, wrote:
> > +### XEN_SYSCTL_XSPLICE_LIST (2)
> > +
> > +Retrieve an array of abbreviated status and names of payloads that are
> > loaded in the
> > +hypervisor.
> > +
> > +The caller provides:
> > +
> > + * `
On 18/03/16 19:05, Dario Faggioli wrote:
> by using the sched_switch hook that we have introduced in
> the various schedulers.
>
> The key is to let the actual switch of scheduler and the
> remapping of the scheduler lock for the CPU (if necessary)
> happen together (in the same critical section)
On 3/23/16 11:34 AM, sabiya kazi wrote:
> Hi Doug,
> Can you have a look at patch and let me know if everything
> is correct, I think things are good.
>
> I would also like to have a word with you for deciding timeline for
> project. Meantime, I have started reading stuff about rust language.
>
On 23/03/16 12:25, Andrew Cooper wrote:
> On 23/03/16 11:18, David Vrabel wrote:
>> On 23/03/16 11:12, Andrew Cooper wrote:
>>> On 23/03/16 10:59, David Vrabel wrote:
On 23/03/16 10:55, Andrew Cooper wrote:
> On 23/03/16 10:52, Juergen Gross wrote:
>> On 23/03/16 11:32, David Vrabel wr
On Wed, Mar 23, 2016 at 01:45:37PM -0400, Zhigang Wang wrote:
> There should be 6 instead of 7 arguments now for tmem_control().
.. which was done in commit 54a51b1766fd433b95e63834eb15d4b1f70271de
"tmem: Remove xc_tmem_control mystical arg3"
but it missed the removal of an 'i'.
>
> Signed-o
On Wed, Mar 23, 2016 at 06:24:40PM +0100, Dirk Behme wrote:
> Hi,
Hey,
CC-ing the ARM MAINTAINERs.
>
> trying to bring up Xen on a new ARMv8 64-bit Cortex A57 eval board, I get
> [1] and then its hanging there.
>
> I'd guess that it hangs due to missing timer interrupt, maybe missing
> interru
On 3/23/16 11:34 AM, sabiya kazi wrote:
> Hi Doug,
> Can you have a look at patch and let me know if everything
> is correct, I think things are good.
>
> I would also like to have a word with you for deciding timeline for
> project. Meantime, I have started reading stuff about rust language.
>
Hey,
please, do not use HTML for emails to this list.
On Wed, 2016-03-23 at 17:38 +0100, Paulina Szubarczyk wrote:
> Hi,
>
> Thank you for the proposed tasks. I would like to work on the second
> one,
> fixing the return codes in xl.
>
I just wanted to say that, since I've done (and mentored)
Hi Stefano,
On 22/02/16 17:38, Stefano Stabellini wrote:
On Fri, 15 Jan 2016, Ian Campbell wrote:
I read the patch and looks good to me. You can add my
Reviewed-by: Stefano Stabellini
I have a couple of minor comments, which you can ignore or address as
you commit the patch.
This patch fel
On 23/03/16 17:51, George Dunlap wrote:
> On 18/03/16 19:04, Dario Faggioli wrote:
>> That will turn out useful in following patches, where such
>> code will need to be called more than just once. Create an
>> helper now, and move the code there, to avoid mixing code
>> motion and functional change
On 18/03/16 19:04, Dario Faggioli wrote:
> That will turn out useful in following patches, where such
> code will need to be called more than just once. Create an
> helper now, and move the code there, to avoid mixing code
> motion and functional changes later.
>
> In Credit2, some style cleanup i
There should be 6 instead of 7 arguments now for tmem_control().
Signed-off-by: Zhigang Wang
---
tools/python/xen/lowlevel/xc/xc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/python/xen/lowlevel/xc/xc.c
b/tools/python/xen/lowlevel/xc/xc.c
index c40a4e9..ff714d7 100
On 22/03/16 08:03, Juergen Gross wrote:
> On 18/03/16 20:04, Dario Faggioli wrote:
>> by borrowing some of the code of .alloc_pdata, i.e.,
>> the bits that perform initializations, leaving only
>> actual allocations in there, when any, which is the
>> case for Credit1 and RTDS.
>>
>> On the other h
(CC xen-user, BCC xen-devel)
On 23/03/16 10:23, Marwa Hamza wrote:
ello
Hello,
Please have a more meaningful subject. Also the question is not related
to development so the thread is moved to xen-users.
i'm trying to learn more about xen hypervisor .. i install xen in my
host with alpine
On 18/03/16 19:04, Dario Faggioli wrote:
> The .alloc_pdata scheduler hook must, before this change,
> be implemented by all schedulers --even those ones that
> don't need to allocate anything.
>
> Make it possible to just use the SCHED_OP(), like for
> the other hooks, by using ERR_PTR() and IS_E
On 21/03/16 14:22, Jan Beulich wrote:
On 18.03.16 at 20:04, wrote:
>> --- a/xen/include/xen/sched-if.h
>> +++ b/xen/include/xen/sched-if.h
>> @@ -9,6 +9,7 @@
>> #define __XEN_SCHED_IF_H__
>>
>> #include
>> +#include
>>
>> /* A global pointer to the initial cpupool (POOL0). */
>> ext
On 18/03/16 19:04, Dario Faggioli wrote:
> with the purpose of decoupling the allocation phase and
> the initialization one, for per-pCPU data of the schedulers.
>
> This makes it possible to perform the initialization later
> in the pCPU bringup/assignement process, when more information
> (for i
Hi,
trying to bring up Xen on a new ARMv8 64-bit Cortex A57 eval board, I
get [1] and then its hanging there.
I'd guess that it hangs due to missing timer interrupt, maybe missing
interrupts at all?
Any hints how to debug this? Or where to look?
It might be possible that the board's firmwa
Hi everyone,
I just wanted to let you know that this hasn't dropped off my radar. We do have
a shortlist of people now, and I will need to reach out to people who were
nominated (and may not know they were). However due to Easter, the time-frame
may slip by a week.
> On 24 Feb 2016, at 18:51,
All,
so I've just learned that Windows (at least some versions and some
of their code paths) use REP MOVSD to read/write the MSI-X table.
The way at least msixtbl_write() works is not compatible with this
(msixtbl_read() also seems affected, albeit to a lesser degree), and
apparently it just worke
It is conceptually wrong to base a VM's featureset on the features visible to
the toolstack which happens to construct it.
Instead, the featureset used is either an explicit one passed by the
toolstack, or the default which Xen believes it can give to the guest.
Collect all the feature manipulati
Signed-off-by: Andrew Cooper
Acked-by: Wei Liu
---
CC: Ian Jackson
New in v2
---
tools/libxc/Makefile | 9 ++
tools/libxc/include/xenctrl.h | 14
tools/libxc/xc_cpuid_x86.c| 75 +++
3 files changed, 98 insertions(+)
diff --git
A toolstack needs to know how much control Xen has over the visible cpuid
values in PV guests. Provide an explicit mechanism to query what Xen is
capable of.
This interface will currently report no capabilities. This change is
scaffolding for future patches, which will introduce detection and sw
It is unsafe to generate the guests xstate leaves from host information, as it
prevents the differences between hosts from being hidden.
In addition, some further improvements and corrections:
- don't discard the known flags in sub-leaves 2..63 ECX
- zap sub-leaves beyond 62
- zap all bits in l
Currently, {pv,hvm}_cpuid() has a large quantity of essentially-static logic
for modifying the features visible to a guest. A lot of this can be subsumed
by {pv,hvm}_featuremask, which identify the features available on this
hardware which could be given to a PV or HVM guest.
This is a step in th
Before c/s 44e24f8567 "x86: don't call generic_identify() redundantly", the
commandline-provided masks would take effect in Xen's view of the features.
As the masks got applied after the query for features, the redundant call to
generic_identify() would clobber the pre-masking feature information
APIC and XSAVE have dependent features, which also need disabling if Xen
chooses to disable a feature.
Use setup_clear_cpu_cap() rather than clear_bit(), as it takes care of
dependent features as well.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
v2: Move boolean_param() adjacent t
And provide stubs for toolstack use.
Signed-off-by: Andrew Cooper
Acked-by: Wei Liu
Acked-by: David Scott
Acked-by: Jan Beulich
---
CC: Tim Deegan
v2:
* Rebased to use libxencall
* Improve hypercall documentation
v3:
* Provide libxc implementation for XEN_SYSCTL_get_cpu_levelling_caps as
It is able to reports the current featuresets; both the static masks and
dynamic featuresets from Xen, or to decode an arbitrary featureset into
`/proc/cpuinfo` style strings.
Signed-off-by: Andrew Cooper
Acked-by: Wei Liu
---
CC: Ian Jackson
v2: No linking hackary
---
.gitignore
This patch is best reviewed as its end result rather than as a diff, as it
rewrites almost all of the setup.
On the BSP, cpuid information is used to evaluate the potential available set
of masking MSRs, and they are unconditionally probed, filling in the
availability information and hardware defa
And use them in preference to cpumask_defaults on context switch. HVM domains
must not be masked (to avoid interfering with cpuid calls within the guest),
so always lazily context switch to the host default.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
v2:
* s/cpumasks/cpuidmasks/
Rather than having a different local copy of some of the feature
definitions.
Modify the xc_cpuid_x86.c cpumask helpers to appropriate truncate the
new values.
As some of the feature have been renamed in the public API, similar renames
are made here.
Signed-off-by: Andrew Cooper
Acked-by: Wei L
A single ctxt_switch_levelling() function pointer is provided
(defaulting to an empty nop), which is overridden in the appropriate
$VENDOR_init_levelling().
set_cpuid_faulting() is made private and included within
intel_ctxt_switch_levelling().
One functional change is that the faulting configura
Later changes will cause the cpuid generation logic to seed their information
from a featureset. This patch adds the infrastructure to specify a
featureset, and will obtain the appropriate default from Xen if omitted.
Signed-off-by: Andrew Cooper
Acked-by: Wei Liu
---
CC: Ian Jackson
v2:
* M
This allows PV domains with different featuresets to observe different values
from a native cpuid instruction, on supporting hardware.
It is important to leak the host view of HTT and CMP_LEGACY through to guests,
even though they could be hidden. These flags affect how to interpret other
cpuid l
The type of the pointer to a bitmap is not interesting; it does not affect the
representation of the block of bits being pointed to.
Make the libxc functions consistent with those in Xen, so they can work just
as well with 'unsigned int *' based bitmaps.
As part of doing so, change the implementa
This patch is best reviewed as its end result rather than as a diff, as it
rewrites almost all of the setup.
On the BSP, cpuid information is used to evaluate the potential available set
of masking MSRs, and they are unconditionally probed, filling in the
availability information and hardware defa
When clearing a cpu cap, clear all dependent features. This avoids having a
featureset with intermediate features disabled, but leaf features enabled.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
v3:
* Style fixes. Use __test_and_set_bit()
---
xen/arch/x86/cpu/common.c | 16
Hi,
Thank you for the proposed tasks. I would like to work on the second one,
fixing the return codes in xl.
Regards,
Paulina Szubarczyk
On 23 March 2016 at 16:32, Roger Pau Monné wrote:
> Hello,
>
> First of all, thanks for your interest in the Xen Project, and for wanting
> to participate in
Some bits in a featureset are not simple a indication of new functionality,
and require special handling.
APIC, OSXSAVE and OSPKE are fast-forwards of other pieces of state;
IA32_APIC_BASE.EN, CR4.OSXSAVE and CR4.OSPKE. Xen will take care of filling
these appropriately at runtime.
FDP_EXCP_ONLY
Use attributes to specify whether a feature is applicable to be exposed to:
1) All guests
2) HVM guests
3) HVM HAP guests
and, via absence of an attribute, to no guests.
There is no current need for other categories (e.g. PV-only features), and
such categories should not be introduced if possib
This script consumes include/public/arch-x86/cpufeatureset.h and generates a
single include/asm-x86/cpuid-autogen.h containing all the processed
information.
It currently generates just FEATURESET_NR_ENTRIES. Future changes will
generate more information.
Signed-off-by: Andrew Cooper
Acked-by:
Some features depend on other features. Working out and maintaining the exact
dependency tree is complicated, so it is expressed in the automatic generation
script.
At runtime, Xen needs to be disable all features which are dependent on a
feature being disabled. Because of the flattening perform
This series is available in git form at:
http://xenbits.xen.org/git-http/people/andrewcoop/xen.git levelling-v4
There are no major changes from v3. There were minor adjustmenst to the
feature dependency tree, OSXSAVE/OSPKE handling for PV guests and collection
of Acks/Reviews.
Most patches do
If Xen doesn't know about a feature, it is unsafe for use and should be
deliberately hidden from Xen's capabilities.
This doesn't make a practical difference yet, but will make a difference
later when the guest featuresets are seeded from the host featureset.
Signed-off-by: Andrew Cooper
Acked-b
New words are:
* 0x8007.edx - Contains Invarient TSC
* 0x8008.ebx - Newly used for AMD Zen processors
In addition, replace some open-coded ITSC and EFRO manipulation.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
Reviewed-by: Konrad Rzeszutek Wilk
---
v2:
* Rely on ordering of
For the featureset to be a useful object, it needs a stable interpretation, a
property which is missing from the current hw_caps interface.
Additionly, introduce TSC_ADJUST, FDP_EXCP_ONLY, SHA, PREFETCHWT1, ITSC, EFRO
and CLZERO which will be used by later changes.
To maintain compilation, FSCAPI
All of this information will be used by the toolstack to make informed
levelling decisions for VMs, and by Xen to sanity check toolstack-provided
information.
Signed-off-by: Andrew Cooper
Reviewed-by: Konrad Rzeszutek Wilk
---
CC: Jan Beulich
v3:
* Move as much as possible into .init.
* Fix
Hi Doug,
Can you have a look at patch and let me know if everything
is correct, I think things are good.
I would also like to have a word with you for deciding timeline for
project. Meantime, I have started reading stuff about rust language.
Regards,
-Sabiya
diff --git a/tools/Makefile b/tool
> -Original Message-
[snip]
> > > >
> > > > For this part, there is ioctl() interface for all block device.
> > > > Looking at virtio-blk in KVM world, it can accept almost all SCSI
> commands
> > > also in ioctl() even they already have virtio-scsi.
> > > > But that's another story.
> > >
On Wed, 23 Mar 2016, Paul Durrant wrote:
> > -Original Message-
> [snip]
> > > > >
> > > > > For this part, there is ioctl() interface for all block device.
> > > > > Looking at virtio-blk in KVM world, it can accept almost all SCSI
> > commands
> > > > also in ioctl() even they already hav
On Wed, 23 Mar 2016, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monné [mailto:roger@citrix.com]
> > Sent: 23 March 2016 14:54
> > To: Bob Liu
> > Cc: Roger Pau Monne; xen-devel@lists.xen.org; Paul Durrant; Ian Jackson;
> > konrad.w...@oracle.com; jgr...@suse.com; ann
On 18/03/16 19:04, Dario Faggioli wrote:
> as doing that include changing the scheduler lock
> mapping for the pCPU itself, and the correct way
> of doing that is:
> - take the lock that the pCPU is using right now
>(which may be the lock of another scheduler);
> - change the mapping of the l
Hello,
First of all, thanks for your interest in the Xen Project, and for wanting
to participate in Outreachy.
Both of you have expressed interest in the "QEMU xen-blkback performance
analysis and improvements" Outreachy project, and AFAIK both of you still
need to perform your initial contrib
flight 87014 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/87014/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-i386-xl-qemuu-ovm
On Wed, 2016-03-23 at 09:44 +0100, Borislav Petkov wrote:
> On Tue, Mar 22, 2016 at 03:53:30PM -0600, Toshi Kani wrote:
> > Yes. I had to remove this number since checkpatch complained that I
> > needed to quote the whole patch tile again. I will ignore this
> > checkpatch error and add this commi
> -Original Message-
> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: 23 March 2016 14:54
> To: Bob Liu
> Cc: Roger Pau Monne; xen-devel@lists.xen.org; Paul Durrant; Ian Jackson;
> konrad.w...@oracle.com; jgr...@suse.com; annie...@oracle.com; David
> Vrabel
> Subject: Re: [PATC
On Wed, 2016-03-23 at 09:51 +0100, Borislav Petkov wrote:
> On Tue, Mar 22, 2016 at 03:40:45PM -0600, Toshi Kani wrote:
> > Will change to "Prevent the OS from initializing the PAT MSR".
> >
> > I wanted to clarify that "disable" does not mean to disable PAT MSR.
>
> How do you "disable PAT MSR"
On Wed, 2016-03-23 at 09:43 +0100, Borislav Petkov wrote:
> On Tue, Mar 22, 2016 at 12:35:19PM -0600, Toshi Kani wrote:
> > Right. Will change to "Add support of non-default PAT MSR setting at
> > handoff".
>
> Please remove this "handoff" notion from the text. Every hw register is
> being handed
On Wed, 23 Mar 2016, Bob Liu wrote:
> On 03/23/2016 08:33 PM, Roger Pau Monné wrote:
> > On Wed, 23 Mar 2016, Bob Liu wrote:
> >
> >> This patch documents a xenstore node which is used by XENVBD Windows PV
> >> driver.
> >>
> >> The use case is that XenServer may have OEM specific storage backends
flight 87036 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/87036/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
Paul Durrant writes ("RE: [PATCH] blkif.h: document scsi/0x12/0x node"):
> > From: Bob Liu [mailto:bob@oracle.com]
> > Sent: 23 March 2016 11:48
> > To: xen-devel@lists.xen.org
> > Cc: Paul Durrant; Ian Jackson; konrad.w...@oracle.com; jgr...@suse.com;
> > Roger Pau Monne; annie...@oracle.com;
>>> On 23.03.16 at 13:05, wrote:
> On 03/23/2016 07:28 AM, Jan Beulich wrote:
>> Sure - it seems quite obvious that all boot time available CPUs
>> should be checked.
> Cool, so I will go with moving init_xen_time right after all CPUs are up but
> before initcalls are invoked.
I think your other
>>> On 15.03.16 at 18:56, wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -168,4 +168,15 @@ config SCHED_DEFAULT
>
> endmenu
>
> +# Enable/Disable xsplice support
> +config XSPLICE
> + bool "xSplice live patching support"
> + default y
Isn't it a little early in the
On 03/23/2016 08:33 PM, Roger Pau Monné wrote:
> On Wed, 23 Mar 2016, Bob Liu wrote:
>
>> This patch documents a xenstore node which is used by XENVBD Windows PV
>> driver.
>>
>> The use case is that XenServer may have OEM specific storage backends and
>> there is requirement to run OEM software
On 03/23/2016 07:33 AM, Juergen Gross wrote:
On 23/03/16 11:55, Andrew Cooper wrote:
On 23/03/16 10:52, Juergen Gross wrote:
On 23/03/16 11:32, David Vrabel wrote:
On 23/03/16 10:25, Jan Beulich wrote:
On 23.03.16 at 11:14, wrote:
7. Report type according to features found (this is a little
On 12/03/16 11:34, Dario Faggioli wrote:
> so the trace will show properly decoded info,
> rather than just a bunch of hex codes.
>
> Signed-off-by: Dario Faggioli
> Reviewed-by: Konrad Rzeszutek Wilk
Acked-by: George Dunlap
> ---
> Cc: George Dunlap
> Cc: Meng Xu
> Cc: Tianyang Chen
> Cc:
On 12/03/16 11:33, Dario Faggioli wrote:
> (i.e., domain creation and destruction) so the
> trace will show properly decoded info, rather
> than just a bunch of hex codes.
> ---
For some reason git won't apply your 'v2', complaining: 'corrupt patch
at line 14'.
But re the content (i.e., this patc
On Wed, 23 Mar 2016, Bob Liu wrote:
> This patch documents a xenstore node which is used by XENVBD Windows PV
> driver.
>
> The use case is that XenServer may have OEM specific storage backends and
> there is requirement to run OEM software in guest which relied on VPD
> information supplied by t
This patch series is meant to be applied on top of Chunyan's series
to support pvusb in libxl.
It is adding support for an alternative pvusb backend "qusb" via qemu.
Changes in V3:
- added new patches 3 and 4 to at least report failure in case no device
model is running when adding devices to a
1 - 100 of 184 matches
Mail list logo
