On 12/01/2017 06:46, osstest service owner wrote:
> flight 104131 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/104131/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-xl-qemuu-debianhvm
>>> On 12.01.17 at 02:22, wrote:
> On 17-01-11 07:01:23, Jan Beulich wrote:
>> >>> On 11.01.17 at 07:22, wrote:
>> > On 17-01-10 08:15:15, Jan Beulich wrote:
>> >> >>> On 14.12.16 at 05:07, wrote:
>> >> > --- a/xen/arch/x86/psr.c
>> >> > +++ b/xen/arch/x86/psr.c
>> >> > @@ -186,6 +186,9 @@ struc
>>> On 11.01.17 at 21:29, wrote:
> On 01/11/2017 12:33 PM, Andrew Cooper wrote:
>> Coverity points out that x86_insn_modrm() returns -EINVAL for instructions
>> not
>> encoded with a ModRM byte. A consequence is that checking != 3 is
>> insufficient to confirm that &ext was actually written to.
>>> On 11.01.17 at 18:33, wrote:
> Coverity points out that x86_insn_modrm() returns -EINVAL for instructions not
> encoded with a ModRM byte. A consequence is that checking != 3 is
> insufficient to confirm that &ext was actually written to.
>
> In practice, this check is only used after decode
Hi All,
The library for userspace backends is under development now. It is not
ready to be published yet.
But you can check how it looks like at my github repository [1].
There are also sound and display backends based on this library [2], [3].
Comments are welcome.
Thanks.
[1] https://github.c
>>> On 11.01.17 at 18:57, wrote:
> --- a/xen/arch/x86/sysctl.c
> +++ b/xen/arch/x86/sysctl.c
> @@ -229,7 +229,10 @@ long arch_do_sysctl(
>
> /* Bad featureset index? */
> if ( !p )
> +{
> ret = -EINVAL;
> +break;
> +}
>
> cpui
On Tue, Jan 10, 2017 at 11:29:44AM -0800, Stefano Stabellini wrote:
> These are the minutes I took during the call:
>
> Xen PV Drivers Lifecycle document ready to be committed.
>
> Common Pitfalls for new PV protocols:
> - 32 vs 64 fields
> - not Linux centric
> - missing version fields and featu
On 17-01-12 02:40:41, Jan Beulich wrote:
> >>> On 12.01.17 at 02:22, wrote:
> > On 17-01-11 07:01:23, Jan Beulich wrote:
> >> >>> On 11.01.17 at 07:22, wrote:
> >> > On 17-01-10 08:15:15, Jan Beulich wrote:
> >> >> >>> On 14.12.16 at 05:07, wrote:
> >> >> > --- a/xen/arch/x86/psr.c
> >> >> > +++
>>> On 11.01.17 at 21:20, wrote:
> So do we really need to go down below 1MiB? We're never going into
> 16-bit mode. Unless the other CPUs are starting up in 16-bit mode.
Well, AP startup works by providing an 8-bit page number value
for where the processor should start fetching instructions.
Ja
On 11/01/17 15:56, Jan Beulich wrote:
On 11.01.17 at 16:40, wrote:
>> On 10/01/17 09:04, Jan Beulich wrote:
>>> @@ -1836,6 +1840,34 @@ static int inject_swint(enum x86_swint_t
>>> generate_exception(fault_type, error_code);
>>> }
>>>
>>> +static void adjust_bnd(struct x86_emulate_ctxt
On 12/01/17 10:13, Jan Beulich wrote:
On 11.01.17 at 18:57, wrote:
>> --- a/xen/arch/x86/sysctl.c
>> +++ b/xen/arch/x86/sysctl.c
>> @@ -229,7 +229,10 @@ long arch_do_sysctl(
>>
>> /* Bad featureset index? */
>> if ( !p )
>> +{
>> ret = -EINVAL;
>> +
flight 68358 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68358/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-i386-squeeze-netboot-pygrub 3 host-install(3) bro
flight 104140 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104140/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 32fd9c4150d0eaada633b6c35cc09c79d78ddaf8
baseline version:
ovmf bf3b7aae7100b60ff8a38
On 12/01/17 10:09, Jan Beulich wrote:
On 11.01.17 at 18:33, wrote:
>> Coverity points out that x86_insn_modrm() returns -EINVAL for instructions
>> not
>> encoded with a ModRM byte. A consequence is that checking != 3 is
>> insufficient to confirm that &ext was actually written to.
>>
>> In
>>> On 10.01.17 at 23:57, wrote:
> Changes in v13:
> - Implement feedback from Kevin Tian.
>https://lists.xenproject.org/archives/html/xen-devel/2015-10/msg03169.html
>https://lists.xenproject.org/archives/html/xen-devel/2015-10/msg03170.html
>https://lists.xenproject.org/archives/h
>>> On 12.01.17 at 12:31, wrote:
> On 12/01/17 10:09, Jan Beulich wrote:
> On 11.01.17 at 18:33, wrote:
>>> Coverity points out that x86_insn_modrm() returns -EINVAL for instructions
>>> not
>>> encoded with a ModRM byte. A consequence is that checking != 3 is
>>> insufficient to confirm th
On 12/01/17 11:46, Jan Beulich wrote:
On 12.01.17 at 12:31, wrote:
>> On 12/01/17 10:09, Jan Beulich wrote:
>> On 11.01.17 at 18:33, wrote:
Coverity points out that x86_insn_modrm() returns -EINVAL for instructions
not
encoded with a ModRM byte. A consequence is that che
On January 12, 2017 5:14 PM, Andrew Cooper wrote:
>On 12/01/2017 06:46, osstest service owner wrote:
>> flight 104131 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/104131/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking, including tests which
Hello,
Below is a draft of a design document for PVHv2 CPU hotplug. It should cover
both vCPU and pCPU hotplug. It's mainly centered around the hardware domain,
since for unprivileged PVH guests the vCPU hotplug mechanism is already
described in Boris series [0], and it's shared with HVM.
The aim
Hi,
On 05/01/17 22:10, Stefano Stabellini wrote:
> On Thu, 22 Dec 2016, Andre Przywara wrote:
>> Upon receiving an LPI, we need to find the right VCPU and virtual IRQ
>> number to get this IRQ injected.
>> Iterate our two-level LPI table to find this information quickly when
>> the host takes an L
On 12/01/17 12:07, Xuquan (Quan Xu) wrote:
> On January 12, 2017 5:14 PM, Andrew Cooper wrote:
>> On 12/01/2017 06:46, osstest service owner wrote:
>>> flight 104131 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/104131/
>>>
>>> Regressions :-(
>>>
>>> Tests which did
On Wed, Jan 11, 2017 at 02:31:35PM -0600, Doug Goldstein wrote:
> On 1/11/17 1:08 PM, Daniel Kiper wrote:
> > On Mon, Jan 09, 2017 at 07:37:59PM -0600, Doug Goldstein wrote:
> >> On 12/5/16 4:25 PM, Daniel Kiper wrote:
> >>> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> >>> index 0a9
>>> On 12.01.17 at 13:15, wrote:
> On 12/01/17 12:07, Xuquan (Quan Xu) wrote:
>> On January 12, 2017 5:14 PM, Andrew Cooper wrote:
>>> On 12/01/2017 06:46, osstest service owner wrote:
flight 104131 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104131/
>
Rename the x86 field to x86_family so its name actually reflects its meaning.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: George Dunlap
CC: Paul Durrant
CC: Boris Ostrovsky
CC: Suravee Suthikulpanit
CC: Jun Nakajima
CC: Kevin Tian
---
xen/ar
>>> On 12.01.17 at 05:47, wrote:
> --- a/xen/include/asm-x86/hvm/domain.h
> +++ b/xen/include/asm-x86/hvm/domain.h
> @@ -72,6 +72,38 @@ struct hvm_ioreq_server {
> bool_t bufioreq_atomic;
> };
>
> +/*
> + * This structure defines function hooks to support hardware-assisted
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 12 January 2017 12:33
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Tim (Xen.org) ; George Dunlap
> ; Paul Durrant ; Boris
> Ostrovsky ; Suravee Suthikulpanit
> ; Jun Nakajima
> ; Kevin Tian
> Su
On Wed, 2017-01-04 at 22:13 -0500, Boris Ostrovsky wrote:
> On 01/04/2017 09:10 PM, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jan 04, 2017 at 08:52:03PM -0500, Konrad Rzeszutek Wilk
> > wrote:
> > > I was trying to bootup on an 30 CPU machine (15 core, SMT).
> > >
> > > It works just fine with cred
On Wed, Jan 11, 2017 at 02:20:15PM -0600, Doug Goldstein wrote:
> On 1/11/17 1:47 PM, Daniel Kiper wrote:
> > On Tue, Jan 10, 2017 at 02:51:27PM -0600, Doug Goldstein wrote:
> >> On 1/9/17 7:37 PM, Doug Goldstein wrote:
> >>> On 12/5/16 4:25 PM, Daniel Kiper wrote:
> >>
> diff --git a/xen/arch
flight 104141 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104141/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 12233c19177d3971b657200778b681c6132e598b
baseline version:
ovmf 32fd9c4150d0eaada633b
>>> On 12.01.17 at 13:32, wrote:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -78,12 +78,11 @@ static void update_domain_cpuid_info(struct domain *d,
> switch ( ctl->input[0] )
> {
> case 0: {
> -int old_vendor = d->arch.x86_vendor;
> +int old_ven
flight 104136 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104136/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-xsm 4 host-build-prep fail REGR. vs. 104119
Regressions which
FPU insns writing to memory must not touch memory if they latch #MF (to
be delivered on the next waiting FPU insn). Note that inspecting FSW.ES
needs to be avoided for all FNST* insns, as they don't raise exceptions
themselves, but may instead be invoked with the bit already set.
Signed-off-by: Ja
On 12/01/17 13:40, Jan Beulich wrote:
On 12.01.17 at 13:32, wrote:
>> --- a/xen/arch/x86/domctl.c
>> +++ b/xen/arch/x86/domctl.c
>> @@ -78,12 +78,11 @@ static void update_domain_cpuid_info(struct domain *d,
>> switch ( ctl->input[0] )
>> {
>> case 0: {
>> -int old_vendo
1: conditionally clear BNDn for branches
2: support VME and PVI
3: use switch()-wide local variable 'cr4'
4: improve CR/DR access handling
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 12.01.17 at 15:02, wrote:
> I did make get_cpu_vendor() quite a lot better than it was previously,
> but it is still searching a loop. For the extra 3 bytes of data, I
> still think pre-calculating the values is worth it.
Well, as said, the question isn't the extra amount of data, but the
Considering that we surface MPX to HVM guests, instructions we emulate
should also correctly deal with MPX state. While for now BND*
instructions don't get emulated, the effect of branches (which we do
emulate) without BND prefix should be taken care of.
No need to alter XABORT behavior: While not
... affecting PUSHF, POPF, CLI, and STI.
Signed-off-by: Jan Beulich
---
v5: Add PUSHF adjustment. mode_pvi() -> mode_vif().
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -433,6 +433,8 @@ typedef union {
#define CR0_EM(1<<2)
#define CR0_TS(
On 12/01/17 14:13, Jan Beulich wrote:
On 12.01.17 at 15:02, wrote:
>> I did make get_cpu_vendor() quite a lot better than it was previously,
>> but it is still searching a loop. For the extra 3 bytes of data, I
>> still think pre-calculating the values is worth it.
> Well, as said, the quest
... rather than various smaller scope ones.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
v2: Re-base over PUSHF adjustment in earlier patch.
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -862,13 +862,10 @@ do {
#define put_fpu(_fic)
- don't accept LOCK for DR accesses (it's undefined in the manuals)
- only accept LOCK for CR accesses when the respective feature flag is
set (which would not normally be the case for Intel)
- add (rather than or) 8 when LOCK is present; real hardware #UDs
when both REX.W and LOCK are present,
On 12/01/17 14:15, Jan Beulich wrote:
> Considering that we surface MPX to HVM guests, instructions we emulate
> should also correctly deal with MPX state. While for now BND*
> instructions don't get emulated, the effect of branches (which we do
> emulate) without BND prefix should be taken care of
On 12/01/17 14:15, Jan Beulich wrote:
> ... affecting PUSHF, POPF, CLI, and STI.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
... HVMOP_set_pci_link_route
These HVMOPs were exposed to guests so their definitions need to be
preserved for compatibility. This patch therefore updates
__XEN_LATEST_INTERFACE_VERSION__ to 0x00040900 and makes the HVMOP
defintions conditional on __XEN_INTERFACE_VERSION__ less than that value.
N
...as a set of hypercalls to be used by a device model.
As stated in the new docs/designs/dm_op.markdown:
"The aim of DMOP is to prevent a compromised device model from
compromising domains other then the one it is associated with. (And is
therefore likely already compromised)."
See that file fo
The definitions of HVM_IOREQSRV_BUFIOREQ_* have to persist as they are
already in use by callers of the libxc interface.
Suggested-by: Jan Beulich
Signed-off-by: Paul Durrant
--
Reviewed-by: Jan Beulich
Cc: Ian Jackson
Acked-by: Wei Liu
Cc: Andrew Cooper
Cc: Daniel De Graaf
v3:
- Fix pad c
NOTE: This patch also modifies the types of the 'vector', 'type' and
'insn_len' arguments of xc_hvm_inject_trap() from uint32_t to
uint8_t. In practice the values passed were always truncated to
8 bits.
Suggested-by: Jan Beulich
Signed-off-by: Paul Durrant
---
Reviewed-by: Jan
Since injection works on a remote vCPU, and since there's no
enforcement of the subject vCPU being paused, there's a potential race
between the producing and consuming sides. Fix this by leveraging the
vector field as synchronization variable.
Signed-off-by: Jan Beulich
[re-based]
Signed-off-by:
Following on from the design submitted by Jennifer Herbert to the list [1]
this series provides an implementation of __HYPERCALL_dm_op followed by
patches based on Jan Beulich's previous HVMCTL series [2] to convert
tools-only HVMOPs used by device models to DMOPs.
[1] https://lists.xenproject.org
This patch introduces code to handle DMOP continuations.
NOTE: This patch also modifies the type of the 'nr' argument of
xc_hvm_modified_memory() from uint64_t to uint32_t. In practice the
value passed was always truncated to 32 bits.
Suggested-by: Jan Beulich
Signed-off-by: Paul Dur
This patch removes the need for handling HVMOP restarts, so that
infrastructure is removed.
NOTE: This patch also modifies the type of the 'nr' argument of
xc_hvm_set_mem_type() from uint64_t to uint32_t. In practice the
value passed was always truncated to 32 bits.
Suggested-by: Jan
The handle type passed to the underlying shadow and hap functions is
changed for compatibility with the new hypercall buffer.
NOTE: This patch also modifies the type of the 'nr' parameter of
xc_hvm_track_dirty_vram() from uint64_t to uint32_t. In practice
the value passed was always tr
On 12/01/17 14:02, Jan Beulich wrote:
> FPU insns writing to memory must not touch memory if they latch #MF (to
> be delivered on the next waiting FPU insn). Note that inspecting FSW.ES
> needs to be avoided for all FNST* insns, as they don't raise exceptions
> themselves, but may instead be invoke
> case 0x8001:
> -c &= pv_featureset[FEATURESET_e1c];
> -d &= pv_featureset[FEATURESET_e1d];
> +c = p->extd.e1c;
This appears to crash guests Intel, at least for dom0.
p->extd.e1c is 0x3 and bit 1 is reserved on Intel.
I haven't traced it yet to exact place that
On 12/01/17 15:22, Boris Ostrovsky wrote:
>> case 0x8001:
>> -c &= pv_featureset[FEATURESET_e1c];
>> -d &= pv_featureset[FEATURESET_e1d];
>> +c = p->extd.e1c;
> This appears to crash guests Intel, at least for dom0.
Is this a PVH dom0? I can't see from this snippe
On 12/01/17 14:58, Paul Durrant wrote:
> ...as a set of hypercalls to be used by a device model.
>
> As stated in the new docs/designs/dm_op.markdown:
>
> "The aim of DMOP is to prevent a compromised device model from
> compromising domains other then the one it is associated with. (And is
> theref
Hi,
On 01/03/2017 12:33 PM, Dirk Behme wrote:
> On 20.12.2016 19:01, Julien Grall wrote:
>> Hi Andrii,
>>
>> On 20/12/2016 19:00, Andrii Anisov wrote:
>>> Sorry for the mess,
>>>
>>> I mean the xen-swiotlb issue on renesas board:
>>>
Bosch: problem with xen-swiotlb. It does not work properly
On 1/12/17 6:18 AM, Daniel Kiper wrote:
So as an aside, IMHO this is where the series should end and the next
set of patches should be a follow on.
>>>
>>> Hmmm... Why? If you do not apply rest of patches then MB2 does not
>>> work on all EFI platforms.
>>>
>>> Daniel
>>
>> So I sho
On 01/12/2017 10:31 AM, Andrew Cooper wrote:
> On 12/01/17 15:22, Boris Ostrovsky wrote:
>>> case 0x8001:
>>> -c &= pv_featureset[FEATURESET_e1c];
>>> -d &= pv_featureset[FEATURESET_e1d];
>>> +c = p->extd.e1c;
>> This appears to crash guests Intel, at least for dom0
This is a follow-up of commit cfd8983f03c7b2 ("x86, locking/spinlocks:
Remove ticket (spin)lock implementation"). The static_key structure
paravirt_ticketlocks_enabled is now removed as it is no longer used.
A simple build and boot test was done to verify it.
Signed-off-by: Waiman Long
---
arch
On 1/12/17 6:50 AM, Daniel Kiper wrote:
> On Wed, Jan 11, 2017 at 02:20:15PM -0600, Doug Goldstein wrote:
>> On 1/11/17 1:47 PM, Daniel Kiper wrote:
>>> On Tue, Jan 10, 2017 at 02:51:27PM -0600, Doug Goldstein wrote:
On 1/9/17 7:37 PM, Doug Goldstein wrote:
> On 12/5/16 4:25 PM, Daniel Kip
Le 09/01/2017 à 13:56, Christoph Hellwig a écrit :
> On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote:
>> Regularly, when a new header is created in include/uapi/, the developer
>> forgets to add it in the corresponding Kbuild file. This error is usually
>> detected after the release
flight 104144 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104144/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b494cf96e70f8640acd9288951be39a0f714f2be
baseline version:
ovmf 12233c19177d3971b6572
According the code around the assert:
movzbl %r14b, %esi 41 0f b6 f6
cmp %esi, %eax 39 f0
jle ... 7e 02
ud2 <0f> 0b
mov %rbx, %rdi 48 89 df
callq ... e8 51 20 00 00
mov $0x810, %eaxb8 10 08 00 00
so I think one is 0x38 %eax, the other is 0x
>>> On 12.01.17 at 16:04, wrote:
> On 12/01/17 14:02, Jan Beulich wrote:
>> Furthermore I think we have another issue with writes: If the write
>> faults, the FSW (or MXCSR, albeit there only for instructions we don't
>> emulate yet) register may have been updated already, so we'd need to
>> undo
> -Original Message-
[snip]
> > +
> > +struct xen_dm_op_buf {
> > +XEN_GUEST_HANDLE_64(void) h;
> > +uint32_t size;
> > +};
>
> Sorry to quibble, but there is a problem here which has only just
> occurred to me. This ABI isn't futureproof, and has padding at the end
> which affect
On 12/01/17 15:50, Boris Ostrovsky wrote:
> On 01/12/2017 10:31 AM, Andrew Cooper wrote:
>> On 12/01/17 15:22, Boris Ostrovsky wrote:
case 0x8001:
-c &= pv_featureset[FEATURESET_e1c];
-d &= pv_featureset[FEATURESET_e1d];
+c = p->extd.e1c;
>>> Thi
On 01/12/2017 07:50 AM, Dario Faggioli wrote:
> On Wed, 2017-01-04 at 22:13 -0500, Boris Ostrovsky wrote:
>> On 01/04/2017 09:10 PM, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Jan 04, 2017 at 08:52:03PM -0500, Konrad Rzeszutek Wilk
>>> wrote:
I was trying to bootup on an 30 CPU machine (15 core,
>>> On 12.01.17 at 17:10, wrote:
>> > +
>> > +struct xen_dm_op_buf {
>> > +XEN_GUEST_HANDLE_64(void) h;
>> > +uint32_t size;
>> > +};
>>
>> Sorry to quibble, but there is a problem here which has only just
>> occurred to me. This ABI isn't futureproof, and has padding at the end
>> which
>>> On 12.01.17 at 15:58, wrote:
> The definitions of HVM_IOREQSRV_BUFIOREQ_* have to persist as they are
> already in use by callers of the libxc interface.
>
> Suggested-by: Jan Beulich
> Signed-off-by: Paul Durrant
> --
> Reviewed-by: Jan Beulich
That's an odd placement ...
Jan
On 12/01/17 14:58, Paul Durrant wrote:
> Since injection works on a remote vCPU, and since there's no
> enforcement of the subject vCPU being paused, there's a potential race
> between the producing and consuming sides. Fix this by leveraging the
> vector field as synchronization variable.
>
> Sign
Le 12/01/2017 à 17:28, Jan Engelhardt a écrit :
> On Thursday 2017-01-12 16:52, Nicolas Dichtel wrote:
>
>> Le 09/01/2017 à 13:56, Christoph Hellwig a écrit :
>>> On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote:
Regularly, when a new header is created in include/uapi/, the dev
On Thursday 2017-01-12 16:52, Nicolas Dichtel wrote:
>Le 09/01/2017 à 13:56, Christoph Hellwig a écrit :
>> On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote:
>>> Regularly, when a new header is created in include/uapi/, the developer
>>> forgets to add it in the corresponding Kbuild
While VEX.R and VEX.X are guaranteed to be 1 in compatibility mode,
VEX.B can be encoded as zero, but would be ignored by the processor.
Since we emulate instructions in 64-bit mode, we need to force the
bit to 1 in order to not act on the wrong {X,Y,Z}MM register.
We must not, however, fiddle wit
>>> On 12.01.17 at 17:28, wrote:
> On 12/01/17 14:58, Paul Durrant wrote:
>> Since injection works on a remote vCPU, and since there's no
>> enforcement of the subject vCPU being paused, there's a potential race
>> between the producing and consuming sides. Fix this by leveraging the
>> vector fie
On 12/01/17 16:12, Jan Beulich wrote:
On 12.01.17 at 16:04, wrote:
>> On 12/01/17 14:02, Jan Beulich wrote:
>>> Furthermore I think we have another issue with writes: If the write
>>> faults, the FSW (or MXCSR, albeit there only for instructions we don't
>>> emulate yet) register may have bee
On Thu, 2017-01-12 at 11:22 -0500, Boris Ostrovsky wrote:
> On 01/12/2017 07:50 AM, Dario Faggioli wrote:
> > I don't think we do that any longer, and that may be part of the
> > reason
> > why we missed this one?
>
> I believe you needed to be on a multi-socket system to catch this
> bug.
> That'
On Mon, 2017-01-02 at 07:15 +, Michael Schinzel wrote:
> Good Morning,
>
I'm back, although, as anticipate, I can't be terribly useful, I'm
afraid...
> You can see, in default Xen configuration, the most important thing
> at read performance test -> 2414.92 MB/sec <- the used cache is half
> o
On 12/01/17 16:37, Jan Beulich wrote:
> While VEX.R and VEX.X are guaranteed to be 1 in compatibility mode,
> VEX.B can be encoded as zero, but would be ignored by the processor.
Really? That is unfortunate.
It would have been far more helpful for this to raise #UD, like the
other prohibited VEX
On Tue, Jan 10, 2017 at 01:35:39PM -0800, Laura Abbott wrote:
> This is v7 of the patches to add CONFIG_DEBUG_VIRTUAL for arm64. This is
> a simple reordering of patches from v6 per request of Will Deacon for ease
> of merging support for arm which depends on this series.
>
> Laura Abbott (11):
>
On 12/5/16 4:25 PM, Daniel Kiper wrote:
> Hi,
>
> I am sending eleventh version of multiboot2 protocol support for
> legacy BIOS and EFI platforms. This patch series release contains
> fixes for all known issues.
>
> The final goal is xen.efi binary file which could be loaded by EFI
> loader, mul
flight 104142 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104142/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm 11 guest-start fail REGR. vs. 104106
Regressions which
Eliminate memory leaks introduced several years ago by cleaning the queue
resources which are allocated on XenBus connection event. Namely, queue
structure array and pages used for IO rings.
vif->lock is used to protect statistics gathering agents from using the
queue structure during cleaning.
Si
> Ahh! found it. This is a side effect of starting to generate the dom0
> policy in Xen.
>
> Can you try this patch?
Intel/AMD HVM/PV 64/32bit all look good. So
Tested-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https:/
On 12/01/17 17:51, Igor Druzhinin wrote:
> Eliminate memory leaks introduced several years ago by cleaning the queue
> resources which are allocated on XenBus connection event. Namely, queue
> structure array and pages used for IO rings.
> vif->lock is used to protect statistics gathering agents fr
On Tue, Jan 19, 2016 at 2:35 PM, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH v2 5/5] libxl: Add explicit cast to
> libxl_psr_cat_set_cbm"):
>> On Tue, 2016-01-19 at 14:06 +, Ian Jackson wrote:
>> > * XEN_DOMCTL_PSR_CAT_OP_SET_L3_* (public/domctl.h)
>> > * enum xc_psr_cat_type (xen
Hi Stefano,
On 05/01/17 21:36, Stefano Stabellini wrote:
> On Thu, 22 Dec 2016, Andre Przywara wrote:
>> For the same reason that allocating a struct irq_desc for each
>> possible LPI is not an option, having a struct pending_irq for each LPI
>> is also not feasible. However we actually only need
Dario Faggioli writes ("Re: [Xen-devel] Xen 4.8 + Linux 4.9 + Credit2 = can't
bootup"):
> Maybe it's me misremembering/saying stupid things, but I recall that at
> some point we were testing some of the recent and in development Linux
> branches in OSSTest.
We used to, but no-one fixed any of the
On Thu, Jan 12, 2017 at 11:46:04AM -0600, Doug Goldstein wrote:
> On 12/5/16 4:25 PM, Daniel Kiper wrote:
> > Hi,
> >
> > I am sending eleventh version of multiboot2 protocol support for
> > legacy BIOS and EFI platforms. This patch series release contains
> > fixes for all known issues.
> >
> > Th
On 01/11/2017 06:36 PM, Stefano Stabellini wrote:
> The following commit:
>
> commit 72a9b186292d98494f26cfd24a1621796209
> Author: KarimAllah Ahmed
> Date: Fri Aug 26 23:55:36 2016 +0200
>
> xen: Remove event channel notification through Xen PCI platform device
>
> broke Linux when boot
Dario Faggioli writes ("Re: [Xen-devel] Xen 4.8 + Linux 4.9 + Credit2 = can't
bootup"):
> Anyway, we should have some multi-socket boxes on OSSTest, AFAICR.
I think we do but I haven't got a systematic way of answering that
question other than by manual eyeballing of the spec sheets.
IF there we
On Thu, 12 Jan 2017, Roger Pau Monné wrote:
> On Tue, Jan 10, 2017 at 11:29:44AM -0800, Stefano Stabellini wrote:
> > These are the minutes I took during the call:
> >
> > Xen PV Drivers Lifecycle document ready to be committed.
> >
> > Common Pitfalls for new PV protocols:
> > - 32 vs 64 fields
On Thu, 12 Jan 2017, Pooya.Keshavarzi wrote:
> > The other issue I heard about was some root file system corruptions after
> > two or three re-boots we haven't observed in the native Linux case. The
> > plan was to do some further analysis, first, before we blame Xen regarding
> > this, though.
On Thu, 12 Jan 2017, Andre Przywara wrote:
> On 05/01/17 22:10, Stefano Stabellini wrote:
> > On Thu, 22 Dec 2016, Andre Przywara wrote:
> >> Upon receiving an LPI, we need to find the right VCPU and virtual IRQ
> >> number to get this IRQ injected.
> >> Iterate our two-level LPI table to find this
On 12/01/17 12:13, Roger Pau Monné wrote:
> Hello,
>
> Below is a draft of a design document for PVHv2 CPU hotplug. It should cover
> both vCPU and pCPU hotplug. It's mainly centered around the hardware domain,
> since for unprivileged PVH guests the vCPU hotplug mechanism is already
> described in
Hi,
I have an example attached below where I believe that libxl_physinfo_to_json()
does not return all of the correct output. physinfo.c is the C program that
outputs the json string. physc.out is the output that I recieved. physgo.out
is the output I get using the golang bindings I'm creating f
Hi Stefano,
as just mentioned in my last reply, I missed that email last time. Sorry
for that.
Replying to the comments that still apply to the new drop ...
On 28/10/16 02:04, Stefano Stabellini wrote:
> On Wed, 28 Sep 2016, Andre Przywara wrote:
>> For the same reason that allocating a struct i
On Thu, 12 Jan 2017, Andre Przywara wrote:
> Hi Stefano,
>
> On 05/01/17 21:36, Stefano Stabellini wrote:
> > On Thu, 22 Dec 2016, Andre Przywara wrote:
> >> For the same reason that allocating a struct irq_desc for each
> >> possible LPI is not an option, having a struct pending_irq for each LPI
On 12/01/17 18:00, Boris Ostrovsky wrote:
>> Ahh! found it. This is a side effect of starting to generate the dom0
>> policy in Xen.
>>
>> Can you try this patch?
>
> Intel/AMD HVM/PV 64/32bit all look good. So
>
> Tested-by: Boris Ostrovsky
Does this mean that newer versions of Linux more picky
Hi,
On 12/01/17 19:15, Stefano Stabellini wrote:
> On Thu, 12 Jan 2017, Andre Przywara wrote:
>> Hi Stefano,
>>
>> On 05/01/17 21:36, Stefano Stabellini wrote:
>>> On Thu, 22 Dec 2016, Andre Przywara wrote:
For the same reason that allocating a struct irq_desc for each
possible LPI is no
On Thu, Jan 12, 2017 at 09:44:59AM -0600, Doug Goldstein wrote:
> On 1/12/17 6:18 AM, Daniel Kiper wrote:
> So as an aside, IMHO this is where the series should end and the next
> set of patches should be a follow on.
> >>>
> >>> Hmmm... Why? If you do not apply rest of patches then MB2 d
1 - 100 of 135 matches
Mail list logo
