flight 104175 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104175/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 15 guest-start/debian.repeat fail REGR. vs. 104170
Regressions which
flight 104176 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104176/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 3 host-install(3) broken REGR. vs. 104159
test-armhf-armhf-
On Sat, Jan 14, 2017 at 01:47:49AM +, Andrew Cooper wrote:
> On 13/01/2017 20:32, Marek Marczykowski-Górecki wrote:
> > On Fri, Jan 13, 2017 at 07:54:01PM +, Andrew Cooper wrote:
> >> This is a guest kernel bug. The guest kernel has used SMAP to say
> >> "please disallow all userspace acce
On 13/01/2017 20:32, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 13, 2017 at 07:54:01PM +, Andrew Cooper wrote:
>> On 13/01/17 19:40, Marek Marczykowski-Górecki wrote:
>>> On Fri, Jan 13, 2017 at 07:27:20PM +, Andrew Cooper wrote:
On 13/01/17 18:59, Marek Marczykowski-Górecki wrote
On 01/13/2017 10:51 AM, Jan Beulich wrote:
On 12.01.17 at 13:13, wrote:
>> # Introduction
>>
>> One of the design goals of PVH is to be able to remove as much Xen PV
>> specific
>> code as possible, thus limiting the number of Xen PV interfaces used by
>> guests,
>> and tending to use nativ
This run is configured for baseline tests only.
flight 68364 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68364/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 521981ee7608b75b51693ea367c9e1d83687d110
baseline v
On 01/13/2017 11:27 AM, Ian Jackson wrote:
>
> osstest's reports are posted to xen-devel. To give you an example of
> what they look like, I have pasted below the top of the report from
> last test report of linux-linus (including interesting mail headers).
>
> If you find the mail filtering of xe
On Fri, Jan 13, 2017 at 03:07:51PM -0500, Dan Streetman wrote:
> Revert the main part of commit:
> af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
>
> That commit introduced reading the pci device's msi message data to see
> if a pirq was previously configured for the device'
flight 104170 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104170/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-credit2 6 xen-boot fail in 104162 pass in 104170
test-armhf-armhf-xl-arndale 4
flight 104169 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104169/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 6 xen-boot fail REGR. vs. 104159
Regressions which
On 01/13/2017 03:07 PM, Dan Streetman wrote:
> Revert the main part of commit:
> af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
>
> That commit introduced reading the pci device's msi message data to see
> if a pirq was previously configured for the device's msi/msix, and re-
On Fri, 13 Jan 2017, Al Stone wrote:
> On 01/13/2017 12:52 PM, Stefano Stabellini wrote:
> > On Fri, 13 Jan 2017, Ian Jackson wrote:
> >> Stefano Stabellini writes ("STAO spec in xen.git"):
> >>> I suggest we commit the STAO spec in the form of the attached ODT
> >>> document to xen.git under docs/
On Fri, 13 Jan 2017, Dan Streetman wrote:
> Revert the main part of commit:
> af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
>
> That commit introduced reading the pci device's msi message data to see
> if a pirq was previously configured for the device's msi/msix, and re-us
On 01/13/2017 12:52 PM, Stefano Stabellini wrote:
> On Fri, 13 Jan 2017, Ian Jackson wrote:
>> Stefano Stabellini writes ("STAO spec in xen.git"):
>>> I suggest we commit the STAO spec in the form of the attached ODT
>>> document to xen.git under docs/misc, for easier editing and consumption
>>> by
On Fri, Jan 13, 2017 at 07:54:01PM +, Andrew Cooper wrote:
> On 13/01/17 19:40, Marek Marczykowski-Górecki wrote:
> > On Fri, Jan 13, 2017 at 07:27:20PM +, Andrew Cooper wrote:
> >> On 13/01/17 18:59, Marek Marczykowski-Górecki wrote:
> >>> On Fri, Jan 13, 2017 at 06:37:06PM +, Andrew C
On Fri, Jan 13, 2017 at 3:00 PM, Boris Ostrovsky
wrote:
> On 01/13/2017 01:44 PM, Stefano Stabellini wrote:
>> On Fri, 13 Jan 2017, Dan Streetman wrote:
>>> On Wed, Jan 11, 2017 at 6:25 PM, Dan Streetman wrote:
On Wed, Jan 11, 2017 at 1:46 PM, Stefano Stabellini
wrote:
> On Wed, 11
Revert the main part of commit:
af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
That commit introduced reading the pci device's msi message data to see
if a pirq was previously configured for the device's msi/msix, and re-use
that pirq. At the time, that was the correct beha
On 01/13/2017 01:44 PM, Stefano Stabellini wrote:
> On Fri, 13 Jan 2017, Dan Streetman wrote:
>> On Wed, Jan 11, 2017 at 6:25 PM, Dan Streetman wrote:
>>> On Wed, Jan 11, 2017 at 1:46 PM, Stefano Stabellini
>>> wrote:
On Wed, 11 Jan 2017, Dan Streetman wrote:
> On Tue, Jan 10, 2017 at 8:
Hi Julien,
I tried markdown, but there are too many tables, they all get garbled.
git diff would only show binary diffs, but libreoffice can show changes.
Cheers,
Stefano
On Fri, 13 Jan 2017, Julien Grall wrote:
> Hi,
>
> Sorry for the top postimg and formatting. I am sending this e-mail from
On 13/01/17 19:40, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 13, 2017 at 07:27:20PM +, Andrew Cooper wrote:
>> On 13/01/17 18:59, Marek Marczykowski-Górecki wrote:
>>> On Fri, Jan 13, 2017 at 06:37:06PM +, Andrew Cooper wrote:
On 13/01/17 18:32, Marek Marczykowski-Górecki wrote:
On Fri, 13 Jan 2017, Ian Jackson wrote:
> Stefano Stabellini writes ("STAO spec in xen.git"):
> > I suggest we commit the STAO spec in the form of the attached ODT
> > document to xen.git under docs/misc, for easier editing and consumption
> > by the Xen community, and to be able to generate a stab
Hi,
Sorry for the top postimg and formatting. I am sending this e-mail from my
phone.
We already had this discussion a couple of months ago (see [1]). We agreed on
an URL but the pdfs were not uploaded.
Regarding the format. Does ODT will allow git to do proper diff?
If not I would prefer the
This run is configured for baseline tests only.
flight 68357 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68357/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-33 host-install(3)
On Fri, 13 Jan 2017, Jan Beulich wrote:
> >>> On 12.01.17 at 13:13, wrote:
> > # Introduction
> >
> > One of the design goals of PVH is to be able to remove as much Xen PV
> > specific
> > code as possible, thus limiting the number of Xen PV interfaces used by
> > guests,
> > and tending to use
On Fri, Jan 13, 2017 at 07:27:20PM +, Andrew Cooper wrote:
> On 13/01/17 18:59, Marek Marczykowski-Górecki wrote:
> > On Fri, Jan 13, 2017 at 06:37:06PM +, Andrew Cooper wrote:
> >> On 13/01/17 18:32, Marek Marczykowski-Górecki wrote:
> >>> On Fri, Jan 13, 2017 at 06:15:35PM +, Andrew C
On 13/01/17 14:32, 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
Ian Jackson writes ("Re: [OSSTEST PATCH v9 3/3] Create a flight to test
OpenStack with xen-unstable and libvirt"):
> Can you provide this series to me as a git branch (catch me on irc
> with the url perhaps) ? I will queue it and feed it to the osstest
> self-push-gate at an opportune moment.
An
On Thu, 12 Jan 2017, Andre Przywara wrote:
> 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 Przy
Stefano Stabellini writes ("STAO spec in xen.git"):
> I suggest we commit the STAO spec in the form of the attached ODT
> document to xen.git under docs/misc, for easier editing and consumption
> by the Xen community, and to be able to generate a stable URL for it. In
> fact at the moment the link
On 13/01/17 18:59, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 13, 2017 at 06:37:06PM +, Andrew Cooper wrote:
>> On 13/01/17 18:32, Marek Marczykowski-Górecki wrote:
>>> On Fri, Jan 13, 2017 at 06:15:35PM +, Andrew Cooper wrote:
Can you get the result of this piece of debugging in
From: Daniel Kiper
There is a problem with place_string() which is used as early memory
allocator. It gets memory chunks starting from start symbol and goes
down. Sadly this does not work when Xen is loaded using multiboot2
protocol because then the start lives on 1 MiB address and we should
not
This is a series based on v11 of Daniel Kiper's
"x86: multiboot2 protocol support" series. It aims to collect up all the
fixes and changes that Andrew Cooper, Jan Beulich and myself discovered in
code review and testing on actual hardware. I've had problems with the
relocation portion of the series
From: Daniel Kiper
Add multiboot2 protocol support. Alter min memory limit handling as we
now may not find it from either multiboot (v1) or multiboot2.
This way we are laying the foundation for EFI + GRUB2 + Xen development.
Signed-off-by: Daniel Kiper
Reviewed-by: Jan Beulich
Reviewed-by: Do
From: Daniel Kiper
Build xen.gz with EFI code. We need this to support multiboot2
protocol on EFI platforms.
If we wish to load non-ELF file using multiboot (v1) or multiboot2 then
it must contain "linear" (or "flat") representation of code and data.
This is requirement of both boot protocols. C
On Fri, 13 Jan 2017, Andre Przywara wrote:
> Hi Stefano,
>
> On 05/01/17 00:13, Stefano Stabellini wrote:
> > On Thu, 22 Dec 2016, Andre Przywara wrote:
> >> The ITS uses device IDs to map LPIs to a device. Dom0 will later use
> >> those IDs, which we directly pass on to the host.
> >> For this we
From: Daniel Kiper
This way Xen can be loaded on EFI platforms using GRUB2 and
other boot loaders which support multiboot2 protocol.
Signed-off-by: Daniel Kiper
Signed-off-by: Doug Goldstein
Reviewed-by: Doug Goldstein
---
Doug v1 - fix incorrect assembly (identified by Andrew Cooper)
Hi all,
Similarly to STAO (http://marc.info/?l=xen-devel&m=148433427425627), I
suggest we also commit the XENV spec in the form of the attached ODT
document to xen.git under docs/misc.
Cheers,
Stefano
xen-env-table-spec-v0.2.odt
Description: application/vnd.oasis.opendocument.text
_
Hi all,
I suggest we commit the STAO spec in the form of the attached ODT
document to xen.git under docs/misc, for easier editing and consumption
by the Xen community, and to be able to generate a stable URL for it. In
fact at the moment the link to the STAO spec from http://uefi.org/acpi
is broke
On 13/01/17 15:35, Jan Beulich wrote:
> This is to bring its name in line with what actually happens there.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
htt
On 13/01/17 15:34, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Fri, Jan 13, 2017 at 06:37:06PM +, Andrew Cooper wrote:
> On 13/01/17 18:32, Marek Marczykowski-Górecki wrote:
> > On Fri, Jan 13, 2017 at 06:15:35PM +, Andrew Cooper wrote:
> >> Can you get the result of this piece of debugging in the failure case?
> > I've got this:
> > ** d4v0 CFG(24,
On 13/01/17 15:34, Jan Beulich wrote:
> @@ -5737,14 +5739,82 @@ x86_emulate(
> dst.val = src.val;
> break;
>
> -case X86EMUL_OPC(0x0f, 0xc7): /* Grp9 (cmpxchg8b/cmpxchg16b) */ {
> +case X86EMUL_OPC(0x0f, 0xc7): /* Grp9 */ {
Style (while you are changing this).
Otherwis
On 13/01/17 15:32, Jan Beulich wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -1355,6 +1355,7 @@ static bool vcpu_has(
> #define vcpu_has_cr8_legacy() vcpu_has(0x8001, ECX, 4, ctxt, ops)
> #define vcpu_has_lzcnt() vcpu_has(0x8
On 01/13/2017 01:26 PM, Stefano Stabellini wrote:
> On Fri, 13 Jan 2017, Boris Ostrovsky wrote:
>> On 01/12/2017 04:39 PM, Stefano Stabellini wrote:
>>> The following commit:
>>>
>>> commit 72a9b186292d98494f26cfd24a1621796209
>>> Author: KarimAllah Ahmed
>>> Date: Fri Aug 26 23:55:36 2016 +
On Fri, 13 Jan 2017, Dan Streetman wrote:
> On Wed, Jan 11, 2017 at 6:25 PM, Dan Streetman wrote:
> > On Wed, Jan 11, 2017 at 1:46 PM, Stefano Stabellini
> > wrote:
> >> On Wed, 11 Jan 2017, Dan Streetman wrote:
> >>> On Tue, Jan 10, 2017 at 8:25 PM, Stefano Stabellini
> >>> wrote:
> >>> > On Tu
On Fri, 13 Jan 2017, Pooya.Keshavarzi wrote:
> On 01/12/2017 07:50 PM, Stefano Stabellini wrote:
> > On Thu, 12 Jan 2017, Pooya.Keshavarzi wrote:
> >>
> >> Firstly sorry for the late reply on this.
> >>
> >> Regarding the problem with swiotlb-xen here are some more details:
> >>
> >> If we limit Do
On 13/01/17 18:32, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 13, 2017 at 06:15:35PM +, Andrew Cooper wrote:
>> On 13/01/17 18:03, Marek Marczykowski-Górecki wrote:
>>> On Fri, Jan 13, 2017 at 05:38:42PM +, Andrew Cooper wrote:
On 13/01/17 17:31, Marek Marczykowski-Górecki wrote:
On Fri, Jan 13, 2017 at 06:15:35PM +, Andrew Cooper wrote:
> On 13/01/17 18:03, Marek Marczykowski-Górecki wrote:
> > On Fri, Jan 13, 2017 at 05:38:42PM +, Andrew Cooper wrote:
> >> On 13/01/17 17:31, Marek Marczykowski-Górecki wrote:
> >>> Hi,
> >>>
> >>> I have a strange problem - xc_evtc
On Wed, Jan 11, 2017 at 6:25 PM, Dan Streetman wrote:
> On Wed, Jan 11, 2017 at 1:46 PM, Stefano Stabellini
> wrote:
>> On Wed, 11 Jan 2017, Dan Streetman wrote:
>>> On Tue, Jan 10, 2017 at 8:25 PM, Stefano Stabellini
>>> wrote:
>>> > On Tue, 10 Jan 2017, Dan Streetman wrote:
>>> >> On Tue, Jan
On Fri, 13 Jan 2017, Boris Ostrovsky wrote:
> On 01/12/2017 04:39 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 notificati
On 13/01/17 15:32, Jan Beulich wrote:
> Note that the adjustment to the mode_64bit() definition is so that we
> can avoid "#ifdef __x86_64__" around the 64-bit asm() portions. An
> alternative would be single asm()s with a conditional branch over the
> (manually encoded) REX64 prefix.
This presuma
On 13/01/17 18:03, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 13, 2017 at 05:38:42PM +, Andrew Cooper wrote:
>> On 13/01/17 17:31, Marek Marczykowski-Górecki wrote:
>>> Hi,
>>>
>>> I have a strange problem - xc_evtchn_status fails when running in HVM,
>>> while exactly the same code (same
On Fri, Jan 13, 2017 at 05:38:42PM +, Andrew Cooper wrote:
> On 13/01/17 17:31, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > I have a strange problem - xc_evtchn_status fails when running in HVM,
> > while exactly the same code (same kernel, same application etc) works
> > fine in PV. I've
On 13/01/17 15:31, Jan Beulich wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -676,6 +676,16 @@ do{ asm volatile (
> #define __emulate_1op_8byte(_op, _dst, _eflags)
> #endif /* __i386__ */
>
> +#define emulate_stub(dst, src...) do {
On 13/01/17 17:31, Marek Marczykowski-Górecki wrote:
> Hi,
>
> I have a strange problem - xc_evtchn_status fails when running in HVM,
> while exactly the same code (same kernel, same application etc) works
> fine in PV. I've narrowed it down to copy_from_guest call in
> common/event_channel.c, but
Hi,
I have a strange problem - xc_evtchn_status fails when running in HVM,
while exactly the same code (same kernel, same application etc) works
fine in PV. I've narrowed it down to copy_from_guest call in
common/event_channel.c, but no idea why it fails there. Xen version is
4.8.0. kernel is kern
flight 104171 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104171/
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 1
On Fri, Jan 13, 2017 at 11:46:39AM +0100, Nicolas Dichtel wrote:
> This header file is exported, thus move it to uapi.
I'm taking this patch, but with the following commit log:
Due to the way kbuild works, this header was unintentionally exported
back in 2013 when it was created, despite it n
On Fri, Jan 13, 2017 at 05:08:34PM +0100, Nicolas Dichtel wrote:
> Le 13/01/2017 à 16:43, David Howells a écrit :
> >> -header-y += msr-index.h
> >
> > I see it on my desktop as /usr/include/asm/msr-index.h and it's been there
> > at
> > least four years - and as such it's part of the UAPI. I do
On 13/01/17 15:31, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 13/01/17 15:30, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Boris Ostrovsky writes ("Re: [Xen-devel] Xen 4.8 + Linux 4.9 + Credit2 = can't
bootup"):
> I can give it a try although I have practically no experience with
> OSSTest. Is there a way to subscribe to notifications for those tests?
osstest's reports are posted to xen-devel. To give you an example
On Fri, Jan 13, 2017 at 05:01:01PM +0100, Nicolas Dichtel wrote:
> Please, do not remove the email subject when you reply. I restore it to
> ease the thread follow-up.
I mentioned it to David, and he says it's because the long list of
recipients is breaking his mailer. I've already posed the ques
On Fri, Jan 13, 2017 at 09:45:13AM -0600, Doug Goldstein wrote:
> On 1/11/17 2:46 PM, Daniel Kiper wrote:
> > On Mon, Dec 05, 2016 at 11:25:05PM +0100, Daniel Kiper wrote:
> >> Hi,
> >>
> >> I am sending eleventh version of multiboot2 protocol support for
> >> legacy BIOS and EFI platforms. This pa
Le 13/01/2017 à 16:43, David Howells a écrit :
>> -header-y += msr-index.h
>
> I see it on my desktop as /usr/include/asm/msr-index.h and it's been there at
> least four years - and as such it's part of the UAPI. I don't think you can
> remove it unless you can guarantee there are no userspace us
Please, do not remove the email subject when you reply. I restore it to ease the
thread follow-up.
Le 13/01/2017 à 16:36, David Howells a écrit :
> Nicolas Dichtel wrote:
>
>> This header file is exported, thus move it to uapi.
>
> Exported how?
It is listed in include/uapi/asm-generic/Kbuild.a
>>> On 12.01.17 at 13:13, wrote:
> # Introduction
>
> One of the design goals of PVH is to be able to remove as much Xen PV specific
> code as possible, thus limiting the number of Xen PV interfaces used by
> guests,
> and tending to use native interfaces (as used by bare metal) as much as
> pos
On Fri, Jan 13, 2017 at 10:41:10AM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 13, 2017 at 04:18:04PM +0100, Radim Krcmar wrote:
> > 2017-01-13 10:01-0200, Marcelo Tosatti:
> > > Expose the realtime host clock and save the TSC value
> > > used for the clock calculation.
> > >
> > > Signed-of
On 1/11/17 2:46 PM, Daniel Kiper wrote:
> On Mon, Dec 05, 2016 at 11:25:05PM +0100, 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 g
> -header-y += msr-index.h
I see it on my desktop as /usr/include/asm/msr-index.h and it's been there at
least four years - and as such it's part of the UAPI. I don't think you can
remove it unless you can guarantee there are no userspace users.
David
___
Nicolas Dichtel wrote:
> This header file is exported, thus move it to uapi.
Exported how?
> +#ifdef __INT32_TYPE__
> +#undef __INT32_TYPE__
> +#define __INT32_TYPE__ int
> +#endif
> +
> +#ifdef __UINT32_TYPE__
> +#undef __UINT32_TYPE__
> +#define __UINT32_TYPE__ unsigned int
On Fri, Jan 13, 2017 at 04:18:04PM +0100, Radim Krcmar wrote:
> 2017-01-13 10:01-0200, Marcelo Tosatti:
> > Expose the realtime host clock and save the TSC value
> > used for the clock calculation.
> >
> > Signed-off-by: Marcelo Tosatti
> >
> > ---
> > arch/x86/kvm/x86.c | 38
On 01/13/2017 03:31 AM, Dario Faggioli wrote:
> 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 m
This is to bring its name in line with what actually happens there.
Suggested-by: Andrew Cooper
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -986,7 +986,7 @@ static inline void put_loop_count(
if ( using_si
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -158,6 +158,11 @@ static int read_msr(
case 0xc080: /* EFER */
*val = ctxt->addr_size > 32 ? 0x500 /* LME|LMA */ : 0;
return X86EMUL_OKAY;
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -14,7 +14,9 @@ $(call cc-option-add,CFLAGS,CC,-Wnested-
$(call as-insn-check,CFLAGS,CC,"vmcall",-DHAVE_GAS_VMX)
$(call as-insn-check,CFLAGS,CC,"crc32 %eax$$(comma)%eax",-DHAVE_GAS_SSE4_2)
$(call as-insn-check
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -1244,6 +1244,234 @@ int main(int argc, char **argv)
printf("okay\n");
}
+printf("%-40s", "Testing bextr $0x0a03,(%ecx),%ebx...");
+if ( stac
Note that the adjustment to the mode_64bit() definition is so that we
can avoid "#ifdef __x86_64__" around the 64-bit asm() portions. An
alternative would be single asm()s with a conditional branch over the
(manually encoded) REX64 prefix.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulato
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -892,6 +892,133 @@ int main(int argc, char **argv)
#define check_eip(which) (regs.eip == (unsigned long)(which) + \
(unsigned
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -885,10 +885,65 @@ int main(int argc, char **argv)
#which ": " insn "\n" \
".equ "
Signed-off-by: Jan Beulich
---
TBD: Alternative code needed for binutils < 2.18?
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -684,6 +684,52 @@ int main(int argc, char **argv)
goto fail;
printf("okay\n");
+printf("%-4
>>> On 12.01.17 at 20:00, wrote:
> On 12/01/17 12:13, Roger Pau Monné wrote:
>> ## Proposed solution using the STAO
>>
>> The general idea of this method is to use the STAO in order to hide the pCPUs
>> from the hardware domain, and provide processor objects for vCPUs in an extra
>> SSDT table.
>>
Dear Andrii,
On 01/13/2017 11:47 AM, Andrii Anisov wrote:
>
> Dear Pooya,
>
> On our site we did not face those issues 'cause we limited dom0 memory space
> to the 32-bit addressable range.
Could you give it a try? Maybe there is something wrong on our side and it
works for you.
> BTW, it loo
On 01/12/2017 07:50 PM, Stefano Stabellini wrote:
> On Thu, 12 Jan 2017, Pooya.Keshavarzi wrote:
>>
>> Firstly sorry for the late reply on this.
>>
>> Regarding the problem with swiotlb-xen here are some more details:
>>
>> If we limit Dom0's memory such that only low-memory (up to 32-bit
>> addre
... plus, in the final patch, some cleanup.
1: support POPCNT
2: support ADCX/ADOX
3: support BMI1 insns
4: support BMI2 insns
5: support TBM insns
6: support RDRAND
7: support RDPID
8: rename the no_writeback label
Signed-off-by: Jan Beulich
___
Xen
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 13.01.17 at 14:56, wrote:
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
flight 104166 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104166/
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 1
>>> On 13.01.17 at 14:56, wrote:
> The model information isn't used at all, and the family information is only
> used once.
>
> Make get_cpu_family() a static inline (as it is just basic calculation, and
> the function call is probably more expensive than the function itself) and
> rearange the l
On 01/12/2017 04:39 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
Upstream QEMU supports emulation of NVM Express a.k.a. NVMe drives.
This patch adds a new vdev type into libxl to allow such drives to be
presented to HVM guests. Because the purpose of the new vdev is purely
to configure emulation, the syntax only supports specification of
whole disks. Also there
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 13 January 2017 13:57
> To: xen-de...@lists.xenproject.org
> Cc: Paul Durrant
> Subject: [PATCH] tools/libxl: add support for emulated NVMe drives
>
> Upstream QEMU supports emulation of NVM Express a.k.a.
Upstream QEMU supports emulation of NVM Express a.k.a. NVMe drives.
This patch adds a new vdev type into libxl to allow such drives to be
presented to HVM guests. Because the purpose of the new vdev is purely
to configure emulation, the syntax only supports specification of
whole disks. Also there
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
v2: Break out family/model logic
---
xen/arch/x86/cpuid.c| 9 +
xen/
flight 104162 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104162/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 104157
Regressions which
The model information isn't used at all, and the family information is only
used once.
Make get_cpu_family() a static inline (as it is just basic calculation, and
the function call is probably more expensive than the function itself) and
rearange the logic to avoid calculating model entirely if th
>>> On 12.01.17 at 17:43, wrote:
> 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'
On 13/01/17 14:31, Juergen Gross wrote:
> On 13/01/17 13:18, Wei Liu wrote:
>> The only place that used such option was removed in 388d3011.
>>
>> Signed-off-by: Wei Liu
>
> Reviewed-by: Juergen Gross
Sorry, this stands only if you do the change I mentioned below.
>
>> ---
>> Cc: Juergen Gros
On Fri, Jan 13, 2017 at 06:19:28AM -0700, Jan Beulich wrote:
> >>> On 13.01.17 at 13:49, wrote:
> > On Fri, Jan 13, 2017 at 05:35:35AM -0700, Jan Beulich wrote:
> >> >>> On 13.01.17 at 13:14, wrote:
> >> > Jan, so, __XEN_LATEST_INTERFACE_VERSION__ is used only for Xen internal
> >> > purposes
>
please forgive the cross-posting. having not had much luck on the
xen-users list, and having seen similarly-complex threads on this list,
i thought i'd see if anyone here had any ideas or pointers.
TL;DR
all packets are being dropped in a debian 7 (wheezy) guest only when
they are coming from
1 - 100 of 160 matches
Mail list logo
