>>> On 24.11.16 at 22:44, wrote:
> On Thu, Nov 24, 2016 at 04:08:12AM -0700, Jan Beulich wrote:
>> >>> On 23.11.16 at 19:52, wrote:
>> > On 29/09/16 22:42, Daniel Kiper wrote:
>
> [...]
>
>> >> +.Lefi_mb2_tsize:
>> >> +/* Check Multiboot2 information total size. */
>> >> +mov
flight 102613 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102613/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 6 xen-boot fail REGR. vs. 102534
test-arm
>>> On 24.11.16 at 18:22, wrote:
> On 24/11/16 15:25, Jan Beulich wrote:
> On 23.11.16 at 16:38, wrote:
>>> +case x86_seg_tr:
>>> +ASSERT(reg->attr.fields.p); /* Usable. */
>>> +ASSERT(!reg->attr.fields.s); /* System segment. */
>>> +
>>> On 24.11.16 at 18:19, wrote:
> On 24/11/16 17:08, Jan Beulich wrote:
> On 24.11.16 at 18:00, wrote:
But wouldn't you then need to add similar checks in OKAY paths elsewhere?
>>> I don't see why I would. Does my explanation above resolve your concern?
>> I'm afraid not: On the same b
On 11/25/2016 09:11 AM, Jan Beulich wrote:
On 24.11.16 at 18:11, wrote:
+struct xensnd_close_req {
+};
I'm afraid structures without any members aren't permitted by C89.
There are 2 options I see:
1. Remove empty structures
2. Leave them in, but add a comment and add a dummy place holder
I
On 11/25/2016 09:14 AM, Jan Beulich wrote:
On 24.11.16 at 18:25, wrote:
On 24/11/16 17:11, Oleksandr Andrushchenko wrote:
That is because we want to be cache line aligned.
But this is only accurate to your platform. There is HW available with
128 bytes.
For instance on Xen ARM, all the str
On 11/25/2016 09:20 AM, Jan Beulich wrote:
On 24.11.16 at 23:14, wrote:
On Thu, 2016-11-24 at 20:31 +0200, Oleksandr Andrushchenko wrote:
Hmm, I think you want a PV Linux DRM/KMS driver, but that doesn't
mean you want/need a protocol by that name. The interface has
to describe virtual hardware
>>> On 24.11.16 at 18:37, wrote:
> As an interim between now and getting a proper audit hook, would a bool
> permit_traps in x86_emulate_ctxt suffice?
That's one option; the other would be to do away with only the
exception injection hook for now, and keep the swint one. That's
effectively the sa
>>> On 24.11.16 at 23:14, wrote:
> On Thu, 2016-11-24 at 20:31 +0200, Oleksandr Andrushchenko wrote:
>> > Hmm, I think you want a PV Linux DRM/KMS driver, but that doesn't
>> > mean you want/need a protocol by that name. The interface has
>> > to describe virtual hardware, and I don't think you'd
>>> On 24.11.16 at 18:25, wrote:
> On 24/11/16 17:11, Oleksandr Andrushchenko wrote:
>> That is because we want to be cache line aligned.
>
> But this is only accurate to your platform. There is HW available with
> 128 bytes.
>
> For instance on Xen ARM, all the structures are aligned to 128 by
>>> On 24.11.16 at 18:11, wrote:
>> > +struct xensnd_close_req {
>>> +};
>>
>> I'm afraid structures without any members aren't permitted by C89.
>>
> There are 2 options I see:
> 1. Remove empty structures
> 2. Leave them in, but add a comment and add a dummy place holder
> I would prefer option
>>> On 24.11.16 at 18:02, wrote:
On 18.11.16 at 18:13, wrote:
>> +{
>> +struct xen_dm_op_get_ioreq_server_info *data =
>> +&op.u.get_ioreq_server_info;
>> +
>> +rc = hvm_get_ioreq_server_info(d, data->id,
>> + &data->ioreq
On 11/24/2016 9:37 PM, Edgar E. Iglesias wrote:
On Thu, Nov 24, 2016 at 02:49:41PM +0800, Lan Tianyu wrote:
On 2016年11月24日 12:09, Edgar E. Iglesias wrote:
Hi,
I have a few questions.
If I understand correctly, you'll be emulating an Intel IOMMU in Xen.
So guests will essentially create int
flight 102603 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102603/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 102503
test-armhf-armhf-libvirt-xsm 13
Wow, thanks! Works very well.
On Fri, Nov 25, 2016 at 1:12 PM, Juergen Gross wrote:
> On 25/11/16 04:11, Yuming Wu wrote:
> > Hi,
> >
> > I'm debugging some xen code during hypervisor initialization. Before it
> > reset stack and jump to cpu loop, I triggered a bug (may be change a
> > readonly
On 25/11/16 04:11, Yuming Wu wrote:
> Hi,
>
> I'm debugging some xen code during hypervisor initialization. Before it
> reset stack and jump to cpu loop, I triggered a bug (may be change a
> readonly page). Usually, system will panic and give me stack info and
> backtrace. But before printk finish
There is still the same confusion as with entry address tag 7; the diagram has
u_virt, yet the text does claim it is physical address. Sure, it is assumed the
identity mapping, but still those names are creating confusion.
Moreover, the EFI32 and EFI64 have different address sizes (32 versus 64
Hi,
I'm debugging some xen code during hypervisor initialization. Before it
reset stack and jump to cpu loop, I triggered a bug (may be change a
readonly page). Usually, system will panic and give me stack info and
backtrace. But before printk finish printing initialization message it just
crash l
flight 102601 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102601/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt13 saverestore-support-check fail REGR. vs. 101275
test-amd64-amd6
On November 24, 2016 9:38 PM,
>On Thu, Nov 24, 2016 at 02:49:41PM +0800, Lan Tianyu wrote:
>> On 2016年11月24日 12:09, Edgar E. Iglesias wrote:
>> Hi,
>> > > >
>> > > > I have a few questions.
>> > > >
>> > > > If I understand correctly, you'll be emulating an Intel IOMMU in
This run is configured for baseline tests only.
flight 68094 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68094/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 26b85012802ed8a2ff3db96d102121323aabcc0c
baseline v
flight 102587 qemu-upstream-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102587/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail REGR. vs. 100711
test
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, November 24, 2016 11:41 PM
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Jun Nakajima
> CC: Kevin Tian
> CC: Wei Liu
> ---
> xen/arch/x86/hvm/vmx/vmx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 dele
flight 102583 qemu-upstream-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102583/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 13 saverestore-support-check fail REGR. vs. 99723
test-
On Thu, 2016-11-24 at 20:31 +0200, Oleksandr Andrushchenko wrote:
> > Hmm, I think you want a PV Linux DRM/KMS driver, but that doesn't
> > mean you want/need a protocol by that name. The interface has
> > to describe virtual hardware, and I don't think you'd call a
> > graphics
> > card "DRM/KMS c
On Thu, Nov 24, 2016 at 04:08:12AM -0700, Jan Beulich wrote:
> >>> On 23.11.16 at 19:52, wrote:
> > On 29/09/16 22:42, Daniel Kiper wrote:
[...]
> >> +.Lefi_mb2_tsize:
> >> +/* Check Multiboot2 information total size. */
> >> +mov %ecx,%r8d
> >> +sub %ebx,%r8d
> >
flight 102596 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102596/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 26b85012802ed8a2ff3db96d102121323aabcc0c
baseline version:
ovmf 0265811dbe56cf46fb3c1
On Wed, Nov 23, 2016 at 06:52:27PM +, Andrew Cooper wrote:
> On 29/09/16 22:42, Daniel Kiper wrote:
[...]
> > +vga_text_buffer:
> > +.long 0xb8000
>
> Why is this turned into a variable?
We must disable VGA accesses during runtime on platforms which does
not have one like e.g. EFI.
flight 102579 qemu-upstream-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102579/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 13 saverestore-support-check fail REGR. vs. 99725
Tests
Hello all,
My name is Volodymyr Babchuk, I'm working on EPAM Systems with bunch
of other guys like Artem Mygaiev or Andrii Anisov. My responsibility
there is security in embedded systems.
I would like to discuss approaches to OP-TEE support in XEN.
But first small introduction for those who is no
Signed-off-by: Daniel Kiper
---
v2 - suggestions/fixes:
- rephrase some sentences
(suggested by Andrew Cooper),
- add missing the articles
(suggested by Andrew Cooper).
---
doc/multiboot.texi | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git
.. and add 2016 to copyright.
Signed-off-by: Daniel Kiper
---
configure.ac |2 +-
doc/multiboot.texi |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index b11961d..585b37a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -13,7 +13,7
Hi,
This updated patch series adds description of the Multiboot2 protocol new
features and fixes some issues found here and there.
It applies to multiboot2 branch in GRUB2 git tree.
Daniel
configure.ac |2 +-
doc/multiboot.texi | 366
Signed-off-by: Daniel Kiper
---
doc/multiboot.texi | 28
doc/multiboot2.h | 16
2 files changed, 44 insertions(+)
diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index cc1edab..dca3e62 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.te
Signed-off-by: Daniel Kiper
---
v2 - suggestions/fixes:
- add missing the articles
(suggested by Andrew Cooper),
- various minor cleanups and fixes
(suggested by Andrew Cooper).
---
doc/multiboot.texi | 56
doc/multiboot2.h
Signed-off-by: Daniel Kiper
---
v2 - suggestions/fixes:
- rephrase whole section
(suggested by Andrew Cooper).
---
doc/multiboot.texi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index 9461890..fe134bc 100644
--- a/doc/multiboo
Signed-off-by: Daniel Kiper
---
v2 - suggestions/fixes:
- clarify physical address meaning for EFI amd64
mode with boot services enabled
(suggested by Andrew Cooper).
---
doc/multiboot.texi | 115 +++-
doc/multiboot2.h |2 +
2 fi
Without this fix multiboot2 doc build fails. Additionally,
add missing full stop at the end of sentence.
Signed-off-by: Daniel Kiper
---
doc/multiboot.texi |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index 771aeab..f0f167e
Signed-off-by: Daniel Kiper
---
v2 - suggestions/fixes:
- add missing the articles
(suggested by Andrew Cooper).
---
doc/multiboot.texi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index 973be9f..9461890 100644
--- a/doc/multib
Multiboot2 is proper name of the boot protocol. Multiboot is name of older boot
protocol. So, rename Multiboot to Multiboot2 to not confuse the reader.
Signed-off-by: Daniel Kiper
---
doc/multiboot.texi | 112 ++--
1 file changed, 56 insertions(+)
.. and properly format author list.
Signed-off-by: Daniel Kiper
---
doc/multiboot.texi |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index fe134bc..5a3cd5d 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -53,7 +53,9
Signed-off-by: Daniel Kiper
---
v2 - suggestions/fixes:
- replace redundant if with the
(suggested by Andrew Cooper).
---
doc/multiboot.texi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index d2b940f..c438b38 100644
--- a/d
From: Olaf Hering
Using 'vdev=sd[a-o]' will create an emulated LSI controller, which can
be used by the emulated BIOS to boot from disk. If the HVM domU has also
PV driver the disk may appear twice in the guest. To avoid this an
unplug of the emulated hardware is needed, similar to what is done f
From: Olaf Hering
Implement SUSE specific unplug protocol for emulated PCI devices
in PVonHVM guests. Its a simple 'outl(1, (ioaddr + 4));'.
This protocol was implemented and used since Xen 3.0.4.
It is used in all SUSE/SLES/openSUSE releases up to SLES11SP3 and
openSUSE 12.3.
In addition old (pr
Backport from qemu-2.8:
Update unplug in Xen HVM guests to cover more cases.
The patches are used since years in the SUSE xen-tools package.
Olaf
Olaf Hering (2):
xen_platform: unplug also SCSI disks
xen_platform: SUSE xenlinux unplug for emulated PCI
hw/pci.c | 41 ++
This run is configured for baseline tests only.
flight 68092 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68092/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-
flight 102574 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102574/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 7 host-ping-check-xen fail REGR. vs. 101909
test-armhf-armhf-
+struct xensnd_close_req {
+};
>>>
>>>
>>>
>>>
>>> I'm afraid structures without any members aren't permitted by C89.
>>>
>> There are 2 options I see:
>> 1. Remove empty structures
>> 2. Leave them in, but add a comment and add a dummy
Hi Oleksandr,
On 24/11/16 18:04, Oleksandr Andrushchenko wrote:
+struct xensnd_close_req {
+};
I'm afraid structures without any members aren't permitted by C89.
There are 2 options I see:
1. Remove empty structures
2. Leave them in, but add a comment and add a dummy place holder
I would p
>>> One thing which I think you should have clarified up front is why
>>> the existing fbfront is neither sufficient nor possible to extend
>>> suitably.
>> Framebuffer device is rather outdated way for Linux user-space
>> to draw. All modern software expects DRM/KMS drivers and as
>> a fallback *
flight 102571 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102571/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 3 host-install(3)broken REGR. vs. 10252
This patch should create a flight "openstack-nova", with those jobs:
build-amd64
build-amd64-xsm
build-amd64-pvops
build-amd64-libvirt
test-amd64-amd64-devstack
test-amd64-amd64-devstack-xsm
About the runvars revision_* of test-*-*-devstack:
only REVISION_OPENSTACK_NOVA is set, the o
This script runs the OpenStack integration test suite, Tempest.
Signed-off-by: Anthony PERARD
Acked-by: Ian Campbell
Acked-by: Ian Jackson
---
Changes in V8:
- fix copyright year
- fix job name in sg-run-job
- fix too long lines
Changes in V7:
- reindent
- acked
No change in V5
Change in V4
This script installs any necessary packages and clones all of the OpenStack
trees which are used by devstack to deploy OpenStack.
Signed-off-by: Anthony PERARD
---
Changes in V8:
- fix job name in sg-run-job
- fix copyright year
- fix too long lines
Changes in V7:
- reindent
- fix style
- remov
Hi,
I have looked into getting OpenStack been tested on the latest Xen via
osstest.
The ts-openstack-deploy script does prepare a bit more the host, clone
devstack and other OpenStack trees, then run ./stack.sh, which is a bit
like raisin and deploy OpenStack on the host. Once the machine is read
>> +struct xensnd_close_req {
>> +};
>
>
>
> I'm afraid structures without any members aren't permitted by C89.
>
There are 2 options I see:
1. Remove empty structures
2. Leave them in, but add a comment and add a dummy place holder
I would prefer opt
Hi Oleksandr,
On 24/11/16 17:33, Oleksandr Andrushchenko wrote:
+struct xensnd_close_req {
+};
I'm afraid structures without any members aren't permitted by C89.
There are 2 options I see:
1. Remove empty structures
2. Leave them in, but add a comment and add a dummy place holder
I would pr
On 24/11/16 17:30, Tim Deegan wrote:
> At 17:19 + on 24 Nov (1480007992), Andrew Cooper wrote:
>> On 24/11/16 17:08, Jan Beulich wrote:
>> On 24.11.16 at 18:00, wrote:
On 24/11/16 14:53, Jan Beulich wrote:
On 23.11.16 at 16:38, wrote:
>> --- a/xen/arch/x86/mm.c
>> ++
+struct xensnd_close_req {
+};
>>>
>>>
>>> I'm afraid structures without any members aren't permitted by C89.
>>>
>> There are 2 options I see:
>> 1. Remove empty structures
>> 2. Leave them in, but add a comment and add a dummy place holder
>> I would prefer option 1 as this way the inte
At 17:19 + on 24 Nov (1480007992), Andrew Cooper wrote:
> On 24/11/16 17:08, Jan Beulich wrote:
> On 24.11.16 at 18:00, wrote:
> >> On 24/11/16 14:53, Jan Beulich wrote:
> >> On 23.11.16 at 16:38, wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -5377,7
Hi,
On 24/11/16 17:11, Oleksandr Andrushchenko wrote:
+struct xensnd_close_req {
+};
I'm afraid structures without any members aren't permitted by C89.
There are 2 options I see:
1. Remove empty structures
2. Leave them in, but add a comment and add a dummy place holder
I would prefer option
On 24/11/16 15:25, Jan Beulich wrote:
On 23.11.16 at 16:38, wrote:
>> +case x86_seg_tr:
>> +ASSERT(reg->attr.fields.p); /* Usable. */
>> +ASSERT(!reg->attr.fields.s); /* System segment. */
>> +ASSERT(!(reg->sel & 0x4));
On 24/11/16 17:08, Jan Beulich wrote:
On 24.11.16 at 18:00, wrote:
>> On 24/11/16 14:53, Jan Beulich wrote:
>> On 23.11.16 at 16:38, wrote:
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5377,7 +5377,7 @@ int ptwr_do_page_fault(struct vcpu *v, unsigned long
addr
>> +struct xensnd_close_req {
>> +};
>
> I'm afraid structures without any members aren't permitted by C89.
>
There are 2 options I see:
1. Remove empty structures
2. Leave them in, but add a comment and add a dummy place holder
I would prefer option 1 as this way the interface seems to be clearer,
>>> On 24.11.16 at 18:00, wrote:
> On 24/11/16 14:53, Jan Beulich wrote:
> On 23.11.16 at 16:38, wrote:
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -5377,7 +5377,7 @@ int ptwr_do_page_fault(struct vcpu *v, unsigned long
>>> addr,
>>> page_unlock(page);
>>> put_pa
On 24/11/16 16:31, Jan Beulich wrote:
>
>>> With you having added my S-o-b (not really sure why), I'm not sure
>>> it makes a whole lot of sense to give my R-b as well (but feel free
>>> to add it).
>> Your code was originally the few bits replacing opencoded "goto
>> raise_exception" with generate
>>> On 18.11.16 at 18:13, wrote:
> NOTE: The definitions of HVM_IOREQSRV_BUFIOREQ_*, HVMOP_IO_RANGE_* and
> HVMOP_PCI_SBDF have to persist for new interface versions as
> they are already in use by callers of the libxc interface.
Looking back at my original hvmctl patch, I agree with
On 24/11/16 14:53, Jan Beulich wrote:
On 23.11.16 at 16:38, wrote:
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -5377,7 +5377,7 @@ int ptwr_do_page_fault(struct vcpu *v, unsigned long
>> addr,
>> page_unlock(page);
>> put_page(page);
>>
>> -if ( rc == X86EMUL_U
>>> On 24.11.16 at 17:24, wrote:
> On 24/11/16 14:31, Jan Beulich wrote:
> On 23.11.16 at 16:38, wrote:
>>> +#define generate_exception_if(p, e, ec...)\
>>> ({ if ( (p) ) { \
>>> fail_if(ops->i
On 24.11.16 18:08, Julien Grall wrote:
> On 24/11/16 15:50, Artem Mygaiev wrote:
>> On 24.11.16 17:09, Julien Grall wrote:
>>> Hi Artem,
>>>
>>> On 24/11/16 14:58, Artem Mygaiev wrote:
On 24.11.16 15:31, Jan Beulich wrote:
On 24.11.16 at 14:18, wrote:
>> On 24.11.16 15:04, Jan
On 24/11/16 14:31, Jan Beulich wrote:
On 23.11.16 at 16:38, wrote:
>> +static inline int mkec(uint8_t e, int32_t ec, ...)
>> +{
>> +return (e < 32 && (1u << e) & EXC_HAS_EC) ? ec : X86_EVENT_NO_EC;
> Please parenthesize the operands of &.
Fixed.
>
>> +}
>> +
>> +#define generate_excepti
>>> On 24.11.16 at 17:01, wrote:
> +struct xensnd_close_req {
> +};
I'm afraid structures without any members aren't permitted by C89.
> +struct xensnd_request {
> + uint8_t raw[64];
> +};
> +
> +struct xensnd_response {
> + uint8_t raw[64];
> +};
What are these two needed for now? If y
On Mon, 21 Nov 2016 13:39:32 -0800
Stefano Stabellini wrote:
> Not all 9pfs transports share memory between request and response. For
> those who don't, it is necessary to know how much memory is required in
> the response.
>
> Signed-off-by: Stefano Stabellini
> ---
IIUC the transport used in
>>> On 24.11.16 at 16:58, wrote:
> On 24/11/16 15:53, Andrew Cooper wrote:
>> On 24/11/16 15:48, Bhupinder Thakur wrote:
>>> If I manually remove the following files and recompile then
>>> compilation is successful:
>>>
>>> Remove xen/arch/arm/asm-offsets.s
>>> Remove xen/arch/arm/xen.lds
>>>
>>>
On 24/11/16 15:50, Artem Mygaiev wrote:
On 24.11.16 17:09, Julien Grall wrote:
Hi Artem,
On 24/11/16 14:58, Artem Mygaiev wrote:
On 24.11.16 15:31, Jan Beulich wrote:
On 24.11.16 at 14:18, wrote:
On 24.11.16 15:04, Jan Beulich wrote:
In my case I need it to at least define Linux specif
>>> On 24.11.16 at 16:40, wrote:
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 24.11.16 at 16:40, wrote:
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 24.11.16 at 16:44, wrote:
>> One thing which I think you should have clarified up front is why
>> the existing fbfront is neither sufficient nor possible to extend
>> suitably.
> Framebuffer device is rather outdated way for Linux user-space
> to draw. All modern software expects DRM/KMS d
On 24/11/16 16:01, Jan Beulich wrote:
On 23.11.16 at 16:38, wrote:
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -1181,20 +1181,38 @@ static int ioport_access_check(
>> return rc;
>>
>> /* Ensure the TSS has an io-bitmap-
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
sound driver to communicate with each to other.
Signed-off-by: Oleksandr Andrushchenko
Signed-off-by: Oleksandr Grytsov
Signed-off-by: Oleksandr Dmytryshyn
Signed-off-by: Iurii Konovalenko
---
Changes sin
From: Oleksandr Andrushchenko
Hi, all!
Please find the next version of the ABI for the PV sound
after addressing review comments.
Thank you,
Oleksandr Andrushchenko
Oleksandr Grytsov
Oleksandr Andrushchenko (1):
xen: add para-virtual sound interface header file
include/xen/interface/io/snd
>>> On 23.11.16 at 16:38, wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -1181,20 +1181,38 @@ static int ioport_access_check(
> return rc;
>
> /* Ensure the TSS has an io-bitmap-offset field. */
> -generate_exception_if
Hi Andrew,
On 24/11/16 15:53, Andrew Cooper wrote:
On 24/11/16 15:48, Bhupinder Thakur wrote:
Hi,
I am facing an issue where the recompilation fails when you build for
ARM32 architecture on an existing build of ARM64.
Even if I do make clean/make distclean before compiling for different
archi
On 24/11/16 15:48, Bhupinder Thakur wrote:
Hi,
Hello Bhupinder,
I am facing an issue where the recompilation fails when you build for
ARM32 architecture on an existing build of ARM64.
Even if I do make clean/make distclean before compiling for different
architecture it still fails.
Steps
On 24/11/16 15:48, Bhupinder Thakur wrote:
> Hi,
>
> I am facing an issue where the recompilation fails when you build for
> ARM32 architecture on an existing build of ARM64.
>
> Even if I do make clean/make distclean before compiling for different
> architecture it still fails.
>
> Steps to reprod
Hi,
I am facing an issue where the recompilation fails when you build for ARM32
architecture on an existing build of ARM64.
Even if I do make clean/make distclean before compiling for different
architecture it still fails.
Steps to reproduce the issue:
1. git clone git://xenbits.xen.org/xen.git
On 24.11.16 17:09, Julien Grall wrote:
> Hi Artem,
>
> On 24/11/16 14:58, Artem Mygaiev wrote:
>> On 24.11.16 15:31, Jan Beulich wrote:
>> On 24.11.16 at 14:18, wrote:
On 24.11.16 15:04, Jan Beulich wrote:
>> In my case I need it to at least define Linux specific __packed
>> att
>>> On 23.11.16 at 16:38, wrote:
> All system segments (GDT/IDT/LDT and TR) describe a linear address and limit,
> and act similarly to user segments. However all current uses of these tables
> in the emulator opencode the address calculations and limit checks. In
> particular, no care is taken
On Thu, Nov 24, 2016 at 03:40:44PM +, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
Release-acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Thu, Nov 24, 2016 at 03:40:43PM +, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
Release-acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
> One thing which I think you should have clarified up front is why
> the existing fbfront is neither sufficient nor possible to extend
> suitably.
Framebuffer device is rather outdated way for Linux user-space
to draw. All modern software expects DRM/KMS drivers and as
a fallback *may* use fbdev.
>>> On 23.11.16 at 16:38, wrote:
> The functions use linear addresses, not virtual addresses, as no segmentation
> is used. (Lots of other code in Xen makes this mistake.)
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mai
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Jun Nakajima
CC: Kevin Tian
CC: Wei Liu
---
xen/arch/x86/hvm/vmx/vmx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 0a52624..7b2c50c 100644
--- a/xen/arch/
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Paul Durrant
CC: Wei Liu
---
xen/arch/x86/hvm/emulate.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 5f34991..f1f6e2f 100644
--- a/xen/arch/x86/hvm/emulat
Sorry about that, will fix
On Thu, Nov 24, 2016 at 5:05 PM, Lars Kurth wrote:
>
> Oleksandr,
>
>
> On 24/11/2016 11:30, "Oleksandr Andrushchenko" wrote:
>
>>This is the ABI for the two halves of a para-virtualized
>>DRM/KMS driver.
>>
>>Signed-off-by: Oleksandr Andrushchenko
>>Signed-off-by: Ol
>>> On 24.11.16 at 16:14, wrote:
> When dumping ACPI C states, here's how things look like for _all_ CPUs:
> Nov 23 13:13:00.382134 (XEN) ==cpu3==
> Nov 23 13:13:00.382157 (XEN) active state:C-1
> Nov 23 13:13:00.390096 (XEN) max_cstate: C7
> Nov 23 13:13:00.390125 (XEN) s
> This is not critical/important ATM, and completely disconnected from the
> purpose of the patch, so I agree it has to be rewritten according to
> current practices.
Agree, will resend new patch v10 soon
Thank you all
___
Xen-devel mailing list
Xen-dev
>>> On 23.11.16 at 16:38, wrote:
> +case x86_seg_tr:
> +ASSERT(reg->attr.fields.p); /* Usable. */
> +ASSERT(!reg->attr.fields.s); /* System segment. */
> +ASSERT(!(reg->sel & 0x4)); /* !TI. */
> +ASSERT(reg->att
On Wed, 2016-11-23 at 15:54 +, osstest service owner wrote:
> flight 102522 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/102522/
>
> Regressions which are regarded as allowable (not blocking):
> test-amd64-amd64-xl-rtds 9 debian-
> install fai
>>> On 24.11.16 at 15:58, wrote:
> On 24.11.16 15:31, Jan Beulich wrote:
> On 24.11.16 at 14:18, wrote:
>>> On 24.11.16 15:04, Jan Beulich wrote:
> In my case I need it to at least define Linux specific __packed
> attribute which is not supported by Win AFAIK.
... needs to avoid
1 - 100 of 165 matches
Mail list logo
