>>> On 29.09.16 at 01:48, wrote:
> @@ -265,11 +266,30 @@ void pci_setup(void)
> bars[i].devfn = devfn;
> bars[i].bar_reg = bar_reg;
> bars[i].bar_sz = bar_sz;
> +bars[i].above_4gb = false;
>
> if ( ((bar_data & PCI_BASE_ADDRESS_S
This run is configured for baseline tests only.
flight 67780 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67780/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw 9 debian-di-insta
>>> On 29.09.16 at 03:19, wrote:
> Add macros for HVM_PARAM_CALLBACK_TYPE_PPI operation values and update
> them in evtchn_fixup().
>
> Also use HVM_PARAM_CALLBACK_IRQ_TYPE_MASK in hvm_set_callback_via().
>
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Signed-off-by: Shannon Zhao
Acked-by: Jan Beu
>>> On 29.09.16 at 00:51, wrote:
> Currently xen ELF end of image address is calculated using first line from
> "nm -nr xen/xen-syms" output. However, potentially it may contain symbol
> address not related to the end of image in any way. It can happen if a symbol
> is introduced with address larg
>>> On 29.09.16 at 00:51, wrote:
> v8 - suggestions/fixes:
>- disable whole ebmalloc machinery on ARM platforms,
This is certainly not in line with my understanding of the outcome of
that discussion.
> --- a/xen/arch/x86/efi/stub.c
> +++ b/xen/arch/x86/efi/stub.c
> @@ -9,6 +9,8 @@ bool efi_e
>>> On 29.09.16 at 00:51, wrote:
> @@ -384,6 +391,15 @@ __start:
> cmp %edi,MB2_fixed_total_size(%ebx)
> jbe trampoline_bios_setup
>
> +/* Get Xen image load base address from Multiboot2 information. */
> +cmpl$MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR,MB2_
On Thu, Sep 29, 2016 at 01:34:30AM -0600, Jan Beulich wrote:
> >>> On 29.09.16 at 00:51, wrote:
> > Currently xen ELF end of image address is calculated using first line from
> > "nm -nr xen/xen-syms" output. However, potentially it may contain symbol
> > address not related to the end of image in
>>> On 29.09.16 at 09:51, wrote:
> On Thu, Sep 29, 2016 at 01:34:30AM -0600, Jan Beulich wrote:
>> >>> On 29.09.16 at 00:51, wrote:
>> > --- a/xen/arch/x86/Makefile
>> > +++ b/xen/arch/x86/Makefile
>> > @@ -91,7 +91,7 @@ endif
>> >
>> > $(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
>> >./b
On Thu, Sep 29, 2016 at 01:40:44AM -0600, Jan Beulich wrote:
> >>> On 29.09.16 at 00:51, wrote:
> > v8 - suggestions/fixes:
> >- disable whole ebmalloc machinery on ARM platforms,
>
> This is certainly not in line with my understanding of the outcome of
> that discussion.
Well, I understand t
On Thu, Sep 29, 2016 at 02:01:46AM -0600, Jan Beulich wrote:
> >>> On 29.09.16 at 09:51, wrote:
> > On Thu, Sep 29, 2016 at 01:34:30AM -0600, Jan Beulich wrote:
> >> >>> On 29.09.16 at 00:51, wrote:
> >> > --- a/xen/arch/x86/Makefile
> >> > +++ b/xen/arch/x86/Makefile
> >> > @@ -91,7 +91,7 @@ end
>>> On 29.09.16 at 10:17, wrote:
> On Thu, Sep 29, 2016 at 02:01:46AM -0600, Jan Beulich wrote:
>> >>> On 29.09.16 at 09:51, wrote:
>> > On Thu, Sep 29, 2016 at 01:34:30AM -0600, Jan Beulich wrote:
>> >> >>> On 29.09.16 at 00:51, wrote:
>> >> > --- a/xen/arch/x86/Makefile
>> >> > +++ b/xen/arch/
>>> On 28.09.16 at 19:05, wrote:
> Attached is the full dmesg output -
>
> Filesystem was copied in full from a running real-iron server (no errors)
> to a VMware virtual disk. No errors booting the system directly into
> Linux, and this occurs with 4.7.x builds of Xen as well.
>
> I'm not sure
On 28/09/16 09:09, Jan Beulich wrote:
> This way we can at least size (and e.g. skip) them if needed, and we
> also won't raise the wrong fault due to not having read all relevant
> bytes.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper . I think... The
prefix decoding is getting very
On 28/09/16 09:10, Jan Beulich wrote:
> This way we can at least size (and e.g. skip) them if needed, and we
> also won't raise the wrong fault due to not having read all relevant
> bytes.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
On Thu, Sep 29, 2016 at 01:03:02AM -0600, Jan Beulich wrote:
> >>> On 29.09.16 at 01:48, wrote:
> > @@ -265,11 +266,30 @@ void pci_setup(void)
> > bars[i].devfn = devfn;
> > bars[i].bar_reg = bar_reg;
> > bars[i].bar_sz = bar_sz;
> > +bars[i].a
>>> On 29.09.16 at 11:11, wrote:
> The commit a3db233 x86emul: use DstEax also for {,I}{MUL,DIV}
> introduces an regression when doing SR-IOV passthrough.
I'll see if I can repro, but I can't see anything wrong with the
commit (yet). The more that ...
> Specifically I get:
> ..
> (d1) Invoking R
>>> On 29.09.16 at 11:23, wrote:
> On Thu, Sep 29, 2016 at 01:03:02AM -0600, Jan Beulich wrote:
>> >>> On 29.09.16 at 01:48, wrote:
>> > @@ -265,11 +266,30 @@ void pci_setup(void)
>> > bars[i].devfn = devfn;
>> > bars[i].bar_reg = bar_reg;
>> > bars[i].bar
Julien Grall writes ("Re: [PATCH] pub-headers: reduce C99 dependencies"):
> I am not the author of the code, but I think it was to declare all the
> constants of a given set uniformed.
>
> For instance all the GUEST_* constants are used to define the layout of
> the guest. This may be shuffle in
On Thu, Sep 29, 2016 at 01:13:26AM -0600, Jan Beulich wrote:
> >>> On 29.09.16 at 03:19, wrote:
> > Add macros for HVM_PARAM_CALLBACK_TYPE_PPI operation values and update
> > them in evtchn_fixup().
> >
> > Also use HVM_PARAM_CALLBACK_IRQ_TYPE_MASK in hvm_set_callback_via().
> >
> > Cc: Jan Beul
>>> On 29.09.16 at 11:34, wrote:
On 29.09.16 at 11:11, wrote:
>> The commit a3db233 x86emul: use DstEax also for {,I}{MUL,DIV}
>> introduces an regression when doing SR-IOV passthrough.
>
> I'll see if I can repro, but I can't see anything wrong with the
> commit (yet).
And sadly I can't.
On Wed, Sep 28, 2016 at 06:18:50PM -0700, Shannon Zhao wrote:
> Estimate the size of ACPI tables and reserve a memory map space for ACPI
> tables.
>
> Signed-off-by: Shannon Zhao
Acked-by: Wei Liu
Thanks for the quick turnaround.
___
Xen-devel maili
On Wed, Sep 28, 2016 at 06:19:02PM -0700, Shannon Zhao wrote:
> Here it adds the ACPI tables size to set the target maxmem to avoid
> providing less available memory for guest.
>
> Signed-off-by: Shannon Zhao
Acked-by: Wei Liu
___
Xen-devel mailing l
flight 101199 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101199/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf edb0fda25ea9b2ef73db18bf5cf0798340209f28
baseline version:
ovmf ab970515d2c6ec657fcea
On 28/09/16 09:12, Jan Beulich wrote:
> @@ -1732,13 +1745,35 @@ x86_decode_twobyte(
> }
>
> static int
> +x86_decode_0f38(
> +struct x86_emulate_state *state,
> +struct x86_emulate_ctxt *ctxt,
> +const struct x86_emulate_ops *ops)
> +{
> +switch ( ctxt->opcode & X86EMUL_OPC_MASK
>>> On 27.09.16 at 17:56, wrote:
> Return should be an int, and the number of pages should be an unsigned long.
I can see the former, but why the latter? Acting on 32-bit quantities
is a little cheaper after all.
Jan
___
Xen-devel mailing list
Xen-de
>>> On 27.09.16 at 17:56, wrote:
> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -379,7 +379,9 @@ hap_set_allocation(struct domain *d, unsigned long pages,
> int *preempted)
> break;
>
> /* Check to see if we need to yield and try again */
> -
>>> On 27.09.16 at 17:57, wrote:
> It doesn't make sense since the idle domain doesn't receive any events.
The change itself is fine, but I think it would help if the commit
message made explicit why this is becoming relevant.
Jan
___
Xen-devel maili
On Thu, Sep 29, 2016 at 03:36:00AM -0600, Jan Beulich wrote:
> >>> On 29.09.16 at 11:23, wrote:
> > On Thu, Sep 29, 2016 at 01:03:02AM -0600, Jan Beulich wrote:
> >> >>> On 29.09.16 at 01:48, wrote:
> >> > @@ -265,11 +266,30 @@ void pci_setup(void)
> >> > bars[i].devfn = devfn;
> >
>>> On 27.09.16 at 17:57, wrote:
> @@ -1383,15 +1382,25 @@ int __init construct_dom0(
> nr_pages);
> }
>
> -if ( is_pvh_domain(d) )
> -hap_set_alloc_for_pvh_dom0(d, dom0_paging_pages(d, nr_pages));
> -
> /*
> * We enable paging mode again so
On 17/08/16 18:19, Dario Faggioli wrote:
> For get_fallback_cpu(), by putting in place the "usual"
> two steps (soft affinity step and hard affinity step)
> loop. We just move the core logic of the function inside
> the body of the loop itself.
>
> For csched2_cpu_pick(), what is important is to f
>>> On 29.09.16 at 11:34, wrote:
On 29.09.16 at 11:11, wrote:
>> The commit a3db233 x86emul: use DstEax also for {,I}{MUL,DIV}
>> introduces an regression when doing SR-IOV passthrough.
>
> I'll see if I can repro,
Actually, I can see some variant of this (and without any SR-IOV), as
soon
On Thu, Sep 29, 2016 at 10:08:30AM +0200, Daniel Kiper wrote:
> On Thu, Sep 29, 2016 at 01:40:44AM -0600, Jan Beulich wrote:
> > >>> On 29.09.16 at 00:51, wrote:
> > > v8 - suggestions/fixes:
> > >- disable whole ebmalloc machinery on ARM platforms,
> >
> > This is certainly not in line with m
flight 101207 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101207/
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
flight 67783 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67783/
Perfect :-)
All tests in this flight passed as required
baseline version:
flight 67745
jobs:
build-amd64 pass
build-armh
On Wed, Sep 28, 2016 at 09:35:21AM -0600, Jan Beulich wrote:
> >>> On 27.09.16 at 17:56, wrote:
> > This is also required for PVHv2 guests if they want to use real-mode, and
> > hvmloader is not executed for those kind of guests.
>
> While the intention is fine, I'm not convinced of consuming yet
Commit a3db233ede ("x86emul: use DstEax also for {,I}{MUL,DIV}") went
a little too far: DstEax and SrcEax weren't really meant to be used
together with ModRM - they assume modrm_reg remains zero by the time
the destination / source register pointer gets calculated. Don't fully
undo that commit thou
There's no 1-byte operand size case to take care of here, and there's
no point doing the first writeback using dst fields - we can read rBP
and write rSP directly.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -3130,21 +31
This run is configured for baseline tests only.
flight 67782 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67782/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-multivcpu 6 xen-boot
Hello,
My name is Jason Dickens and I'm a Research Scientist here at
GrammaTech. Some of our research involves securing hypervisors and we
have needed to add to and/or modify Xen. I have been successful in
modifying the source for various purposes, but my question now is about
devices. We hav
flight 101197 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101197/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101076
test-amd64-i386-xl-qemuu
>>> On 27.09.16 at 17:57, wrote:
> So that it can also be used by the PVH-specific domain builder. This is just
> code motion, it should not introduce any functional change.
>
> Signed-off-by: Roger Pau Monné
Looks generally okay, but please do minor style corrections as you
move code:
> --- a
As long as t_info_first_offset is calculated in uint32_t offsets we need to
multiply it by sizeof(uint32_t) in order to get the right number of pages
for trace metadata. Not doing that makes it impossible to read the trace
buffer correctly from userspace for some corner cases.
Signed-off-by: Igor
>>> On 27.09.16 at 17:57, wrote:
> Instead of being tied to the presence of an IOMMU
At the very least I'd expect the "why" aspect to get mentioned
here.
> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> @@ -219,7 +219,8 @@ int __init amd_i
On Wed, Sep 28, 2016 at 10:03:21AM -0600, Jan Beulich wrote:
> >>> On 27.09.16 at 17:56, wrote:
> > On PVHv2 guests we explicitly want to use native methods for routing
> > interrupts.
> >
> > Introduce a new XEN_X86_EMU_USE_PIRQ to notify Xen whether a HVM guest can
> > route physical interrupts
>>> On 27.09.16 at 17:57, wrote:
> The current code used by Intel VTd will only map RMRR regions for the
> hardware domain, but will fail to map RMRR regions for unprivileged domains
> unless the page tables are shared between EPT and IOMMU.
Okay, if that's the case it surely should get fixed.
>
>>> On 27.09.16 at 17:57, wrote:
> +static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
> +{
> +
> +if ( is_hvm_domain(d) )
> +{
> +if ( is_hardware_domain(d) &&
> + emflags !=
> (XEN_X86_EMU_PIT|XEN_X86_EMU_LAPIC|XEN_X86_EMU_IOAPIC))
> +
On Thu, Sep 29, 2016 at 04:39:02AM -0600, Jan Beulich wrote:
> >>> On 27.09.16 at 17:56, wrote:
> > Return should be an int, and the number of pages should be an unsigned long.
>
> I can see the former, but why the latter? Acting on 32-bit quantities
> is a little cheaper after all.
This was req
On Thu, Sep 29, 2016 at 04:43:07AM -0600, Jan Beulich wrote:
> >>> On 27.09.16 at 17:56, wrote:
> > --- a/xen/arch/x86/mm/hap/hap.c
> > +++ b/xen/arch/x86/mm/hap/hap.c
> > @@ -379,7 +379,9 @@ hap_set_allocation(struct domain *d, unsigned long
> > pages, int *preempted)
> > break;
> >
On 27/09/16 10:51, Gerd Hoffmann wrote:
> On Mo, 2016-09-26 at 14:43 +0200, Juergen Gross wrote:
>> Trying to use pvUSB in a Xen guest with a qemu emulated USB controller
>> will crash qemu as it tries to attach a pvUSB device to the emulated
>> controller.
>
> Hmm. --verbose please.
>
> While t
On 27/09/16 10:53, Gerd Hoffmann wrote:
> On Mo, 2016-09-26 at 14:43 +0200, Juergen Gross wrote:
>> Add a bus for Xen backend devices in order to be able to establish a
>> dedicated device path for pluggable devices.
>
> Looks sane to me. Can take this through the usb queue if I get an ack
> from
On 27/09/16 11:00, Daniel P. Berrange wrote:
> On Mon, Sep 26, 2016 at 02:43:57PM +0200, Juergen Gross wrote:
>> In order to be able to specify to which pvusb controller a new pvusb
>> device should be added we need a qemu device for each pvusb controller
>> with an associated id.
>>
>> Add such a
On 27/09/16 11:08, Gerd Hoffmann wrote:
> Hi,
>
>> struct usbback_info {
>> struct XenDevice xendev; /* must be first */
>> +char id[24];
>> +struct USBBACKDevice *dev;
>> USBBus bus;
>> void *urb_srin
On Thu, Sep 29, 2016 at 04:51:42AM -0600, Jan Beulich wrote:
> >>> On 27.09.16 at 17:57, wrote:
> > @@ -1383,15 +1382,25 @@ int __init construct_dom0(
> > nr_pages);
> > }
> >
> > -if ( is_pvh_domain(d) )
> > -hap_set_alloc_for_pvh_dom0(d, dom0_paging_p
flight 101200 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101200/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-xsm 14 guest-sav
flight 101202 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101202/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 101182
Regressions which
On Thu, Sep 29, 2016 at 07:55:00AM -0600, Jan Beulich wrote:
> >>> On 27.09.16 at 17:57, wrote:
> > Instead of being tied to the presence of an IOMMU
>
> At the very least I'd expect the "why" aspect to get mentioned
> here.
TBH, it seems simpler to have it there rather than conditional to the
Hi,
> > Hmm, I think the xen core needs better QOM support ...
> >
> > struct XenDevice should have a DeviceState element, so it can be used as
> > device object directly instead of attaching a device object like
> > this ...
>
> Hmm, interesting idea. The device object could even be added in
On Tue, 2016-09-13 at 12:13 +0100, George Dunlap wrote:
> On 05/09/16 14:47, Dario Faggioli wrote:
> > On Wed, 2016-08-31 at 18:10 +0100, anshul makkar wrote:
> > > > @@ -1273,6 +1280,7 @@ csched2_alloc_vdata(const struct
> > > > scheduler
> > > > *ops, struct vcpu *vc, void *dd)
> > > > else
flight 101203 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101203/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101186
test-amd64-amd64-xl-rtds
On Thu, Sep 29, 2016 at 07:47:22AM -0600, Jan Beulich wrote:
> >>> On 27.09.16 at 17:57, wrote:
> > So that it can also be used by the PVH-specific domain builder. This is just
> > code motion, it should not introduce any functional change.
> >
> > Signed-off-by: Roger Pau Monné
>
> Looks gener
flight 101206 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101206/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 84bc72fb7ddaa26105bfe5bf36115099da1e60b1
baseline version:
ovmf edb0fda25ea9b2ef73db1
On Tue, 2016-09-13 at 14:33 +0100, George Dunlap wrote:
> On 17/08/16 18:18, Dario Faggioli wrote:
> > Alternatively, we can actually _subtract_ some credits to a
> > yielding vcpu.
> > That will sort of make the effect of a call to yield last in time.
>
> But normally we want the yield to be temp
>>> On 29.09.16 at 16:17, wrote:
> On Wed, Sep 28, 2016 at 10:03:21AM -0600, Jan Beulich wrote:
>> >>> On 27.09.16 at 17:56, wrote:
>> > On PVHv2 guests we explicitly want to use native methods for routing
>> > interrupts.
>> >
>> > Introduce a new XEN_X86_EMU_USE_PIRQ to notify Xen whether a HV
>>> On 29.09.16 at 16:33, wrote:
> On Thu, Sep 29, 2016 at 04:39:02AM -0600, Jan Beulich wrote:
>> >>> On 27.09.16 at 17:56, wrote:
>> > Return should be an int, and the number of pages should be an unsigned
>> > long.
>>
>> I can see the former, but why the latter? Acting on 32-bit quantities
>>> On 29.09.16 at 16:37, wrote:
> On Thu, Sep 29, 2016 at 04:43:07AM -0600, Jan Beulich wrote:
>> >>> On 27.09.16 at 17:56, wrote:
>> > --- a/xen/arch/x86/mm/hap/hap.c
>> > +++ b/xen/arch/x86/mm/hap/hap.c
>> > @@ -379,7 +379,9 @@ hap_set_allocation(struct domain *d, unsigned long
> pages, int *
>>> On 29.09.16 at 16:51, wrote:
> On Thu, Sep 29, 2016 at 04:51:42AM -0600, Jan Beulich wrote:
>> >>> On 27.09.16 at 17:57, wrote:
>> > @@ -1383,15 +1382,25 @@ int __init construct_dom0(
>> > nr_pages);
>> > }
>> >
>> > -if ( is_pvh_domain(d) )
>> > -
>>> On 29.09.16 at 17:11, wrote:
> On Thu, Sep 29, 2016 at 07:55:00AM -0600, Jan Beulich wrote:
>> >>> On 27.09.16 at 17:57, wrote:
>> > Instead of being tied to the presence of an IOMMU
>>
>> At the very least I'd expect the "why" aspect to get mentioned
>> here.
>
> TBH, it seems simpler to h
Hi Stefano and all,
while working on some part of the QEMU block layer infrastructure that
requires going from a BlockBackend to the qdev DeviceState, I noticed
that xen_disk is still not qdevified after all the years. It's the last
device, and has been for a while, that is blocking the necessary
On Tue, 2016-09-20 at 14:32 +0100, George Dunlap wrote:
> On 17/08/16 18:18, Dario Faggioli wrote:
> > diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> > @@ -1771,9 +1771,18 @@ csched_schedule(
> > * cpu and steal it.
> > */
> >
> > -/* If we have schedule ra
On Thu, Sep 29, 2016 at 10:12:12AM -0600, Jan Beulich wrote:
> >>> On 29.09.16 at 16:51, wrote:
> > On Thu, Sep 29, 2016 at 04:51:42AM -0600, Jan Beulich wrote:
> >> >>> On 27.09.16 at 17:57, wrote:
> >> > @@ -1383,15 +1382,25 @@ int __init construct_dom0(
> >> > nr_page
On Tue, 2016-09-20 at 15:35 +0100, George Dunlap wrote:
> On 17/08/16 18:18, Dario Faggioli wrote:
> >
> > In both Credit2's trace records relative to checking
> > whether we want to preempt a vcpu (in runq_tickle()),
> > and to credits being burn, make it explicit on which
> > pcpu the vcpu being
On 29/09/16 18:23, Dario Faggioli wrote:
> On Tue, 2016-09-20 at 15:35 +0100, George Dunlap wrote:
>> On 17/08/16 18:18, Dario Faggioli wrote:
>>>
>>> In both Credit2's trace records relative to checking
>>> whether we want to preempt a vcpu (in runq_tickle()),
>>> and to credits being burn, make i
On 29/09/16 14:08, Jan Beulich wrote:
> There's no 1-byte operand size case to take care of here, and there's
> no point doing the first writeback using dst fields - we can read rBP
> and write rSP directly.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
__
Hi Kevin,
I agree with you, and if you would be so kind to send the patches, even
untested, they would be much appreciated. Anthony or I will make sure to
test them appropriately and fix them, if they turn out to be incomplete
or partially broken. Would that be OK?
Cheers,
Stefano
P.S.
FYI Xen
On 29/09/16 14:08, Jan Beulich wrote:
> Commit a3db233ede ("x86emul: use DstEax also for {,I}{MUL,DIV}") went
> a little too far: DstEax and SrcEax weren't really meant to be used
> together with ModRM - they assume modrm_reg remains zero by the time
> the destination / source register pointer gets
On Wed, 28 Sep 2016, Tamas K Lengyel wrote:
> The ARM SMC instructions are already configured to trap to Xen by default. In
> this patch we allow a user-space process in a privileged domain to receive
> notification of when such event happens through the vm_event subsystem by
> introducing the PRIV
On Thu, Sep 29, 2016 at 07:08:10AM -0600, Jan Beulich wrote:
> Commit a3db233ede ("x86emul: use DstEax also for {,I}{MUL,DIV}") went
> a little too far: DstEax and SrcEax weren't really meant to be used
> together with ModRM - they assume modrm_reg remains zero by the time
> the destination / sourc
Hi Jan,
On 28/09/2016 23:04, Jan Beulich wrote:
On 28.09.16 at 21:42, wrote:
Hi Jan,
On 28/09/2016 05:00, Jan Beulich wrote:
For consumers not using (fully) C99-aware compilers, limit the number
of places where tweaking of the headers would be necessary: Introduce
and use xen_mk_ullong(), al
Hi Jan,
On 28/09/2016 05:00, Jan Beulich wrote:
For consumers not using (fully) C99-aware compilers, limit the number
of places where tweaking of the headers would be necessary: Introduce
and use xen_mk_ullong(), allowing its helper macro to be overridden at
once.
For now don't touch public/io/
flight 101211 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101211/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 50b7556924ad173285f4116dc9e0937600bf5bee
baseline version:
xtf 962dd4b225c17ae48d36a9
On 29/09/2016 12:11, Julien Grall wrote:
Hi Jan,
On 28/09/2016 23:04, Jan Beulich wrote:
On 28.09.16 at 21:42, wrote:
Hi Jan,
On 28/09/2016 05:00, Jan Beulich wrote:
For consumers not using (fully) C99-aware compilers, limit the number
of places where tweaking of the headers would be nece
On 28/09/16 09:13, Jan Beulich wrote:
> ... instead of custom handling. To facilitate this break out init code
> from _hvm_emulate_one() into the new hvm_emulate_init(), and make
> hvmemul_insn_fetch( globally available.
)
> int __get_instruction_length_from_list(struct vcpu *v,
> const
On 29/09/16 20:24, Andrew Cooper wrote:
>
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -5200,3 +5214,89 @@ x86_emulate(
>> #undef vex
>> #undef override_seg
>> #undef ea
>> +
>> +#ifdef __XEN__
>> +
>> +#include
>> +
>> +struct x86_emulat
On Thu, Sep 29, 2016 at 12:22:37PM -0700, Julien Grall wrote:
>
>
> On 29/09/2016 12:11, Julien Grall wrote:
> >Hi Jan,
> >
> >On 28/09/2016 23:04, Jan Beulich wrote:
> >On 28.09.16 at 21:42, wrote:
> >>>Hi Jan,
> >>>
> >>>On 28/09/2016 05:00, Jan Beulich wrote:
> For consumers not using
Gerd Hoffmann writes:
> Hi,
>
>> > Hmm, I think the xen core needs better QOM support ...
>> >
>> > struct XenDevice should have a DeviceState element, so it can be used as
>> > device object directly instead of attaching a device object like
>> > this ...
>>
>> Hmm, interesting idea. The dev
On 28/09/16 09:13, Jan Beulich wrote:
> @@ -3204,179 +3285,59 @@ static void emulate_gate_op(struct cpu_u
> return;
> }
>
> -op_bytes = op_default = ar & _SEGMENT_DB ? 4 : 2;
> -ad_default = ad_bytes = op_default;
> -opnd_sel = opnd_off = 0;
> -jump = -1;
> -for
On 28/09/16 09:14, Jan Beulich wrote:
> This is in preparation for using the generic emulator here.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -2255,6 +2255,107 @@ unsigned long guest_to_host_gpr_switch(u
>
> void (*pv_post_outb_hook)(unsigne
On 28/09/16 09:15, Jan Beulich wrote:
> This is in preparation for using the generic emulator here.
>
> Some care is needed temporarily to not unduly alter guest register
> state: The local variable "res" can only go away once this code got
> fully switched over to using x86_emulate().
>
> Also swi
On 28/09/16 09:16, Jan Beulich wrote:
> This is in preparation for using the generic emulator here.
>
> Signed-off-by: Jan Beulich
This looks like only code motion, so Reviewed-by: Andrew Cooper
There is some rather unhelpful behaviour with the cases where we
silently discard access to MSRs suc
On 28/09/16 09:17, Jan Beulich wrote:
> This is a prereq for switching PV privileged op emulation to the
> generic instruction emulator. Since handle_xsetbv() is already capable
> of dealing with all guest kinds, avoid introducing another hook here.
>
> Signed-off-by: Jan Beulich
Reviewed-by: And
On 28/09/16 09:18, Jan Beulich wrote:
> Sort the special case opcode 0f01 entries numerically, insert blank
> lines between each of the cases, and properly place opening braces.
>
> No functional change.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
_
flight 101212 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101212/
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 Thu, 2016-09-29 at 18:28 +0100, George Dunlap wrote:
> On 29/09/16 18:23, Dario Faggioli wrote:
> > In that case, knowing where a certain vcpu that we're asking to
> > burn
> > its credit is running, may mean going quite a bit up in the trace,
> > to
> > find its last context switch/runstate cha
On 28/09/16 09:19, Jan Beulich wrote:
> Especially for x86_insn_operand_ea() to return dependable segment
> information even when the caller didn't consider applicability, we
> shouldn't have ea.type start out as OP_MEM. Make it OP_NONE instead,
> and set it to OP_MEM when we actually encounter mem
On 28/09/16 09:18, Jan Beulich wrote:
> There's a new emulator return code being added to allow bypassing
> certain operations (see the code comment). Its handling in the epilogue
> code involves moving the raising of the single step trap until after
> registers were updated. This should probably h
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 allocate a memory fro
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
---
v9 - suggestions/fixes:
- use
First of all we need to differentiate between legacy BIOS
and EFI platforms during runtime, not during build, because
one image will have legacy and EFI code and can be executed
on both platforms. Additionally, we need more fine grained
knowledge about EFI environment and check for EFI platform
and
Hi,
I am sending ninth 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, multiboot (v1) protocol (only on legacy BIOS platforms) and
mu
This patch is prereq for "efi: build xen.gz with EFI code" patch which adds,
among others, xen/arch/x86/efi/relocs-dummy.S to xen.gz output. Below there
is a description why it is needed.
Currently xen ELF end of image address is calculated using first line from
"nm -nr xen/xen-syms" output. Howev
1 - 100 of 129 matches
Mail list logo
