From: Iurii Konovalenko
Now both play and capture is supported.
Signed-off-by: Iurii Konovalenko
Signed-off-by: Oleksandr Dmytryshyn
---
include/xen/interface/io/sndif.h | 93 +---
sound/drivers/xen-sndfront.c | 222 ++-
2 files changed, 25
From: Iurii Konovalenko
Now this driver registers an virtual sound card
and sends an PCM streams to the backend driver.
Backend driver is an user-space application and
uses ALSA with dmix plugin to play audio.
Signed-off-by: Iurii Konovalenko
Signed-off-by: Oleksandr Dmytryshyn
---
include/xe
This is Para-virtual sound driver.
This driver creates sound files in /dev/snd/:
controlC0, pcmC0D0p, etc. Then it intercepts some
IOCTLs and redirects them to the backend driver.
Backend driver is build-in the kernel. It issues
those IOCTLs on the real sound files and returns
the result to the fr
Hi to all.
Next series of patches introduces Para-virtual sound driver
CONFIG_XEN_SND_FRONTEND should be selected to use this driver.
Frontend driver registers an virtual sound card and sends/receives
an PCM streams to/from the backend driver. Backend driver is an
user-space application which us
Add code to support pvusb from domain create. One could specify
usb in domain's configuration file and create domain, then usb
device would be attached to guest automatically.
One could specify usb device in config file like this:
usb=['2-1.1']
Signed-off-by: Chunyan Liu
Signed-off-by: Simon Cao
Signed-off-by: Chunyan Liu
Signed-off-by: Simon Cao
---
tools/libxl/libxl.c | 6 +++---
tools/libxl/libxl_internal.h | 5 +
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 11cf0e1..3cd13db 100644
--- a/tools/libxl/libxl.
Add pvusb APIs, including:
- attach/detach (create/destroy) virtual usb controller.
- attach/detach usb device
- list assignable usb devices in host
- some other helper functions
Signed-off-by: Chunyan Liu
Signed-off-by: Simon Cao
---
tools/libxl/Makefile |2 +-
tools/libxl/libx
Add pvusb commands.
To attach a usb device to guest through pvusb, one could follow
following example:
#xl usb-ctrl-attach test_vm version=1 num_ports=8
#xl usb-list test_vm
will show the usb controllers and port usage under the domain.
#xl usb-assignable-list
will list all assignable usb
This patch series is based on Simon's work. Since there is no progress
after last August, I hope we can make this work proceed. Any comment will
be very appreciated.
It adds pvusb toolstack implementation, with pvusb kernel side work,
one could attach/detach a usb device to guest.
Changes to Simo
To attach a usb device, a virtual usb controller should be created first.
This patch defines usbctrl and usbdevice related structs.
Signed-off-by: Chunyan Liu
Signed-off-by: Simon Cao
---
tools/libxl/libxl_types.idl | 58 +++-
tools/libxl/libxl_types_int
>>> On 18.01.15 at 09:36, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Thursday, January 15, 2015 6:06 PM
>>
>> > The composed reserved region list is then passed to domain builder,
>> > which tries to detect and avoid conflicts when populating guest RAM.
>> > To avoid breakin
flight 33516 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33516/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs. 33292
Tests which did n
>>> On 16.01.15 at 18:14, wrote:
> On 01/16/2015 12:20 AM, Jan Beulich wrote:
> On 15.01.15 at 21:38, wrote:
>>> On 01/15/2015 09:03 AM, Tim Deegan wrote:
At 13:26 -0800 on 09 Jan (1420806397), Ed White wrote:
> This is treated exactly like p2m_ram_rw, except that suppress_ve is not
>>> On 16.01.15 at 18:17, wrote:
> On 01/16/2015 12:24 AM, Jan Beulich wrote:
> On 15.01.15 at 22:00, wrote:
>>> On 01/15/2015 09:33 AM, Tim Deegan wrote:
Hi,
Sorry for the fractured replies - my notes are confused about which
functions were defined where.
At 13:
>>> On 16.01.15 at 18:07, wrote:
> On 01/16/2015 11:57 AM, Andrew Cooper wrote:
>> On 16/01/15 16:45, Jan Beulich wrote:
>> On 16.01.15 at 17:38, wrote:
On Fri, 2015-01-16 at 16:34 +, Jan Beulich wrote:
On 16.01.15 at 17:16, wrote:
>> On Fri, 2015-01-16 at 16:06 +,
Before the chang, if setting iommu=0 option in xen boot option, the
painc info is "Couldn't enable IOMMU and iomm=required/force", this
will confuse the users because the iommu has been disabled.
Signed-off-by: Liang Li
---
xen/arch/x86/apic.c | 5 +
1 file changed, 5 insertions(+)
diff --g
On Sat, 2015-01-17 at 03:51 +, xen.org wrote:
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-i386-freebsd10-amd64
> test guest-start
>
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: qemu git:/
>>> On 18.01.15 at 09:58, wrote:
> still one open to hear suggestion though, regarding to how we want
> to pass the reserved regions to domain builder and hvmloader (for Xen
> we will extend related assignment hypercall to include per device override).
>
> one simple solution is to extend xc_hv
flight 33521 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33521/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 5 xen-boot fail REGR. vs. 26303
test-amd64-i386-rhel6h
On Mon, 2015-01-19 at 04:48 +, xen.org wrote:
> branch xen-unstable
> xen branch xen-unstable
> job build-armhf-libvirt
> test libvirt-build
>
> Tree: libvirt git://libvirt.org/libvirt.git
> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> Tree: xen git://xenbits.xen.org/
On Mon, 2015-01-19 at 09:37 +, Ian Campbell wrote:
> On Mon, 2015-01-19 at 04:48 +, xen.org wrote:
> > branch xen-unstable
> > xen branch xen-unstable
> > job build-armhf-libvirt
> > test libvirt-build
> >
> > Tree: libvirt git://libvirt.org/libvirt.git
> > Tree: qemuu git://xenbits.xen.or
All,
is there any chance I could get an ack or otherwise on
http://lists.xenproject.org/archives/html/xen-devel/2015-01/msg00869.html
http://lists.xenproject.org/archives/html/xen-devel/2015-01/msg00876.html
which both have seen reviews, but no suitable acks allowing me
to commit? There were a f
At 09:48 + on 19 Jan (1421657335), Jan Beulich wrote:
> All,
>
> is there any chance I could get an ack or otherwise on
>
> http://lists.xenproject.org/archives/html/xen-devel/2015-01/msg00869.html
> http://lists.xenproject.org/archives/html/xen-devel/2015-01/msg00876.html
>
> which both hav
>>> On 19.01.15 at 09:49, wrote:
> flight 33516 xen-4.4-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/33516/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-pair 17 guest-migrate/src_ho
>>> On 18.01.15 at 21:50, wrote:
> Regressions which are regarded as allowable (not blocking):
> test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like
> 33112
Or, continuing from the 4.4 test reply just sent, does that tree simply
need a one time force push so that the test m
>>> On 16.01.15 at 20:52, wrote:
> --- a/security_vulnerability_process.html
> +++ b/security_vulnerability_process.html
> @@ -212,6 +212,17 @@ following:
>The assigned XSA number
>The planned disclosure date
>
> +List members may, if (and only if) the Security Team grants
> +permission,
On 01/18/2015 08:58 AM, Tian, Kevin wrote:
>> From: George Dunlap
>> Sent: Thursday, January 15, 2015 7:45 PM
>>
>>>
>>> If above high level flow can be agreed, then we can move forward to
>>> discuss next level detail e.g. how to pass the rmrr list cross different
>>> components. :-)
>>
>> I think
>>> On 16.01.15 at 20:48, wrote:
> Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108
> process post-mortem"):
>> I would say, give it a week for further feedback and then prepare a patch.
>
> It's been rather longer than a week - sorry.
>
> I would like to propose the fo
On Fri, 16 Jan 2015, Jaggi, Manish wrote:
> Hi Stefano /clark,
> Thanks for sharing the link. For dom0 I am using openSuse.
> I have followed the steps listed on
> the(https://libvirt.org/compiling.html#building) to build and install. I
> believe build-librvit-deb would be doing the same steps or
On Fri, 2015-01-16 at 17:49 +, Julien Grall wrote:
> Hello,
>
> On 16/01/15 17:33, Vitaly Kuznetsov wrote:
> > Julien Grall writes:
> >
> >> The code to load the kernel is only used when Xen builds dom0. It
> >> happens during the boot.
> >
> > I suppose we don't have dom0 kexec for ARM now
On Thu, 2015-01-15 at 15:27 +, Jan Beulich wrote:
> There's no point in continuing to expose those.
There's a chance someone might have been using them for
__XEN_INTERFACE_VERSION__ >= 0x00030202, I think.
Given that we missed the opportunity to gate these when the change was
made we should p
>>> On 19.01.15 at 10:00, wrote:
> --- a/xen/arch/x86/apic.c
> +++ b/xen/arch/x86/apic.c
> @@ -915,6 +915,11 @@ void __init x2apic_bsp_setup(void)
> return;
> }
> printk("x2APIC: Already enabled by BIOS: Ignoring cmdline
> disable.\n");
> +} else {
> +
Hello Shaukat,
Xen should be able to run on Snapdragon 810 platforms.
The porting efforts should just take a few days, if you know the
characteristics of your dev board well, see:
http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions_whitepaper
Just to clarify, XenServer is a Citrix pr
Replace instances of "if ( p ) xfree(p)" with just "xfree(p)"
Signed-off-by: Andrew Cooper
CC: Keir Fraser
CC: Jan Beulich
CC: Tim Deegan
CC: Ian Campbell
CC: Ian Jackson
---
This was from some experimentation with semantic patches. 'spatch' can't
currently parse some of our macros (e.g.
About half of the cpuid space has the top bit of op set, and op it always
specified with unsigned integers. There are no problematic uses in tree at
the moment.
Signed-off-by: Andrew Cooper
CC: Keir Fraser
CC: Jan Beulich
---
xen/include/asm-x86/processor.h |4 ++--
1 file changed, 2 inse
Both are called with known-good domains, making the NULL check redundant.
Both also have open-coded forms of for_each_vcpu() which are replaced.
To aid the cleanup in switch_compat(), release_compat_l4() is updated to make
it safe to call on a vcpu without an existing compat l4.
Finally, switch_c
Xen event channels are not internal resources. They still have one end in a
domain, and are created at the request of privileged domains. This logic
which "successfully" creates a Xen event channel opens up undesirable failure
cases with ill-specified XSM policies.
If a domain is permitted to cr
On Mon, 2015-01-19 at 08:57 +, Jan Beulich wrote:
> >>> On 16.01.15 at 18:07, wrote:
> > Also, a side question --- how is platform ops interface considered
> > stable if it is versioned? I may have a different understanding of what
> > "stable" means.
>
> I'm not sure why this has a version
On 19/01/15 08:19, Oleksandr Dmytryshyn wrote:
> Hi to all.
>
> Next series of patches introduces Para-virtual sound driver
>
> CONFIG_XEN_SND_FRONTEND should be selected to use this driver.
>
> Frontend driver registers an virtual sound card and sends/receives
> an PCM streams to/from the backe
On Mon, 2015-01-19 at 10:42 +, Andrew Cooper wrote:
> Replace instances of "if ( p ) xfree(p)" with just "xfree(p)"
>
> Signed-off-by: Andrew Cooper
> CC: Keir Fraser
> CC: Jan Beulich
> CC: Tim Deegan
> CC: Ian Campbell
> CC: Ian Jackson
>
> ---
>
> This was from some experimentation
>>> On 19.01.15 at 11:36, wrote:
> On Thu, 2015-01-15 at 15:27 +, Jan Beulich wrote:
>> There's no point in continuing to expose those.
>
> There's a chance someone might have been using them for
> __XEN_INTERFACE_VERSION__ >= 0x00030202, I think.
>
> Given that we missed the opportunity to
On 19/01/15 08:19, Oleksandr Dmytryshyn wrote:
> +
> +struct sndif_request_open {
> + unsigned int dev_num;
> + unsigned int card_num;
> + unsigned int dev_type;
> + unsigned int _pad1;
> + uint64_t id; /* private guest value, echoed in resp */
> + unsigned in
On 19/01/15 08:19, Oleksandr Dmytryshyn wrote:
> From: Iurii Konovalenko
>
> Now this driver registers an virtual sound card
> and sends an PCM streams to the backend driver.
> Backend driver is an user-space application and
> uses ALSA with dmix plugin to play audio.
>
[...]
> struct sndif_req
On Mon, 2015-01-19 at 10:21 +, George Dunlap wrote:
> On 01/18/2015 08:58 AM, Tian, Kevin wrote:
> >> From: George Dunlap
> >> Sent: Thursday, January 15, 2015 7:45 PM
> >>
> >>>
> >>> If above high level flow can be agreed, then we can move forward to
> >>> discuss next level detail e.g. how t
>>> On 15.01.15 at 16:49, wrote:
> On 15/01/15 15:34, Jan Beulich wrote:
> On 15.01.15 at 15:40, wrote:
>>> c/s 3f8e22de7 "x86 hvm: Allow HPET to be configured as a per-domain config
>>> option" introduced the parameter to conditionally enable the HPET.
>>>
>>> However, having the check in hp
On 19/01/15 10:54, Ian Campbell wrote:
> On Mon, 2015-01-19 at 10:42 +, Andrew Cooper wrote:
>> Replace instances of "if ( p ) xfree(p)" with just "xfree(p)"
>>
>> Signed-off-by: Andrew Cooper
>> CC: Keir Fraser
>> CC: Jan Beulich
>> CC: Tim Deegan
>> CC: Ian Campbell
>> CC: Ian Jackson
>
On Mon, Jan 19, 2015 at 12:55 PM, David Vrabel wrote:
> On 19/01/15 08:19, Oleksandr Dmytryshyn wrote:
>> +
>> +struct sndif_request_open {
>> + unsigned int dev_num;
>> + unsigned int card_num;
>> + unsigned int dev_type;
>> + unsigned int _pad1;
>> + uint64_t id;
On Mon, Jan 19, 2015 at 12:50 PM, David Vrabel wrote:
> On 19/01/15 08:19, Oleksandr Dmytryshyn wrote:
>> Hi to all.
>>
>> Next series of patches introduces Para-virtual sound driver
>>
>> CONFIG_XEN_SND_FRONTEND should be selected to use this driver.
>>
>> Frontend driver registers an virtual sou
On Mon, Jan 19, 2015 at 12:57 PM, David Vrabel wrote:
> On 19/01/15 08:19, Oleksandr Dmytryshyn wrote:
>> From: Iurii Konovalenko
>>
>> Now this driver registers an virtual sound card
>> and sends an PCM streams to the backend driver.
>> Backend driver is an user-space application and
>> uses ALS
On Mon, 2015-01-19 at 11:12 +, Andrew Cooper wrote:
> On 19/01/15 10:54, Ian Campbell wrote:
> > Anyway, could you include the spatch in the commit log, for completeness
> > and for future cargo culting ;-) (unless it's huge, I guess)
>
> It was tiny, but sadly scummed to a `git clean`. I can
On 19 Jan 2015, at 10:20, Jan Beulich wrote:
On 16.01.15 at 20:52, wrote:
>> +List members may, if (and only if) the Security Team grants
>> +permission, deploy fixed versions during the embargo. Permission for
>
>
Better: List members may deploy fixed versions during the embargo, if (.
Use domain_max_vcpus(d) in preference to MAX_VIRT_CPUS when allocating the
poll mask. This allows x86 HVM guests to have a poll mask of 128 bits rather
than 8k bits.
While changing this, use xzalloc_array() in preference to xmalloc_array() to
avoid needing the subsequent call to bitmap_zero().
S
This allows the common XEN_DOMCTL_max_vcpus handler to loose some x86-specific
architecture knowledge.
It turns out that Xen had the same magic number twice in-tree with different
names (HVM_MAX_VCPUS and MAX_HVM_VCPUS). This removes all use of
MAX_HVM_VCPUS, and x86 uses HVM_MAX_VCPUS from the p
The arinc653 interface is capable of specifying a domain in the schedule (from
the toolstack) before the domain itself exists, or is present in the cpupool
(The domain is identified by UUID rather than domid). As a result, the
schedule can't be validated at this point.
The vcpu_id from userspace i
In all 4 cases, visible in the context are bounds check against d->max_vcpus.
Domain building will ensure that d->max_vcpus never exceeds an appropriate
bound. In the x86 case, different types of domains have different maxima for
vcpus, making the checks wrong as opposed to simply redundant.
For
MAX_VIRT_CPUS used to be an appropriate upper bound for vcpus when it was the
length of the fixed-size vcpus array in a struct domain. When the vcpu array
became dynamically allocated in Xen 4.0, it ceased to be an appropriate bound.
Andrew Cooper (4):
xen/domain: Introduce domain_max_vcpus() h
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, January 19, 2015 5:33 PM
>
> >>> On 18.01.15 at 09:58, wrote:
> > still one open to hear suggestion though, regarding to how we want
> > to pass the reserved regions to domain builder and hvmloader (for Xen
> > we will extend related
>>> On 19.01.15 at 12:12, wrote:
> On 19/01/15 10:54, Ian Campbell wrote:
>> On Mon, 2015-01-19 at 10:42 +, Andrew Cooper wrote:
>>> Replace instances of "if ( p ) xfree(p)" with just "xfree(p)"
>>>
>>> Signed-off-by: Andrew Cooper
>>> CC: Keir Fraser
>>> CC: Jan Beulich
>>> CC: Tim Deegan
At 11:24 + on 19 Jan (1421663081), Tian, Kevin wrote:
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: Monday, January 19, 2015 5:33 PM
> >
> > >>> On 18.01.15 at 09:58, wrote:
> > > still one open to hear suggestion though, regarding to how we want
> > > to pass the reserved region
>>> On 19.01.15 at 11:44, wrote:
> To aid the cleanup in switch_compat(), release_compat_l4() is updated to
> make
> it safe to call on a vcpu without an existing compat l4.
For this part of the change:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -349,6 +349,8 @@ static int
>>> On 19.01.15 at 11:45, wrote:
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -1155,21 +1155,25 @@ int alloc_unbound_xen_event_channel(
>
> spin_lock(&d->event_lock);
>
> -if ( (port = get_free_port(d)) < 0 )
> +rc = get_free_port(d);
> +if ( rc <
Jan Beulich writes ("Re: [Xen-devel] [xen-4.4-testing test] 33516: regressions
- FAIL"):
> > test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs.
> > 33292
>
> this continues to suffer from the swiotlb issue, and prevents the push
> from happening that would allow RC1s to be
>>> On 19.01.15 at 12:33, wrote:
> FWIW, I don't like adding hypervisor state (and even more so
> hypervisor mechanism like a new hypercall) for things that the
> hypervisor doesn't need to know about. Since the e820 is only shared
> between the tools and the guest, I'd prefer it to go in either
On 19/01/15 11:37, Jan Beulich wrote:
On 19.01.15 at 11:45, wrote:
>> --- a/xen/common/event_channel.c
>> +++ b/xen/common/event_channel.c
>> @@ -1155,21 +1155,25 @@ int alloc_unbound_xen_event_channel(
>>
>> spin_lock(&d->event_lock);
>>
>> -if ( (port = get_free_port(d)) < 0 )
>>> On 19.01.15 at 12:40, wrote:
> Jan Beulich writes ("Re: [Xen-devel] [xen-4.4-testing test] 33516:
> regressions -
> FAIL"):
>> > test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs.
>> > 33292
>>
>> this continues to suffer from the swiotlb issue, and prevents the push
Ian Campbell writes ("Re: [PATCH] xen/many: xfree() can tolerate NULL
pointers"):
> On Mon, 2015-01-19 at 10:42 +, Andrew Cooper wrote:
> > This was from some experimentation with semantic patches. 'spatch' can't
> > currently parse some of our macros (e.g. XEN_GUEST_HANDLE()), which cases it
Ian Campbell writes ("Re: [PATCH] xen/many: xfree() can tolerate NULL
pointers"):
> On Mon, 2015-01-19 at 11:12 +, Andrew Cooper wrote:
> > On 19/01/15 10:54, Ian Campbell wrote:
> > > Anyway, could you include the spatch in the commit log, for completeness
> > > and for future cargo culting ;
Jan Beulich writes ("Re: [xen-4.4-testing test] 33516: regressions - FAIL [and
2 more messages]"):
> On 19.01.15 at 12:40, wrote:
> > So, just to confirm, what I will do (if you give your permission) is
> > to force push 30f10d4d2b102bd7184b84c9cc3d2246f060706a to stable-4.4.
>
> Yes, please.
D
>>> On 19.01.15 at 12:47, wrote:
> Ian Campbell writes ("Re: [PATCH] xen/many: xfree() can tolerate NULL
> pointers"):
>> On Mon, 2015-01-19 at 11:12 +, Andrew Cooper wrote:
>> > On 19/01/15 10:54, Ian Campbell wrote:
>> > > Anyway, could you include the spatch in the commit log, for complete
>>> On 19.01.15 at 12:41, wrote:
> On 19/01/15 11:37, Jan Beulich wrote:
> On 19.01.15 at 11:45, wrote:
>>> --- a/xen/common/event_channel.c
>>> +++ b/xen/common/event_channel.c
>>> @@ -1155,21 +1155,25 @@ int alloc_unbound_xen_event_channel(
>>>
>>> spin_lock(&d->event_lock);
>>>
>>
Hi,
At 15:01 + on 17 Jan (1421503283), Andrew Cooper wrote:
> With this altp2m code, I have been thinking about migration and passthrough.
>
> Migration and passthrough are themselves mutually exclusive features, as
> logdirty cant identify DMA writes (and the toolstack can probably be
> forg
On 19/01/15 11:21, Andrew Cooper wrote:
This allows the common XEN_DOMCTL_max_vcpus handler to loose some x86-specific
architecture knowledge.
Sp. "lose"
+unsigned int domain_max_vcpus(const struct domain *d)
+{
+return MAX_VIRT_CPUS;
+}
+
inline?
Simon
Jan Beulich writes ("Re: [PATCH] xen/many: xfree() can tolerate NULL pointers"):
> On 19.01.15 at 12:47, wrote:
> > Umm, further to my last mail, we (the Free Software world in general)
> > should treat this the same way we would any other case where the
> > source code has been genuinely lost. W
At 11:41 + on 19 Jan (1421664109), Jan Beulich wrote:
> >>> On 19.01.15 at 12:33, wrote:
> > FWIW, I don't like adding hypervisor state (and even more so
> > hypervisor mechanism like a new hypercall) for things that the
> > hypervisor doesn't need to know about. Since the e820 is only shared
On Fri, 2015-01-16 at 19:52 +, Ian Jackson wrote:
> Permitting deployment during embargo seemed to have rough consensus on
> the principle. We seemed to be converging on the idea that the
> Security Team should explicitly set deployment restrictions for each
> set of patches.
>
> Signed-off-b
On Mon, 2015-01-19 at 10:20 +, Jan Beulich wrote:
> >>> On 16.01.15 at 20:52, wrote:
> > --- a/security_vulnerability_process.html
> > +++ b/security_vulnerability_process.html
> > @@ -212,6 +212,17 @@ following:
> >The assigned XSA number
> >The planned disclosure date
> >
> > +List
Use N-buffering instead of old deferred I/O, which is not suitable for high
frame rates. This includes new event type -- xenfb_in_released,
to track buffers not being used by backend.
Also use grants for fb pages, as they allow backend to map them
to video devices.
Signed-off-by: Sergiy Kibrik
--
On Fri, 2015-01-16 at 19:52 +, Ian Jackson wrote:
> Signed-off-by: Ian Jackson
> Signed-off-by: Ian Jackson
> ---
> security_vulnerability_process.html |5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/security_vulnerability_process.html
> b/security_vulnerab
On 19/01/15 12:16, Simon Rowe wrote:
> On 19/01/15 11:21, Andrew Cooper wrote:
>> This allows the common XEN_DOMCTL_max_vcpus handler to loose some
>> x86-specific
>> architecture knowledge.
> Sp. "lose"
>> +unsigned int domain_max_vcpus(const struct domain *d)
>> +{
>> +return MAX_VIRT_CPUS;
On Mon, 2015-01-19 at 12:52 +, Andrew Cooper wrote:
> I considered that but, while there is an asm-x86/domain.h, there is not
> an asm-arm/domain.h which would be the logical location for it to live.
I think you've just missed it?
$ ls -l xen/include/asm-arm/domain.h
-rw-rw-r-- 1 ianc xendev
On Fri, 16 Jan 2015, Jintack Lim wrote:
> Hi,
>
> I'm trying to measure number of cycles for hypercalls.
> I'm working on ARM v7 and v8.
>
> Xentrace seems to be a right tool to use according to this discussion.
> http://lists.xen.org/archives/html/xen-devel/2008-10/msg00480.html
>
> However whe
On 19/01/15 12:57, Ian Campbell wrote:
> On Mon, 2015-01-19 at 12:52 +, Andrew Cooper wrote:
>> I considered that but, while there is an asm-x86/domain.h, there is not
>> an asm-arm/domain.h which would be the logical location for it to live.
> I think you've just missed it?
>
> $ ls -l xen/inc
On 01/19/2015 12:23 PM, Tim Deegan wrote:
> At 11:41 + on 19 Jan (1421664109), Jan Beulich wrote:
> On 19.01.15 at 12:33, wrote:
>>> FWIW, I don't like adding hypervisor state (and even more so
>>> hypervisor mechanism like a new hypercall) for things that the
>>> hypervisor doesn't need t
On 18/01/15 15:17, Tamas K Lengyel wrote:
> This patch series aims to clean up the mem_event subsystem within Xen. The
> original use-case for this system was to allow external helper applications
> running in privileged domains to control various memory operations performed
> by Xen. Amongs these
Ian Campbell writes ("Re: [Xen-devel] [PATCH SECURITY-POLICY 3/9] Deployment
with Security Team Permission"):
> On Fri, 2015-01-16 at 19:52 +, Ian Jackson wrote:
> > +List members may, if (and only if) the Security Team grants
> > +permission, deploy fixed versions during the embargo. Permiss
On Mon, 2015-01-19 at 13:08 +, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH SECURITY-POLICY 3/9] Deployment
> with Security Team Permission"):
> > On Fri, 2015-01-16 at 19:52 +, Ian Jackson wrote:
> > > +List members may, if (and only if) the Security Team grants
> > >
Ian Campbell writes ("Re: [Xen-devel] [PATCH SECURITY-POLICY 4/9] Use a public
mailing list for predisclosure membership applications."):
> On Fri, 2015-01-16 at 19:52 +, Ian Jackson wrote:
> > -security@xenproject if they wish to receive pre-disclosure of
> > -advisories. Please include in th
flight 33542 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33542/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 33476
Tests which did not succeed,
On Mon, 2015-01-19 at 13:10 +, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH SECURITY-POLICY 4/9] Use a
> public mailing list for predisclosure membership applications."):
> > On Fri, 2015-01-16 at 19:52 +, Ian Jackson wrote:
> > > -security@xenproject if they wish to r
Commit 61a734d305e1 ("xen/manage: Always freeze/thaw processes when
suspend/resuming") ensured that userspace processes were always frozen
before suspending to reduce interaction issues when resuming devices.
However, freeze_processes() does not freeze kernel threads. Freeze
kernel threads as well
On Mon, 19 Jan 2015, Sergiy Kibrik wrote:
> Use N-buffering instead of old deferred I/O, which is not suitable for high
> frame rates. This includes new event type -- xenfb_in_released,
> to track buffers not being used by backend.
> Also use grants for fb pages, as they allow backend to map them
>
On Mon, 19 Jan 2015, Stefano Stabellini wrote:
> On Mon, 19 Jan 2015, Sergiy Kibrik wrote:
> > Use N-buffering instead of old deferred I/O, which is not suitable for high
> > frame rates. This includes new event type -- xenfb_in_released,
> > to track buffers not being used by backend.
> > Also use
On Tue, 2014-12-16 at 17:21 +0100, Juergen Gross wrote:
> Option Selects Depends
> --
Could you annotate (maybe not a new column, perhaps with a * or
something) which options are supposed t
On Mon, 2015-01-19 at 14:03 +0200, Sergiy Kibrik wrote:
> include/xen/interface/io/fbif.h |9 +-
Please get the any protocol changes reviewed and accepted into xen.git
first, including e.g. the switch to grant tables, if that requires
front/back end coordination.
Ian.
Jan Beulich writes ("[Xen-devel] [PATCH SECURITY-POLICY 0/9] Re: Security
policy ambiguities - XSA-108 process post-mortem"):
> LGTM, but I think there's no point in ack-ing the series as the
> changes need to be voted on anyway.
Indeed.
I will post a v2 with the minor fixes from this thread inc
Lars Kurth writes ("Re: [Xen-devel] [PATCH SECURITY-POLICY 3/9] Deployment with
Security Team Permission"):
> On 19 Jan 2015, at 10:20, Jan Beulich wrote:
> > On 16.01.15 at 20:52, wrote:
> >> +List members may, if (and only if) the Security Team grants
> >> +permission, deploy fixed versions du
>>> On 19.01.15 at 13:36, wrote:
> On Mon, 2015-01-19 at 10:20 +, Jan Beulich wrote:
>> >>> On 16.01.15 at 20:52, wrote:
>> > --- a/security_vulnerability_process.html
>> > +++ b/security_vulnerability_process.html
>> > @@ -212,6 +212,17 @@ following:
>> >The assigned XSA number
>> >T
>>> On 19.01.15 at 13:23, wrote:
> At 11:41 + on 19 Jan (1421664109), Jan Beulich wrote:
>> >>> On 19.01.15 at 12:33, wrote:
>> > FWIW, I don't like adding hypervisor state (and even more so
>> > hypervisor mechanism like a new hypercall) for things that the
>> > hypervisor doesn't need to kn
>>> On 19.01.15 at 14:28, wrote:
> I think it is still the case that selecting an option which is user
> visible is frowned upon?
I don't think so; iirc there are cases where things deliberately get
set up that way (for example library code that is explicitly meant
to be available also to out-of-
and i also don't know for sure if it's even due to this patch set
> or not):
> [ 2361.607881] irq 18: nobody cared (try booting with the
> "irqpoll" option)
> [ 2361.650103] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
> 3.19.0-rc5-creanuc-20150119-dofl
1 - 100 of 223 matches
Mail list logo
