On 22/02/17 07:53, Juergen Gross wrote:
> On 20/02/17 16:19, Andrew Cooper wrote:
>> On 20/02/17 14:43, Juergen Gross wrote:
>>> On 20/02/17 15:31, Wei Liu wrote:
On Thu, Feb 16, 2017 at 08:47:07AM +0100, Juergen Gross wrote:
> There have been reports that Fedora 25 uses /run instead of /v
On 22/02/17 07:23, Jan Beulich wrote:
On 21.02.17 at 18:35, wrote:
>> On 21/02/17 17:16, Jan Beulich wrote:
>> On 20.02.17 at 12:00, wrote:
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -163,6 +163,9 @@ static void recalculate_xstate(struct cpuid_policy *p)
>>> On 22.02.17 at 08:47, wrote:
> On 02/22/2017 09:40 AM, Jan Beulich wrote:
> On 22.02.17 at 08:16, wrote:
>>> 3. C89 - Jan, we discussed that a bit for zero-sized arrays [2]
>>> and empty structures [3]. So, then we came to a conclusion that
>>> breakage is not acceptable, but now I see th
On 20/02/17 16:19, Andrew Cooper wrote:
> On 20/02/17 14:43, Juergen Gross wrote:
>> On 20/02/17 15:31, Wei Liu wrote:
>>> On Thu, Feb 16, 2017 at 08:47:07AM +0100, Juergen Gross wrote:
There have been reports that Fedora 25 uses /run instead of /var/run.
Add a --with-rundir option i
On 02/22/2017 09:40 AM, Jan Beulich wrote:
On 22.02.17 at 08:16, wrote:
3. C89 - Jan, we discussed that a bit for zero-sized arrays [2]
and empty structures [3]. So, then we came to a conclusion that
breakage is not acceptable, but now I see that you have changed
your mind? (Please correct me i
>>> On 22.02.17 at 03:20, wrote:
> On 02/22/17 09:28 +0800, Haozhong Zhang wrote:
>> On 02/21/17 02:15 -0700, Jan Beulich wrote:
>> > >>> On 21.02.17 at 03:11, wrote:
> [..]
>> > > + *
>> > > + * Therefore, we clear the nested guest flag before
>> > > __raw_copy_to_guest()
>> > > +
>>> On 22.02.17 at 08:16, wrote:
> 3. C89 - Jan, we discussed that a bit for zero-sized arrays [2]
> and empty structures [3]. So, then we came to a conclusion that
> breakage is not acceptable, but now I see that you have changed
> your mind? (Please correct me if I got it wrong). The reason I am
>>> On 21.02.17 at 18:40, wrote:
> On 21/02/17 17:25, Jan Beulich wrote:
> On 20.02.17 at 12:00, wrote:
>>> The thermal/performance leaf was previously hidden from HVM guests, but
> fully
>>> visible to PV guests. Most of the leaf refers to MSR availability, and
> there
>>> is nothing an u
>>> On 21.02.17 at 18:35, wrote:
> On 21/02/17 17:16, Jan Beulich wrote:
> On 20.02.17 at 12:00, wrote:
>>> --- a/xen/arch/x86/cpuid.c
>>> +++ b/xen/arch/x86/cpuid.c
>>> @@ -163,6 +163,9 @@ static void recalculate_xstate(struct cpuid_policy *p)
>>> */
>>> static void recalculate_misc(struc
>>> On 21.02.17 at 18:29, wrote:
> On 21/02/17 17:20, Jan Beulich wrote:
>>
> The final 8 bits are the initial legacy APIC ID. For HVM guests, this was
> overridden to vcpu_id * 2. The same logic is now applied to PV guests, so
> guests don't observe a constant number on all vcpus vi
Hi, Stefano, Jan!
1. Stefano, are you still NOT considering adding
functionality to avoid memory copying? We discussed
this a little bit here [1].
2. Will you also provide macros/inlines for fixed sized packets?
So, others do not reinvent the wheel again on top of your code.
3. C89 - Jan, we
>>> On 21.02.17 at 18:42, wrote:
> On 21/02/17 17:17, Jan Beulich wrote:
> On 21.02.17 at 18:12, wrote:
>>> Which particular feature groups? I could extend that text to say
>>>
>>> "VEX/XOP-encoded GPR instructions, such as those from the BMI{1,2} and
>>> $X sets..."
>> TBM and LWP.
>
> Ok.
Hi Andre,
On Tue, Jan 31, 2017 at 12:01 AM, 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 have to map each device that Dom0 may request to a host
> ITS device with the same identifier.
flight 105958 qemu-upstream-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105958/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-localmigrate/x10 fail REGR. vs.
105693
On 2017-02-21 23:10, Stefano Stabellini wrote:
On Tue, 21 Feb 2017, Géza Gémes wrote:
Hi,
I've tried to run the raisin test suite, while pv tests pass the hvm tests
fail. I've identified a number of problems, starting with two small disk size
to formating the whole disk and then being unable to
* Paolo Bonzini wrote:
> > Paolo, how stable, non-rebasing are the KVM tree commits?
>
> Whatever ends in linux-next is stable. I have a separate rebasing branch,
> but it's not part of linux-next by design.
Ok, that's nice!
> > Or should we keep Andy's KVM patches together with the GDT patc
This run is configured for baseline tests only.
flight 68596 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68596/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pygrub 13 guest-saverest
This run is configured for baseline tests only.
flight 68597 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68597/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 85520606ad459ba7d825c7ea5f225cffa1dbe95b
baseline v
Xen.org security team submitted a new ticket to Firelay/Proteon Support Portal
and requested that we copy you Ticket Description: -BEGIN PGP SIGNED
MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2017-2620 / XSA-209
version 3
cirrus_bitblt_
flight 105957 qemu-upstream-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105957/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a
test-arm64-arm64-xl
Hi, everyone. Really sorry for digging out this thread. Because feng has left
Intel, I will take over this work, address some problems in his v8 patch set
and send out a v9 verson later such that VT-d PI can work properly on Xen.
Thanks,
Chao
On Fri, Nov 18, 2016 at 09:57:17AM +0800, Wu, Feng w
On Tue, Feb 21, 2017 at 07:20:29PM +, Julien Grall wrote:
>
>
> On 21/02/2017 18:30, Stefano Stabellini wrote:
> >On Tue, 21 Feb 2017, Julien Grall wrote:
> >>Hi Stefano,
> >>
> >>On 21/02/17 17:49, Stefano Stabellini wrote:
> >>>On Tue, 21 Feb 2017, Dario Faggioli wrote:
> On Tue, 2017-0
On Mon, Feb 13, 2017 at 03:35:19PM +, Julien Grall wrote:
> On 02/02/17 15:33, Edgar E. Iglesias wrote:
> >On Wed, Feb 01, 2017 at 07:04:43PM +, Julien Grall wrote:
> >>On 31/01/2017 19:06, Edgar E. Iglesias wrote:
> >>>On Tue, Jan 31, 2017 at 05:09:53PM +, Julien Grall wrote:
> >>Thank
flight 105955 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105955/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 105894
test-armhf-armhf-
flight 105956 qemu-upstream-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105956/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 guest-stop/l1/l2 fail REGR. vs. 105732
Regre
> From: Zhang, Haozhong
> Sent: Wednesday, February 22, 2017 10:21 AM
> >
> > >
> > > And why is this HAP-specific?
> > >
> >
> > IIUC, nested HVM relies on HAP.
>
> For nested SVM, I find the following check in hvmop_set_param():
> case HVM_PARAM_NESTEDHVM:
> if ( cpu_has_svm && !pagi
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: Tuesday, February 21, 2017 10:10 PM
>
> On 02/21/2017 03:09 AM, Tian, Kevin wrote:
> >> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> >> Sent: Saturday, February 18, 2017 1:40 AM
> >>
> >> vpmu_enabled() (used by hvm
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, February 21, 2017 7:25 PM
>
> On 21/02/17 09:13, Tian, Kevin wrote:
> >> @@ -2618,6 +2630,56 @@ static const struct lbr_info
> >> *last_branch_msr_get(void)
> >> return NULL;
> >> }
> >>
> >> +enum
> >> +{
> >> +L
On 02/22/17 09:28 +0800, Haozhong Zhang wrote:
> On 02/21/17 02:15 -0700, Jan Beulich wrote:
> > >>> On 21.02.17 at 03:11, wrote:
[..]
> > > + *
> > > + * Therefore, we clear the nested guest flag before
> > > __raw_copy_to_guest()
> > > + * and __copy_to_guest(), and restore the fla
On 02/21/17 02:15 -0700, Jan Beulich wrote:
> >>> On 21.02.17 at 03:11, wrote:
> > For a HVM domain, if a vcpu is in the nested guest mode,
> > __raw_copy_to_guest() and __copy_to_guest() used by
> > update_runstate_area() will copy data to L2 guest other than L1 guest.
> >
> > Besides copying to
This run is configured for baseline tests only.
flight 68589 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68589/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-220 xtf/test-hvm32-
flight 105952 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105952/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs.
105928
Regressions which ar
On 21/02/2017 23:45, osstest service owner wrote:
> flight 105948 xen-4.7-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/105948/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-xl-credit2 17
flight 105948 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105948/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 17 guest-localmigrate/x10 fail REGR. vs. 105855
Regressions whi
This patch introduces macros, structs and functions to handle rings in
the format described by docs/misc/pvcalls.markdown and
docs/misc/9pfs.markdown. The index page (struct __name##_data_intf)
contains the indexes and the grant refs to setup two rings.
Indexes page
+
On Tue, 21 Feb 2017, Jan Beulich wrote:
> >>> On 21.02.17 at 00:26, wrote:
> > On Mon, 20 Feb 2017, Jan Beulich wrote:
> >> >>> On 17.02.17 at 23:38, wrote:
> >> But the use of inline functions here is questionable
> >> in the first place - so far there are none, as they're not standard
> >> C89.
On Tue, 21 Feb 2017, Jan Beulich wrote:
> >>> On 21.02.17 at 02:32, wrote:
> > +static inline void name##_read_packet(char *buf,
> >\
> > +RING_IDX *masked_prod, RING_IDX *masked_cons,
> >\
>
> The const/indirection problems is stil
flight 105946 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105946/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail
REGR. vs. 105933
Reg
On Tue, 21 Feb 2017, Géza Gémes wrote:
> Hi,
>
> I've tried to run the raisin test suite, while pv tests pass the hvm tests
> fail. I've identified a number of problems, starting with two small disk size
> to formating the whole disk and then being unable to install grub to the boot
> sector. I've
Wei Liu, on lun. 20 févr. 2017 15:20:08 +, wrote:
> On Mon, Feb 20, 2017 at 03:14:27PM +, Paul Durrant wrote:
> > > From: Wei Liu [mailto:wei.l...@citrix.com]
> > > > > [2]
> > > > > http://xenbits.xen.org/gitweb/?p=people/pauldu/mini-os.git;a=commit;h=41c9f2ae
> > > > >
> > >
> > > Need
flight 105954 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105954/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf f3cbcfed8a591b5fd9ec99bb7252785e2235179d
baseline version:
xtf 2b8c78575cb534908ccc88
flight 105949 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105949/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 85520606ad459ba7d825c7ea5f225cffa1dbe95b
baseline version:
ovmf 5af4388433e13ffeda980
As some users have suggested, elaborate the usage of RMRR specification
on the command line, and provide a usage example.
Signed-off-by: Venu Busireddy
---
docs/misc/xen-command-line.markdown |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/docs/misc/xen-command-l
This run is configured for baseline tests only.
flight 68587 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68587/
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
flight 105943 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105943/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 105923
test-armhf-armhf-libvirt-x
flight 105941 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105941/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 59254
test-armhf-armhf-xl
On Tue, Feb 21, 2017 at 08:19:53PM +0100, Daniel Kiper wrote:
> This way Xen can be loaded on EFI platforms using GRUB2 and
> other boot loaders which support multiboot2 protocol.
>
> Signed-off-by: Daniel Kiper
> ---
> v16 - suggestions/fixes:
> - improve comments in error handling
> (s
Every multiboot protocol (regardless of version) compatible image must
specify its load address (in ELF or multiboot header). Multiboot protocol
compatible loader have to load image at specified address. However, there
is no guarantee that the requested memory region (in case of Xen it starts
at 2
This way macro name better describes its function.
Currently it is used to calculate symbol offset in
relation to the beginning of Xen image mapping.
However, value returned by sym_offs() for a given
symbol is not always equal its physical address.
There is no functional change.
Suggested-by: Jan
On 21/02/2017 18:30, Stefano Stabellini wrote:
On Tue, 21 Feb 2017, Julien Grall wrote:
Hi Stefano,
On 21/02/17 17:49, Stefano Stabellini wrote:
On Tue, 21 Feb 2017, Dario Faggioli wrote:
On Tue, 2017-02-21 at 13:46 +, George Dunlap wrote:
Oh, actually, if --which I only now realize may
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: Doug Goldstein
Reviewe
Add multiboot2 protocol support for relocatable images. Only GRUB2 with
"multiboot2: Add support for relocatable images" patch understands
that feature. Older multiboot protocol (regardless of version)
compatible loaders ignore it and everything works as usual.
Signed-off-by: Daniel Kiper
Acked-b
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
..calculating its value during runtime.
Signed-off-by: Daniel Kiper
Acked-by: Jan Beulich
Reviewed-by: Doug Goldstein
---
xen/arch/x86/setup.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index e2a5f76..8feed35 100644
---
This way Xen can be loaded on EFI platforms using GRUB2 and
other boot loaders which support multiboot2 protocol.
Signed-off-by: Daniel Kiper
---
v16 - suggestions/fixes:
- improve comments in error handling
(suggested by Jan Beulich).
v15 - suggestions/fixes:
- rearrange inline as
Subsequent patches introducing relocatable early boot code play with
page tables using 2 MiB huge pages. If load address is not aligned at
2 MiB then code touching such page tables must have special cases for
start and end of Xen image memory region. So, let's make life easier
and move default load
Hi,
I am sending sixteenth version of multiboot2 protocol support for
legacy BIOS and EFI platforms. This patch series release contains
fixes for all known/confirmed issues.
The final goal is xen.efi binary file which could be loaded by EFI
loader, multiboot (v1) protocol (only on legacy BIOS pla
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. Currently, PE file con
Hello,
I have been to doing some research and as far as I know XEN supports
Live Migration
of VMs that only have shared storage. (i.e. iSCSI) If the VM has been
booted with local storage it cannot be live migrated.
QEMU seems to support live migration with local storage (I have tested using
'virsh
On Tue, 21 Feb 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 21/02/17 17:49, Stefano Stabellini wrote:
> > On Tue, 21 Feb 2017, Dario Faggioli wrote:
> > > On Tue, 2017-02-21 at 13:46 +, George Dunlap wrote:
> > > Oh, actually, if --which I only now realize may be what you are
> > > referring
Hi Stefano,
On 21/02/17 18:03, Stefano Stabellini wrote:
On Tue, 21 Feb 2017, Julien Grall wrote:
Hi George,
On 21/02/17 13:46, George Dunlap wrote:
I think our options look like:
Thank you for the summary of the options!
A. Don't trap guest WFI at all -- allow it to 'halt' in
moderate-
On 21/02/17 17:49, Stefano Stabellini wrote:
> On Tue, 21 Feb 2017, Dario Faggioli wrote:
>> On Tue, 2017-02-21 at 13:46 +, George Dunlap wrote:
>>>
>>> A. Don't trap guest WFI at all -- allow it to 'halt' in
>>> moderate-power-but-ready-for-interrupt mode.
>>>
>>> [..]
>>>
>>> A is safe becau
On Tue, 21 Feb 2017, Julien Grall wrote:
> Hi George,
>
> On 21/02/17 13:46, George Dunlap wrote:
> > I think our options look like:
>
> Thank you for the summary of the options!
>
> >
> > A. Don't trap guest WFI at all -- allow it to 'halt' in
> > moderate-power-but-ready-for-interrupt mode.
Hi Stefano,
On 21/02/17 17:49, Stefano Stabellini wrote:
On Tue, 21 Feb 2017, Dario Faggioli wrote:
On Tue, 2017-02-21 at 13:46 +, George Dunlap wrote:
Oh, actually, if --which I only now realize may be what you are
referring to, since you're talking about "guest burning its credits"--
you
On Tue, 21 Feb 2017, Dario Faggioli wrote:
> On Tue, 2017-02-21 at 13:46 +, George Dunlap wrote:
> >
> > A. Don't trap guest WFI at all -- allow it to 'halt' in
> > moderate-power-but-ready-for-interrupt mode.
> >
> > [..]
> >
> > A is safe because the scheduler should already have set a time
On 21/02/17 17:40, Andrew Cooper wrote:
> On 21/02/17 17:25, Jan Beulich wrote:
> On 20.02.17 at 12:00, wrote:
>>> The thermal/performance leaf was previously hidden from HVM guests, but
>>> fully
>>> visible to PV guests. Most of the leaf refers to MSR availability, and
>>> there
>>> is no
On 21/02/17 17:17, Jan Beulich wrote:
On 21.02.17 at 18:12, wrote:
>> Which particular feature groups? I could extend that text to say
>>
>> "VEX/XOP-encoded GPR instructions, such as those from the BMI{1,2} and
>> $X sets..."
> TBM and LWP.
Ok. Final text reads:
# AVX is not taken to mea
On 21/02/17 17:25, Jan Beulich wrote:
On 20.02.17 at 12:00, wrote:
>> The thermal/performance leaf was previously hidden from HVM guests, but fully
>> visible to PV guests. Most of the leaf refers to MSR availability, and there
>> is nothing an unprivileged PV guest can do with the informati
On Tue, 21 Feb 2017, Dario Faggioli wrote:
> On Tue, 2017-02-21 at 12:30 +, Julien Grall wrote:
> > On 21/02/2017 09:09, Dario Faggioli wrote:
> > > Well, TBH, we still are not entirely sure who the culprit is for
> > > high
> > > latency. There are spikes in Credit2, and I'm investigating that
On 21/02/17 17:16, Jan Beulich wrote:
On 20.02.17 at 12:00, wrote:
>> --- a/xen/arch/x86/cpuid.c
>> +++ b/xen/arch/x86/cpuid.c
>> @@ -163,6 +163,9 @@ static void recalculate_xstate(struct cpuid_policy *p)
>> */
>> static void recalculate_misc(struct cpuid_policy *p)
>> {
>> +/* Leaves
On Tue, 21 Feb 2017, Wei Liu wrote:
> On Mon, Feb 20, 2017 at 10:22:06AM -0800, Stefano Stabellini wrote:
> > The default dom0_mem is 128M which is not sufficient to boot a Ubuntu
> > based Dom0. It is not clear what a better default value could be.
> >
> > Instead, loudly warn the user when dom0_
Hi Stefano,
On 21/02/17 17:26, Stefano Stabellini wrote:
On Tue, 21 Feb 2017, Wei Liu wrote:
On Mon, Feb 20, 2017 at 10:22:06AM -0800, Stefano Stabellini wrote:
The default dom0_mem is 128M which is not sufficient to boot a Ubuntu
based Dom0. It is not clear what a better default value could b
On 21/02/17 17:20, Jan Beulich wrote:
>
The final 8 bits are the initial legacy APIC ID. For HVM guests, this was
overridden to vcpu_id * 2. The same logic is now applied to PV guests, so
guests don't observe a constant number on all vcpus via their emulated or
faulted view.
>
>>> On 20.02.17 at 12:00, wrote:
> The thermal/performance leaf was previously hidden from HVM guests, but fully
> visible to PV guests. Most of the leaf refers to MSR availability, and there
> is nothing an unprivileged PV guest can do with the information, so hide the
> leaf entirely.
>
> The
>>> On 20.02.17 at 12:00, wrote:
> The MONITOR flag isn't exposed to guests. The existing toolstack logic, and
> pv_cpuid() in the hypervisor, zero the MONITOR leaf for queries.
>
> However, the MONITOR leaf is still visible in the hardware domains native
> CPUID view, and Linux depends on this
Hello guys,
Could someone help me with VLAPIC and Event channel relationship? I can't
find any good design overview for it.
Are they compatible things or not?
Actually I want to map any PIRQ to HVM guest (for example keyboard), and
use VLAPIC to deliver virtual interrupt to HVM guest.
But seems l
>>> On 21.02.17 at 18:13, wrote:
> On 21/02/17 16:59, Jan Beulich wrote:
> On 20.02.17 at 12:00, wrote:
>>> The ebx word is more problematic. The low 8 bits are the brand ID and safe
>>> to
>>> pass straight through. The next 8 bits are the CLFLUSH line size. This
>>> value
>>> is forwar
>>> On 21.02.17 at 18:12, wrote:
> Which particular feature groups? I could extend that text to say
>
> "VEX/XOP-encoded GPR instructions, such as those from the BMI{1,2} and
> $X sets..."
TBM and LWP.
Jan
___
Xen-devel mailing list
Xen-devel@lists
>>> On 20.02.17 at 12:00, wrote:
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -163,6 +163,9 @@ static void recalculate_xstate(struct cpuid_policy *p)
> */
> static void recalculate_misc(struct cpuid_policy *p)
> {
> +/* Leaves with subleaf unions. */
> +p->basic.raw[0
On 21/02/17 16:59, Jan Beulich wrote:
On 20.02.17 at 12:00, wrote:
>> The ebx word is more problematic. The low 8 bits are the brand ID and safe
>> to
>> pass straight through. The next 8 bits are the CLFLUSH line size. This
>> value
>> is forwarded straight from hardware, as nothing goo
On 21/02/17 17:07, Jan Beulich wrote:
On 21.02.17 at 17:53, wrote:
>> On 21/02/17 16:47, Jan Beulich wrote:
>> On 21.02.17 at 17:40, wrote:
>>> On 20.02.17 at 12:00, wrote:
> --- a/xen/tools/gen-cpuid.py
> +++ b/xen/tools/gen-cpuid.py
> @@ -225,9 +225,13 @@ def crunch_nu
>>> On 21.02.17 at 17:53, wrote:
> On 21/02/17 16:47, Jan Beulich wrote:
> On 21.02.17 at 17:40, wrote:
>> On 20.02.17 at 12:00, wrote:
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -225,9 +225,13 @@ def crunch_numbers(state):
XSAVE: [XSAVEOPT,
>>> On 20.02.17 at 12:00, wrote:
> The ebx word is more problematic. The low 8 bits are the brand ID and safe to
> pass straight through. The next 8 bits are the CLFLUSH line size. This value
> is forwarded straight from hardware, as nothing good can possibly come of
> providing an alternative
On 21/02/17 15:14, Julien Grall wrote:
> Hi George,
>
> On 21/02/17 13:46, George Dunlap wrote:
>> I think our options look like:
>
> Thank you for the summary of the options!
>
>>
>> A. Don't trap guest WFI at all -- allow it to 'halt' in
>> moderate-power-but-ready-for-interrupt mode.
>>
>> B
flight 105953 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105953/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 5 xen
On 21/02/17 16:47, Jan Beulich wrote:
On 21.02.17 at 17:40, wrote:
> On 20.02.17 at 12:00, wrote:
>>> --- a/xen/tools/gen-cpuid.py
>>> +++ b/xen/tools/gen-cpuid.py
>>> @@ -225,9 +225,13 @@ def crunch_numbers(state):
>>> XSAVE: [XSAVEOPT, XSAVEC, XGETBV1, XSAVES,
>>>
This run is configured for baseline tests only.
flight 68588 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68588/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-boot
On Tue, 2017-02-21 at 12:30 +, Julien Grall wrote:
> On 21/02/2017 09:09, Dario Faggioli wrote:
> > Well, TBH, we still are not entirely sure who the culprit is for
> > high
> > latency. There are spikes in Credit2, and I'm investigating that.
> > But
> > apart from them? I think we need other
>>> On 21.02.17 at 17:40, wrote:
On 20.02.17 at 12:00, wrote:
>> --- a/xen/tools/gen-cpuid.py
>> +++ b/xen/tools/gen-cpuid.py
>> @@ -225,9 +225,13 @@ def crunch_numbers(state):
>> XSAVE: [XSAVEOPT, XSAVEC, XGETBV1, XSAVES,
>> AVX, MPX, PKU, LWP],
>>
>> -#
On 21/02/17 16:40, Jan Beulich wrote:
On 20.02.17 at 12:00, wrote:
>> --- a/xen/tools/gen-cpuid.py
>> +++ b/xen/tools/gen-cpuid.py
>> @@ -225,9 +225,13 @@ def crunch_numbers(state):
>> XSAVE: [XSAVEOPT, XSAVEC, XGETBV1, XSAVES,
>> AVX, MPX, PKU, LWP],
>>
>> -
>>> On 20.02.17 at 12:00, wrote:
> --- a/xen/tools/gen-cpuid.py
> +++ b/xen/tools/gen-cpuid.py
> @@ -225,9 +225,13 @@ def crunch_numbers(state):
> XSAVE: [XSAVEOPT, XSAVEC, XGETBV1, XSAVES,
> AVX, MPX, PKU, LWP],
>
> -# AVX is taken to mean hardware support for
>>> On 20.02.17 at 12:00, wrote:
> On real hardware, the bulk of CPUID data is system-specific and constant.
> Hold the toolstack to the same behaviour when constructing domains.
>
> Values which are expected to change dynamically (e.g. OSXSAVE) are
> unaffected
> and continue to function as bef
On 02/21/2017 10:45 AM, Juergen Gross wrote:
> On 21/02/17 16:31, Dan Streetman wrote:
>> On Fri, Jan 13, 2017 at 5:30 PM, Konrad Rzeszutek Wilk
>> wrote:
>>> On Fri, Jan 13, 2017 at 03:07:51PM -0500, Dan Streetman wrote:
Revert the main part of commit:
af42b8d12f8a ("xen: fix MSI setup
It makes clear distinction between the client (xl) and library (libxl),
which should help design better APIs. This will also help reduce the
code size in libxl directory.
Signed-off-by: Wei Liu
---
.gitignore | 2 +-
tools/libxl/Makefile| 22 ---
Xl has grown sufficiently large to warrnant its own directory. We also need
clear separation between the client (xl) and library (libxl).
This patch series moves xl into tools/xl directory.
Use find to generate a list of files to be installed from staging and wip
branch, then `diff -q staging w
We are about to split out xl (which depends on libxlutil) to a different
directory. Provide the proper options for compiling and linking in
Rules.mk, and replace the hardcoded string in libxl/Makefile.
No functional change.
Signed-off-by: Wei Liu
---
tools/Rules.mk | 7 +++
tools/libx
On 21/02/17 16:31, Dan Streetman wrote:
> On Fri, Jan 13, 2017 at 5:30 PM, Konrad Rzeszutek Wilk
> wrote:
>> 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 com
On Fri, Jan 13, 2017 at 5:30 PM, Konrad Rzeszutek Wilk
wrote:
> 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 messa
Hi George,
On 21/02/17 13:46, George Dunlap wrote:
I think our options look like:
Thank you for the summary of the options!
A. Don't trap guest WFI at all -- allow it to 'halt' in
moderate-power-but-ready-for-interrupt mode.
B. Trap guest WFI and block normally.
C. Trap guest WFI and pol
On Tue, 2017-02-21 at 13:46 +, George Dunlap wrote:
>
> A. Don't trap guest WFI at all -- allow it to 'halt' in
> moderate-power-but-ready-for-interrupt mode.
>
> [..]
>
> A is safe because the scheduler should already have set a timer to
> break
> out of it if necessary. The only potential
1 - 100 of 176 matches
Mail list logo
